Esta série de codelabs (tutoriais práticos e autoguiados) destina-se a ajudar os desenvolvedores do Google App Engine (Padrão) a modernizar os aplicativos por meio de uma série de migrações. Depois disso, os usuários podem tornar os aplicativos mais portáteis, inserindo-os explicitamente no Cloud Run, o serviço irmã de hospedagem de contêiner do Google Cloud no App Engine e em outros serviços de hospedagem de contêiner.
Neste tutorial, você aprende a colocar os aplicativos do App Engine em contêiner para implantá-los no serviço totalmente gerenciado do Cloud Run usando o Docker, uma plataforma conhecida no setor de desenvolvimento, envio e execução de aplicativos em contêineres. Para desenvolvedores do Python 2, este tutorial existe com o app de amostra do Cloud NDB do App Engine para módulo 2, enquanto os desenvolvedores do Python 3 têm a amostra do Cloud Datastore do Módulo 3.
Você aprenderá como realizar as seguintes tarefas:
- Contentorização do app usando o Docker
- Implante imagens de contêiner no Cloud Run
Pré-requisitos
- Um projeto do Google Cloud Platform com:
- Habilidades básicas em Python
- Conhecimento prático de comandos comuns do Linux
- Conhecimento básico sobre como desenvolver e implantar aplicativos do App Engine
- Recomendado: conclua o codelab Module 2 ou o codelab módulo 3.
- Um aplicativo funcional do App Engine pronto para ser criado em contêineres
- Python 2: exemplo do Cloud NDB do módulo 2
- Python 3: exemplo do Cloud Datastore do módulo 3
Pesquisa
Como você usará este codelab?
Os sistemas PaaS, como o App Engine e o Cloud Functions, oferecem muitas conveniências para sua equipe e aplicativo. Por exemplo, essas plataformas sem servidor permitem que o SysAdmin/Devops se concentre na criação de soluções. Seu aplicativo pode ser escalonado automaticamente de acordo com a necessidade, reduzir o tamanho zero para pagar com pagamento por uso, ajudar a controlar custos e usar uma variedade de linguagens de desenvolvimento comuns.
No entanto, a flexibilidade dos contêineres também é atraente, a capacidade de escolher qualquer linguagem, qualquer biblioteca e qualquer binário. Proporcionando aos usuários o melhor dos dois mundos, a conveniência da computação sem servidor e a flexibilidade dos contêineres é sobre o Google Cloud Run.
O aprendizado deste codelab não está no escopo deste codelab coberto pela documentação do Cloud Run. O objetivo aqui é você saber como colocar o aplicativo do App Engine em um contêiner para o Cloud Run (ou outros serviços). Há algumas coisas que você deve saber antes de avançar, principalmente que a experiência do usuário será um pouco diferente, um nível inferior, já que não haverá mais a implementação e a implantação do código do aplicativo.
Você precisará aprender algo sobre contêineres como como criá-los e implantá-los. Você também decide o que quer colocar na imagem do contêiner, incluindo um servidor da Web, já que não usará mais o servidor da Web do App Engine. Se preferir não seguir esse caminho, manter seus aplicativos no App Engine não é uma boa opção.
Neste tutorial, você aprenderá a colocar seu aplicativo em um contêiner, substituir os arquivos de configuração do Google App Engine por uma configuração de contêiner, determinar o que irá entrar no contêiner e especificar como iniciar seu aplicativo - muitas dessas coisas são tratadas automaticamente pelo Google App Engine.
Essa migração conta com estas etapas:
- Configuração/Pré-trabalho
- Inserir o aplicativo em contêiner
- Substituir arquivos de configuração
- Modificar arquivos do aplicativo
Antes de prosseguirmos com a parte principal do tutorial, vamos configurar o nosso projeto, obter o código e, em seguida, implantar o aplicativo de referência para saber que começamos a trabalhar com o código em funcionamento.
1. Configurar projeto
Se você concluiu os codelabs Módulo 2 ou módulo 3, recomendamos reutilizar o mesmo projeto (e código). Se preferir, crie um novo projeto ou reutilize outro. Verifique se o projeto tem uma conta de faturamento ativa e o App Engine (aplicativo) está ativado.
2. Receber app de amostra do valor de referência
Um dos pré-requisitos para este codelab é ter um aplicativo de exemplo Module 2 ou Module 3. Se você não tiver um, conclua qualquer um dos tutoriais (links acima) antes de continuar. Caso contrário, caso você já esteja familiarizado com o conteúdo dele, comece pelo código do módulo 2 ou 3 abaixo.
Independentemente de você usar o seu ou o nosso, o código do Módulo 2 é o local onde vamos ver a versão em Python do tutorial e, da mesma forma, o código do Módulo 3 para Python 3. Este codelab do Módulo 4 orienta você em cada etapa e, dependendo das suas opções, deve acabar com um código parecido com uma das pastas do repositório do módulo 4 (FINISH) quando concluído.
- Python 2 (aplicativo Cloud NDB)
- INICIAR: Código do módulo 2
- CONCLUIR: Código do módulo 4
- Python 3 (aplicativo do Cloud Datastore)
- INICIAR: Código do módulo 3
- CONCLUIR: Código do módulo 4
- Repositório completo (para clonar ou fazer o download do ZIP)
O diretório do Python 2 do Module 2 (os seus arquivos ou os nossos) deve ter a seguinte aparência:
$ ls
README.md appengine_config.py requirements.txt
app.yaml main.py templates
Se você estiver usando seu próprio código do Módulo 2 (2.x), também terá uma pasta lib. Nem lib nem appengine_config.py são usados para Python 3, em que o código STARTing 3 do módulo 3 (3.x) deve ter a seguinte aparência:
$ ls
README.md main.py templates
app.yaml requirements.txt
3. (Re) Implantar aplicativo de referência
As etapas de pré-trabalho restantes para serem executadas agora:
- Conheça melhor a ferramenta de linha de comando
gcloud - Reimplantar o aplicativo de amostra com
gcloud app deploy - Confirmar se o aplicativo é executado no App Engine sem problemas
Depois de executar essas etapas com sucesso, você estará pronto para contentorizar o contêiner.
O Docker é a plataforma de contêineres padrão do setor atualmente. Um desafio de usá-lo, conforme mencionado anteriormente, é um esforço para selecionar um Dockerfile eficiente, o arquivo de configuração que determina como as imagens de contêiner são criadas. Por outro lado, os Buildpacks exigem pouco esforço, já que usam introspecção para determinar as dependências do app, tornando o contêiner Buildpacks o mais eficiente possível.
Você está no lugar certo se já conhece contêineres e o Docker, mas quer saber mais sobre o contêiner do App Engine para Cloud Run. Você também pode fazer o Codelab do Módulo 5 (idêntico a este, mas com o Cloud Buildpacks) depois. Nosso app de exemplo Barebones é leve o suficiente para evitar alguns dos problemas Dockerfile mencionados anteriormente.
As etapas de migração incluem a substituição dos arquivos de configuração do App Engine e a especificação de como iniciar seu aplicativo. Veja abaixo uma tabela que resume os arquivos de configuração esperados para cada tipo de plataforma. Compare a coluna do App Engine com a coluna Docker (e, opcionalmente, os pacotes de build):
Descrição | App Engine | Docker | Pacotes de criação |
Configuração geral |
|
| ( |
Bibliotecas de terceiros |
|
|
|
Configuração de terceiros |
| (n/a) | (n/a) |
Inicialização | (n/a) ou |
|
|
Ignorar arquivos |
|
|
|
Depois que o aplicativo é colocado em um contêiner, ele pode ser implantado no Cloud Run. Outras opções de plataforma de contêiner do Google Cloud incluem Compute Engine, GKE e Anthos.
Configuração geral
Migrar do App Engine significa substituir app.yaml por um Dockerfile que descreva como criar e executar o contêiner. O App Engine inicia seu aplicativo automaticamente, mas o Cloud Run não. É para isso que são os comandos Dockerfile ENTRYPOINT e CMD. Saiba mais sobre Dockerfile nesta página de documentos do Cloud Run e veja um exemplo de Dockerfile que gera gunicorn.
Uma alternativa ao uso de ENTRYPOINT ou CMD em um Dockerfile é usar um Procfile. Por fim, um .dockerignore ajuda a filtrar arquivos que não são de app para manter o tamanho do contêiner reduzido. Em breve teremos novidades sobre elas.
Excluir app.yaml e criar Dockerfile
O app.yaml não é usado em contêineres. Portanto, exclua-o agora. O arquivo de configuração do contêiner é Dockerfile, e nosso aplicativo de amostra requer apenas um mínimo. Crie seu Dockerfile com este conteúdo, substituindo NNN por 2 ou 3, dependendo da versão do Python que você está usando:
FROM python:NNN-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python", "main.py"]
A maior parte de Dockerfile especifica como criar o contêiner excetoENTRYPOINT, que especifica como iniciar o contêiner. Nesse caso, ele chama python main.py para executar. servidor de desenvolvimento do Flask. Se você não estiver familiarizado com o Docker, a diretiva FROM indica a imagem base de onde começar e "slim" refere-se a uma distribuição mínima do Python. Saiba mais na página de imagens do Docker para Python.
O conjunto de comandos do comando cria o diretório de trabalho (/app), copia nos arquivos do aplicativo e executa pip install para trazer bibliotecas de terceiros para o contêiner. WORKDIR combina os comandos mkdir e cd do Linux em conjunto; leia mais na documentação do WORKDIR . As diretivas COPY e RUN são autoexplicativas.
Bibliotecas de terceiros
O arquivo requirements.txt pode permanecer o mesmo. O Flask deve estar presente com sua biblioteca de cliente do Datastore (Cloud Datastore ou Cloud NDB). Se você quiser usar outro servidor HTTP compatível com WSGI como o Gunicorn (a versão atual no momento da redação deste artigo é 20.0.4), adicione gunicorn==20.0.4 a requirements.txt.
Configuração de terceiros
Os desenvolvedores do App Engine para Python 2 sabem que as bibliotecas de terceiros são copiadas para a pasta lib, referenciadas em requirements.txt, detalhadas em app.yaml e compatíveis com appengine_config.py. Os contêineres, como os aplicativos do Python 3 do App Engine, usam apenas requirements.txt, portanto, todos os outros itens podem ser descartados, o que significa que, se você tiver um aplicativo do App Engine 2.x, exclua appengine_config.py e qualquer pasta lib agora.
Inicialização
Os usuários do Python 2 não inicializam o servidor da Web do App Engine, mas ao migrar para um contêiner, é necessário fazer isso. Isso é feito adicionando uma diretiva CMD ou ENTRYPOINT em Dockerfile especificando como iniciar seu aplicativo. Isso é descrito abaixo da mesma forma que os usuários do Python 3.
Os usuários do Python 3 têm a opção de converter os arquivos app.yaml para ter um entrypoint em vez de diretivas script: auto na seção handlers. Se você usar entrypoint em seu Python 3 app.yaml, ele será parecido com:
runtime: python38
entrypoint: python main.py
A diretiva entrypoint informa ao App Engine como iniciar o servidor. É possível movê-lo quase imediatamente para o Dockerfile (ou Procfile se usar Buildpacks [consulte Módulo 5] para contentorizar o app). Resumo sobre onde uma diretiva de ponto de entrada pode ser usada em ambas as plataformas:
- Docker: linha em
Dockerfile:ENTRYPOINT ["python", "main.py"] - Pacotes de criação: linha em
Procfile:web: python main.py
É possível usar o servidor de desenvolvimento do Flask para testes, mas se estiver usando um servidor de produção como o gunicorn para seu aplicativo, aponte a diretiva ENTRYPOINT ou CMD para ele como no Cloud Run Exemplo de guia de início rápido (em inglês).
Ignorar arquivos
Recomendamos criar um arquivo .dockerignore para cortar o tamanho do contêiner e não sobrecarregar a imagem do contêiner com arquivos supérfluos como estes:
*.md
*.pyc
*.pyo
.git/
.gitignore
__pycache__
Arquivos de aplicativos
Todos os apps Module 2 ou Module 3 são totalmente compatíveis com Python 2, o que significa que não há mudanças nos componentes principais de main.py; só adicionaremos algumas linhas do código de inicialização. Adicione um par de linhas na parte inferior de main.py para iniciar o servidor de desenvolvimento, já que o Cloud Run requer a abertura da porta 8080 para que possa chamar o aplicativo:
if __name__ == '__main__':
import os
app.run(debug=True, threaded=True, host='0.0.0.0',
port=int(os.environ.get('PORT', 8080)))
Quando a configuração do Docker e as atualizações do arquivo de origem estiverem concluídas, você estará pronto para executá-lo no Cloud Run. Antes disso, vamos falar rapidamente sobre os serviços.
Serviços x aplicativos
Embora o App Engine tenha sido criado principalmente para hospedar aplicativos, ele também é uma plataforma para hospedar serviços da Web ou aplicativos formados por um conjunto de microsserviços. No Cloud Run, tudo é um serviço, seja um serviço real ou um aplicativo com uma interface da Web. Portanto, considere o uso dele como a implantação de um serviço em vez de uma aplicação
A menos que seu aplicativo do Google App Engine seja composto por vários serviços, você não precisava fazer nada de nome ao implantar seus aplicativos. Isso muda com o Cloud Run, em que você precisa criar um nome de serviço. Enquanto o domínio appspot.com de um App Engine contém o ID do projeto, por exemplo, https://PROJECT_ID.appspot.com e talvez seja a abreviação do código da região, por exemplo, http://PROJECT_ID.REGION_ID.r.appspot.com.
No entanto, o domínio de um serviço do Cloud Run apresenta o nome do serviço, a abreviação do código da região e um hash, mas não o código do projeto. Por exemplo, https://SVC_NAME-HASH-REG_ABBR.a.run.app. Conclusão, comece a pensar no nome de um serviço.
Implantar o serviço
Execute o comando abaixo para criar a imagem do contêiner e implantar no Cloud Run. Quando solicitado, selecione sua região e permita conexões não autenticadas para facilitar o teste e selecione sua região, conforme apropriado, em que SVC_NAME é o nome do serviço que você está implantando.
$ gcloud beta run deploy SVC_NAME --source . Please choose a target platform: [1] Cloud Run (fully managed) [2] Cloud Run for Anthos deployed on Google Cloud [3] Cloud Run for Anthos deployed on VMware [4] cancel Please enter your numeric choice: 1 To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`. Please specify a region: [1] asia-east1 [2] asia-east2 [3] asia-northeast1 [4] asia-northeast2 [5] asia-northeast3 [6] asia-south1 [7] asia-southeast1 [8] asia-southeast2 [9] australia-southeast1 [10] europe-north1 [11] europe-west1 [12] europe-west2 [13] europe-west3 [14] europe-west4 [15] europe-west6 [16] northamerica-northeast1 [17] southamerica-east1 [18] us-central1 [19] us-east1 [20] us-east4 [21] us-west1 [22] us-west2 [23] us-west3 [24] us-west4 [25] cancel Please enter your numeric choice: <select your numeric region choice> To make this the default region, run `gcloud config set run/region REGION`. Allow unauthenticated invocations to [SVC_NAME] (y/N)? y Building using Dockerfile and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION] ✓ Building and deploying new service... Done. ✓ Uploading sources... ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM]. ✓ Creating Revision... Deploying Revision. ✓ Routing traffic... ✓ Setting IAM Policy... Done. Service [SVC_NAME] revision [SVC_NAME-00001-vos] has been deployed and is serving 100 percent of traffic. Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app
Acesse o URL especificado com seu navegador para confirmar que a implantação foi concluída.
Como o comando gcloud indica, os usuários podem definir várias configurações padrão para reduzir a saída e a interatividade, conforme mostrado acima. Por exemplo, para evitar toda a interação, você pode usar o seguinte comando de implantação de uma linha:
$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated
Caso você o use, selecione o mesmo nome de serviço SVC_NAME e o nome de REGION desejado, não a seleção do menu indexado como fizemos acima.
Confirme se o app funciona no Cloud Run como no App Engine. Se você passou para esta série sem fazer qualquer um dos codelabs anteriores, o app em si não muda. Ele registra todas as visitas à página principal da web (/) e tem esta aparência quando o site é acessado muitas vezes:
Agora, seu código precisa corresponder ao que está na pasta do repositório do Module 4, seja 2.x ou 3.x. Parabéns por concluir este codelab do Módulo 4.
Opcional: limpar
E a limpeza para evitar cobrança até que você esteja pronto para passar para o próximo codelab de migração? Como você está usando outro produto, consulte o guia de preços do Cloud Run.
Opcional: desativar o serviço
Se você ainda não estiver pronto para passar para o próximo tutorial, desative seu serviço para evitar cobranças adicionais. Quando estiver pronto para passar para o próximo codelab, você poderá reativá-lo. Enquanto seu aplicativo estiver desativado, ele não receberá tráfego para custos. No entanto, o uso do Datastore pode ser cobrado se exceder a cota gratuita. Exclua o suficiente para ficar abaixo desse limite.
Por outro lado, se você não quiser continuar com as migrações e quiser excluir tudo completamente, poderá excluir o serviço ou encerrar o projeto completamente.
Próximas etapas
Parabéns! Você criou um contêiner para seu aplicativo, o que conclui este tutorial. A partir daí, o próximo passo é aprender a fazer o mesmo com os pacotes do Cloud Build no codelab do módulo 5 (link abaixo) ou usar outra migração do App Engine:
- Migre para o Python 3, caso ainda não tenha feito isso. O aplicativo de amostra já é compatível com 2.x e 3.x. Portanto, a única mudança é que os usuários do Docker atualizem o
Dockerfilepara usar uma imagem do Python 3. - Módulo 5: Migrar para o Cloud Run com o Cloud Buildpacks
- Contentorize seu app para ser executado no Cloud Run com o Cloud Buildpacks
- Não é preciso saber nada sobre o Docker, os contêineres ou as
Dockerfiles. - Exige que você já tenha migrado seu aplicativo para Python 3.
- Módulo 7: filas de tarefas push do App Engine (obrigatório se você usar filas de tarefas [push]
- Adiciona tarefas push
taskqueuedo App Engine ao aplicativo Module 1 - Prepara os usuários a migrar para o Cloud Tasks no Módulo 8
- Adiciona tarefas push
- Módulo 3:
- Modernize o acesso ao Datastore do Cloud NDB para o Cloud Datastore
- Esta é a biblioteca usada para aplicativos do App Engine em Python 3 e aplicativos que não são do App Engine
- Módulo 6: Migrar para o Cloud Firestore
- Migrar para o Cloud Firestore para acessar recursos do Firebase
- O Cloud Firestore é compatível com o Python 2, mas este codelab está disponível apenas no Python 3.
Problemas/comentários do módulo de migração do App Engine
Se você encontrar problemas com este codelab, pesquise seu problema antes de preenchê-lo. Links para pesquisar e criar novos problemas:
- Issue Tracker dos codelabs de migração do App Engine
Recursos de migração
Os links para as pastas do repo para o Módulo 2 e 3 (START) e para o Módulo 4 (FINISH) podem ser encontrados na tabela abaixo. Elas também podem ser acessadas no repositório de todas as migrações de codelab do App Engine, que você pode clonar ou fazer o download de um arquivo ZIP.
Codelab | Python 2 | Python 3 |
(code) | ||
(code) | ||
Módulo 4 |
Recursos do App Engine e do Cloud Run
Veja abaixo mais recursos relacionados a essa migração específica:
- Contêineres
- Exibir o Google Cloud
- Google Cloud Build
- Google Cloud Container Registry
- Docker
- Postagem de lançamento do Cloud Buildpacks
- Postagem de implantação do Cloud Buildpacks
- Repositório do Cloud Buildpacks
- Especificação dos pacotes de criação do CNCF
- Ferramenta App Engine para o Cloud Run para gerar sua própria
service.yaml
- Geral