Módulo 5: Migrar do Google App Engine para o Cloud Run com o Cloud Buildpacks

1. Visão geral

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 os buildpacks do Cloud, uma alternativa ao Docker. Os Cloud Buildpacks contêinerizam seus apps sem gerenciar arquivos Dockerfile ou mesmo saber nada sobre o Docker.

Este codelab é destinado a desenvolvedores do App Engine em Python 2 que migraram os apps dos serviços integrados originais para o Python 3 e agora querem executá-los em um contêiner. O codelab começa com um app Python 3 do Módulo 2 ou 3 concluído.

Você aprenderá como realizar as seguintes tarefas:

  • Contentorizar seu app usando o Cloud Buildpacks
  • Implante imagens de contêiner no Cloud Run

Pré-requisitos

Pesquisa

Como você usará este codelab?

Apenas leitura Leitura e exercícios

2. Contexto

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ê vai aprender a colocar seu app em um contêiner, remover arquivos de configuração do App Engine e gerenciar um servidor da Web, incluindo como iniciar o app.

Essa migração conta com estas etapas:

  1. Configuração/Pré-trabalho
  2. Inserir o aplicativo em contêiner
    • Substituir arquivos de configuração
    • Modificar arquivos do aplicativo

3. Configuração/Pré-trabalho

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 do Módulo 2 ou 3. Se você não tiver um, recomendamos concluir qualquer um dos tutoriais (links acima) antes de continuar. Caso contrário, se você já estiver familiarizado com o conteúdo, comece pegando uma das pastas de código abaixo.

Independentemente de você usar o seu ou o nosso, é aí que este tutorial COMEÇA. Este codelab orienta você na migração e, quando terminar, ele deve corresponder principalmente ao que está na pasta do repositório FINISH do Módulo 5.

O diretório dos arquivos START (seu ou nosso) 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:

  1. Conheça melhor a ferramenta de linha de comando gcloud
  2. Reimplantar o aplicativo de amostra com gcloud app deploy
  3. 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.

4. Contentorização do aplicativo

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 quiser pular o aprendizado sobre o Docker e colocar seu app do App Engine em um contêiner para ser executado no Cloud Run ou em qualquer outra plataforma de hospedagem de contêineres. Se quiser aprender a usar o Docker para conteinerização de apps, faça o codelab do módulo 4 depois de concluir este. Ele é idêntico a este, mas usa o Docker para oferecer uma compreensão mais profunda de como gerenciar imagens de contêiner.

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 Buildpacks (e, opcionalmente, Docker):

Descrição

App Engine

Docker

Buildpacks

Configuração geral

app.yaml

Dockerfile

(service.yaml)

Bibliotecas de terceiros

requirements.txt

requirements.txt

requirements.txt

Configuração de terceiros

app.yaml (mais appengine_config.py e lib [2.x-apenas])

(n/a)

(n/a)

Inicialização

(n/a) ou app.yaml (se entrypoint for usado)

Dockerfile

Procfile

Ignorar arquivos

.gcloudignore e .gitignore

.gcloudignore, .gitignore e .dockerignore

.gcloudignore e .gitignore

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

O App Engine inicia seu aplicativo automaticamente, mas o Cloud Run não. O Procfile tem uma função semelhante à diretiva app.yaml entrypoint. No nosso app de exemplo, Procfile vai executar python main.py para iniciar o servidor de desenvolvimento do Flask. Se quiser, também é possível usar um servidor da Web de produção, como o gunicorn. Se fizer isso, adicione-o ao requirements.txt. Saiba mais sobre como implantar a partir do código-fonte usando buildpacks nesta página de documentos do Cloud Run.

Basta mover a diretiva app.yaml entrypoint para um Procfile. Se você não tiver um, use o servidor de desenvolvimento do Flask por enquanto, já que este é apenas um app de teste de amostra para familiarizar os usuários com essa migração. Seu app será um comando de inicialização específico que você conhece bem. Por baixo dos panos, o serviço do Cloud Run cria um service.yaml que se parece/age mais como um app.yaml. Para ver o service.yaml gerado automaticamente, acesse um link como este, mas para seu serviço SVC_NAME e REGION: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

Bibliotecas de terceiros

O arquivo requirements.txt não precisa ser alterado. 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

O Buildpack não é compatível com o Python 2, então não vamos falar sobre isso aqui. Os apps Python 3 executados em contêineres no Cloud Run são semelhantes aos apps Python 3 do App Engine, já que as bibliotecas de terceiros precisam ser especificadas em requirements.txt.

Inicialização

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 Procfile. Resumo sobre onde uma diretiva de ponto de entrada pode ser usada em ambas as plataformas: isso se traduz diretamente no seguinte, mostrando também o equivalente do Docker para sua informação:

  • Pacotes de criação: linha em Procfile: web: python main.py
  • Docker: linha em Dockerfile: ENTRYPOINT ["python", "main.py"]

Para testes e preparo, é fácil executar o servidor de desenvolvimento do Flask em Python, como fizemos acima. No entanto, os desenvolvedores podem optar por algo mais eficiente para produção, como o exemplo de guia de início rápido do Cloud Run, que usa gunicorn.

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)))

5. Criar e implantar

Com a configuração do App Engine substituída por buildpacks e as atualizações do arquivo de origem concluídas, você está 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 ID 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 ID da região e um hash, mas não o ID 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 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 Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] 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.

6. Resumo/limpeza

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:

app visitme

Agora, seu código precisa corresponder ao que está na pasta do repositório do módulo 5. Parabéns por concluir este codelab do Módulo 5.

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 app estiver desativado, ele não vai receber tráfego para gerar custos. No entanto, o uso do Datastore pode ser cobrado se exceder a cota sem custo financeiro. 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 o Docker no codelab do módulo 4 (link abaixo) ou usar outra migração do App Engine:

  • Módulo 4: migre para o Cloud Run com o Docker
    • Contentorize seu app para ser executado no Cloud Run com o Docker
    • Permite que você se mantenha no Python 2
  • Módulo 7: filas de tarefas push do App Engine (obrigatório se você usar filas de tarefas [push]
    • Adiciona tarefas push taskqueue do App Engine ao aplicativo Module 1
    • Prepara os usuários a migrar para o Cloud Tasks no Módulo 8
  • 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.

7. Outros recursos

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:

Recursos de migração

Os links para as pastas do repo para o Módulo 2 e 3 (START) e para o Módulo 5 (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

Módulo 2

código

(code)

Módulo 3

(code)

código

Módulo 5

(n/a)

código

Recursos do App Engine e do Cloud Run

Veja abaixo mais recursos relacionados a essa migração específica: