1. Visão geral
A série de codelabs da estação de migração sem servidor (tutoriais práticos e individualizados) e os vídeos relacionados têm como objetivo ajudar desenvolvedores sem servidor do Google Cloud a modernizar apps, orientando-os em uma ou mais migrações, principalmente para evitar serviços legados. Isso torna seus apps mais portáteis e oferece mais opções e flexibilidade, o que permite a integração e o acesso a uma variedade maior de produtos do Cloud e o upgrade para versões de idiomas mais recentes com mais facilidade. Embora inicialmente voltada para os primeiros usuários do Cloud, principalmente desenvolvedores do App Engine (ambiente padrão), esta série é ampla o suficiente para incluir outras plataformas sem servidor, como o Cloud Functions e o Cloud Run, ou outros lugares, se aplicável.
Antes, os desenvolvedores precisavam migrar dos "serviços agrupados" legados do App Engine. como Datastore e Memcache antes de poderem fazer upgrade das versões de linguagem, dois empreendimentos possivelmente desafiadores em sequência. Ao disponibilizar muitos dos principais serviços em pacote no serviço de 2a geração do App Engine, os desenvolvedores agora podem transferir seus aplicativos para os ambientes de execução mais recentes enquanto continuam a usar (a maioria) os serviços em pacote. Este codelab ajuda você a fazer upgrade de um aplicativo de exemplo do Python 2 para o 3, mantendo o uso do serviço empacotado do Datastore (por meio da biblioteca do App Engine do App Engine). O uso da maioria dos serviços em pacote requer apenas uma pequena atualização do código, como será abordado neste tutorial, mas há outros que exigem alterações mais extensas. eles serão abordados na "Parte 2", um módulo de acompanhamento e um codelab.
Você vai aprender a
- Fazer a portabilidade do aplicativo de amostra do App Engine do Python 2 para 3
- Atualizar a configuração do app para incluir o SDK do App Engine
- Adicionar o código do SDK ao app que oferece suporte a serviços em pacote em ambientes de execução de segunda geração, como Python 3
O que é necessário
- Um projeto do Google Cloud com uma conta de faturamento ativa do GCP.
- Habilidades básicas em Python
- Conhecimento prático de comandos comuns do Linux
- Conhecimento básico sobre desenvolvimento e implantação de apps no App Engine
- Um app do App Engine do Módulo 1 em funcionamento (conclua o codelab [recomendado] ou copie o app do repositório)
Pesquisa
Como você vai usar este tutorial?
Como você classificaria sua experiência com Python?
Como você classificaria sua experiência de uso dos serviços do Google Cloud?
2. Contexto
O serviço original do App Engine foi lançado em 2008 e vinha com um conjunto de APIs legadas (agora conhecidas como serviços agrupados) para facilitar a criação e a implantação de aplicativos globalmente. Esses serviços incluem Datastore, Memcache e Task Queue. Ainda que seja conveniente, os usuários ficaram preocupados com a portabilidade dos aplicativos ao usar APIs proprietárias vinculadas ao App Engine e queriam que seus aplicativos fossem mais portáteis. Isso, aliado ao fato de que muitos desses serviços em pacote estavam amadurecendo para se tornarem produtos de nuvem independentes, levaram a equipe do App Engine a lançar a plataforma de próxima geração em 2018, sem esses produtos.
Avance para o futuro com desenvolvedores Python 2 ansiosos para atualizar para Python 3. Um aplicativo 2.x que usa serviços em pacote exigia a migração desses serviços antes que os aplicativos pudessem ser transferidos para 3.x, representando um par de migrações forçadas de volta para trás, possivelmente desafiadoras também. Para ajudar nessa transição, a equipe do App Engine lançou no terceiro trimestre de 2021 um "buraco de minhoca" passado, permitindo que aplicativos executados em ambientes de execução de última geração acessem muitos desses serviços em pacote. Embora essa versão não inclua todos os serviços disponíveis nos ambientes de execução originais, as principais ferramentas, como Datastore, fila de tarefas e Memcache, estão disponíveis.
Este codelab demonstra as mudanças necessárias para você fazer upgrade do app para o Python 3 preservando o uso de serviços em pacote. O objetivo é que seus apps sejam executados nos ambientes de execução mais recentes, permitindo que você migre de serviços em pacote para equivalentes do Cloud independentes ou alternativas de terceiros de acordo com seu cronograma, em vez de impedir a migração para um upgrade 3.x. Embora a migração de serviços em pacote não seja mais necessária, isso oferece mais portabilidade e flexibilidade em termos de onde seus aplicativos podem ser hospedados, incluindo a mudança para plataformas que podem atender melhor suas cargas de trabalho ou simplesmente permanecer no App Engine enquanto faz upgrade para uma versão de linguagem mais moderna, como acabamos de descrever.
O aplicativo de exemplo Python 2 do Módulo 1 utiliza o serviço empacotado Datastore por meio do App Engine MapReduce. O app já migrou frameworks do webapp2 para o Flask, concluído no codelab do módulo 1, mas com o uso do Datastore intacto.
Este tutorial apresenta as seguintes etapas:
- Configuração/Pré-trabalho
- Atualizar a configuração
- Modificar o código do aplicativo
3. Configuração/Pré-trabalho
Esta seção explica como:
- Configurar seu projeto do Cloud
- Receber app de amostra do valor de referência
- (Re)implantar e validar o app de referência
Essas etapas garantem que você está começando com o código em funcionamento.
1. Configurar projeto
Se você concluiu o codelab do Módulo 1, recomendamos reutilizar o mesmo projeto e código. Outra opção é criar um novo projeto do Cloud ou reutilizar um projeto atual. Verifique se o projeto tem uma conta de faturamento ativa em que o serviço do App Engine foi ativado.
2. Receber app de amostra do valor de referência
Um dos pré-requisitos deste codelab é ter um app do Módulo 1 do App Engine em funcionamento: conclua o codelab do módulo 1 (recomendado) ou copie o app do módulo 1 do repositório. Não importa se você usa o seu ou o nosso, o código do Módulo 1 é onde vamos "INICIAR". Este codelab orienta você em cada etapa, concluindo com um código semelhante ao que está na pasta de repositório "FINISH" do Módulo 7.
- INÍCIO: pasta do módulo 1 (Python 2)
- FINISH: pasta do módulo 1b (Python 3)
- Repositório inteiro (para clonar ou fazer o download do arquivo ZIP)
Independentemente do app do Módulo 1 usado, a pasta será semelhante à mostrada abaixo, possivelmente também com uma pasta lib
:
$ ls README.md appengine_config.py requirements.txt app.yaml main.py templates
3. (Re) Implantar aplicativo de referência
Siga as etapas abaixo para (re)implantar o app do Módulo 1:
- Exclua a pasta
lib
, se houver uma, e execute:pip install -t lib -r requirements.txt
para preencherlib
novamente. Pode ser necessário usar o comandopip2
se você tiver o Python 2 e o 3 instalados. - Verifique se você instalou e inicializou a ferramenta de linha de comando
gcloud
e analisou o uso dela. - Defina seu projeto do Cloud com
gcloud config set project
PROJECT_ID
se você não quiser inserir oPROJECT_ID
com cada comandogcloud
emitido. - Implante o app de exemplo com
gcloud app deploy
- Confirme se o app Módulo 1 é executado conforme o esperado, sem problemas para mostrar as visitas mais recentes (ilustrados abaixo).
4. Atualizar a configuração
Depois de executar essas etapas e ver que seu app da Web funciona, será possível fazer a portabilidade dele para o Python 3, começando com a configuração.
Adicionar o SDK ao arquivo requirements.txt
O ambiente de execução do Python 3 do App Engine reduz significativamente a sobrecarga do uso de bibliotecas de terceiros. É necessário apenas listá-los em requirements.txt
. Para usar os serviços incluídos no Python 3, adicione o pacote do SDK do App Engine appengine-python-standard
a ele. O pacote do SDK une o Flask do módulo 1:
flask
appengine-python-standard
Atualizar o app.yaml
Siga as etapas abaixo para aplicar as mudanças de configuração ao arquivo app.yaml
:
- Substitua a diretiva
runtime
pela versão compatível do Python 3. Por exemplo, especifiquepython310
para Python 3.10. - Exclua as diretivas
threadsafe
eapi_version
, já que nenhuma delas é usada no Python 3. - Exclua totalmente a seção
handlers
, já que esse app tem apenas gerenciadores de script. Se o app tiver gerenciadores de arquivos estáticos, deixe-os intactos nohandlers
. - O ambiente de execução do Python 3 não oferece suporte a bibliotecas integradas de terceiros como o ambiente de execução do Python 2. Se seu app tiver uma seção
libraries
emapp.yaml
, exclua a seção inteira. Os pacotes obrigatórios só precisam ser listados norequirements.txt
, como bibliotecas não integradas. Nosso app de exemplo não tem uma seçãolibraries
. Siga para a próxima etapa. - Crie uma diretiva
app_engine_apis
definida comotrue
para usá-la. Isso corresponde a adicionar o pacote do SDK do App Engine aorequirements.txt
acima.
Resumo das mudanças necessárias a serem feitas em app.yaml
:
ANTES:
runtime: python27
threadsafe: yes
api_version: 1
handlers:
- url: /.*
script: main.app
DEPOIS:
runtime: python310
app_engine_apis: true
Outros arquivos de configuração
Como todos os pacotes de terceiros só precisam estar listados em requirements.txt
, a menos que você tenha algo especial em appengine_config.py
, exclua esse item. Da mesma forma, como todas as bibliotecas de terceiros são instaladas automaticamente durante o processo de build, não é necessário copiá-las ou disponibilizá-las. Isso significa que não há mais o comando pip install
nem a pasta lib
. Portanto, exclua-as. Resumindo:
- Excluir
appengine_config.py
arquivo - Excluir
lib
pasta
Isso conclui todas as mudanças de configuração necessárias.
5. Modificar o código do aplicativo
Para acessar a maioria dos serviços em pacote disponíveis no ambiente de execução do Python 3, é necessário um pequeno trecho de código que envolve o objeto de aplicativo da interface de gateway do servidor da Web (WSGI, na sigla em inglês) em main.py
. A função wrapper é google.appengine.api.wrap_wsgi_app()
, que pode ser usada importando-a e encapsulando seu objeto WSGI com ela. Faça as alterações abaixo para refletir a atualização necessária para Flask em main.py
:
ANTES:
from flask import Flask, render_template, request
from google.appengine.ext import ndb
app = Flask(__name__)
DEPOIS:
from flask import Flask, render_template, request
from google.appengine.api import wrap_wsgi_app
from google.appengine.ext import ndb
app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
Consulte a documentação para ver exemplos de encapsulamento UDP de outras bibliotecas do Python.
Embora esse exemplo funcione para conceder ao seu aplicativo acesso à maioria dos serviços incluídos no Python 3, outros, como Blobstore e Mail, exigem códigos adicionais. Falaremos sobre esses exemplos em outro módulo de migração.
Isso conclui todas as mudanças necessárias para adicionar o uso dos serviços agrupados do App Engine ao aplicativo de exemplo do Módulo 1. O aplicativo já é compatível com Python 2 e 3. Portanto, não haverá outras mudanças na portabilidade para o Python 3 além do que você já fez na configuração. A etapa final: implante esse aplicativo modificado no ambiente de execução Python 3 do App Engine de última geração e confirme se as atualizações foram bem-sucedidas.
6. Resumo/limpeza
Esta seção encerra este codelab implantando o app, verificando se ele funciona conforme o esperado e em qualquer saída refletida. Após a validação do app, faça uma limpeza e considere as próximas etapas.
Implante e verifique o aplicativo
Implante o app Python 3 com gcloud app deploy
e confirme se ele funciona como no Python 2. Nenhuma das funcionalidades muda, então a saída precisa ser idêntica ao app Módulo 1:
Observações finais
- Compare o que você tem com o que está na pasta do módulo 1b (CONCLUIR). Se você tiver caminhado errado ao longo do caminho, faça os ajustes necessários.
- Compare o Módulo 0
main.py
lado a lado com o Módulo 1bmain.py
nesta página (se o app ainda usawebapp2
). Depois, faça o codelab do Módulo 1 para aprender a migrar dewebapp2
para Flask.
Parabéns por ter dado o primeiro passo para transferir seus aplicativos do App Engine em Python 2 para Python 3 mantendo o uso dos serviços em pacote neste momento.
Limpar
Geral
Se você já tiver terminado por enquanto, recomendamos que desative seu aplicativo do App Engine para evitar cobranças. No entanto, se você quiser fazer mais testes, saiba que a plataforma do App Engine tem uma cota sem custo financeiro e, desde que você não exceda esse nível de uso, não haverá cobranças. Isso é para computação, mas também pode haver cobranças por serviços relevantes do App Engine. Portanto, consulte a página de preços para mais informações. Se essa migração envolver outros serviços do Cloud, eles serão faturados separadamente. Em ambos os casos, se aplicável, consulte a seção "Específico para este codelab". seção abaixo.
Para divulgação completa, a implantação em uma plataforma de computação sem servidor do Google Cloud, como o App Engine, incorre em menores custos de criação e armazenamento. O Cloud Build tem a própria cota sem custo financeiro, assim como o Cloud Storage. O armazenamento da imagem consome parte da cota. No entanto, talvez você more em uma região que não tenha esse nível sem custo financeiro, portanto, esteja ciente do uso do armazenamento para minimizar os possíveis custos. "Pastas" específicas do Cloud Storage que você deve analisar incluem:
console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
- Os links de armazenamento acima dependem do
PROJECT_ID
e da *LOC
*ação, por exemplo, "us
" caso seu app esteja hospedado nos EUA.
Por outro lado, se você não for continuar com este aplicativo ou outros codelabs de migração relacionados e quiser excluir tudo completamente, encerre seu projeto.
Específicos deste codelab
Os serviços listados abaixo são exclusivos deste codelab. Consulte a documentação de cada produto para mais informações:
- o serviço App Engine Datastore é fornecido pelo Cloud Datastore (Cloud Firestore no modo Datastore), que também tem um nível sem custo financeiro; consulte a página de preços para mais informações.
Próximas etapas
Há várias direções para ir a partir daqui:
- Atualizar o código usando serviços em pacote que exigem mais alterações de código
- Migrar de serviços em pacote para produtos independentes do Cloud
- Migrar do App Engine para outra plataforma sem servidor do Cloud
O acesso a outros serviços em pacote, como Blobstore, Mail e Deferred, requer mais alterações de código. Os módulos de migração com foco na mudança dos serviços em pacote legados do App Engine a serem considerados incluem:
- Módulo 2: do App Engine do App Engine para o Cloud NFS
- Módulos 7 a 9: fila de tarefas do App Engine (tarefas push) para o Cloud Tasks
- Módulos 12 a 13: Memcache do App Engine para o Cloud Memorystore
- Módulos 15 a 16: Blobstore do App Engine para Cloud Storage
- Módulos 18 a 19: fila de tarefas do App Engine (tarefas pull) para o Cloud Pub/Sub
O App Engine não é mais a única plataforma sem servidor no Google Cloud. Se você tem um aplicativo pequeno do App Engine ou com funcionalidade limitada e quer transformá-lo em um microsserviço independente ou quer dividir um aplicativo monolítico em vários componentes reutilizáveis, estes são bons motivos para migrar para o Cloud Functions. Se a conteinerização se tornou parte do fluxo de trabalho de desenvolvimento de aplicativos, principalmente se consistir em um pipeline de CI/CD (integração/entrega contínua ou implantação), considere migrar para o Cloud Run. Esses cenários são abordados nos seguintes módulos:
- Migrar do App Engine para o Cloud Functions: consulte o Módulo 11
- Migrar do App Engine para o Cloud Run: consulte o Módulo 4 para conteinerizar seu app com o Docker ou o Módulo 5 para fazer isso sem contêineres, conhecimento do Docker ou
Dockerfile
s
A mudança para outra plataforma sem servidor é opcional. Recomendamos considerar as melhores opções para seus apps e casos de uso antes de fazer qualquer mudança.
Seja qual for o módulo de migração que você considerar a seguir, todo o conteúdo da estação de migração sem servidor (codelabs, vídeos, código-fonte [quando disponível]) pode ser acessado no repositório de código aberto. O README
do repositório também fornece orientações sobre quais migrações considerar e qualquer "ordem" relevante. de módulos de migração.
7. Outros recursos
Abaixo estão listados recursos adicionais para desenvolvedores que querem explorar melhor esse Módulo de migração ou o relacionado, assim como produtos relacionados. Isso inclui locais para fornecer feedback sobre esse conteúdo, links para o código e várias documentações que podem ser úteis.
Problemas/feedback do codelab
Se você encontrar problemas com este codelab, pesquise seu problema antes de preenchê-lo. Links para pesquisar e criar novos problemas:
Recursos de migração
Os links para as pastas do repositório do Módulo 1 (INÍCIO) e do Módulo 1b (FINISH) podem ser encontrados na tabela abaixo. Eles também podem ser acessados no repositório para todas as migrações de codelab do App Engine.
Codelab | Python 2 | Python 3 |
N/A | ||
Módulo 17 (este codelab) | N/A | código (mod1b-flask) |
Recursos on-line
Veja abaixo recursos on-line que podem ser relevantes para este tutorial:
Pacotes de serviços do App Engine
- Como acessar serviços incluídos no ambiente de execução de última geração do Python 3
- Comparação lado a lado do app do módulo 0 (Python 2) e do app do módulo 1b (Python 3)
- Amostras de wrapper de objeto WSGI da estrutura da Web do SDK do App Engine
- Suporte para serviços incluídos no App Engine em ambientes de execução de última geração (2021)
Documentos gerais do App Engine
- Documentação do App Engine
- Ambiente de execução do App Engine para Python 2 (ambiente padrão)
- Como usar as bibliotecas integradas do App Engine no App Engine para Python 2
- Ambiente de execução do App Engine para Python 3 (ambiente padrão)
- Diferenças entre o Python 2 e o Três ambientes de execução do App Engine (ambiente padrão)
- Guia de migração do App Engine (ambiente padrão) Python 2 para 3
- Informações de preços e cotas do App Engine
- Lançamento da plataforma App Engine de segunda geração (2018)
- Suporte de longo prazo para ambientes de execução legados
- Repositório de exemplos de migração da documentação (em inglês)
- Repositório de amostras de migração com contribuição da comunidade
Outras informações sobre a nuvem
- Python no Google Cloud Platform
- Bibliotecas de cliente do Python para Google Cloud
- "Sempre sem custo financeiro" do Google Cloud nível
- SDK Google Cloud (ferramenta de linha de comando
gcloud
) - Toda a documentação do Google Cloud
Vídeos
- Estação de migração sem servidor
- Expedições sem servidor
- Inscreva-se no Google Cloud Tech
- Inscreva-se no Google Developers
Licença
Este conteúdo está sob a licença Atribuição 2.0 Genérica da Creative Commons.