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 individualizados) tem como objetivo ajudar os desenvolvedores do Google App Engine (Standard) a modernizar os apps, orientando-os em 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, ensinamos como conteinerizar aplicativos do App Engine para implantação no serviço totalmente gerenciado do Cloud Run usando o Cloud Buildpacks, uma alternativa ao Docker. Os Cloud Buildpacks conteinerizam seus aplicativos sem gerenciar arquivos Dockerfile ou mesmo sem saber nada sobre o Docker.

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

Você aprenderá como realizar as seguintes tarefas:

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

Pré-requisitos

Pesquisa

Como você usará este codelab?

Apenas ler o documento Ler e fazer os 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ê aprenderá a conteinerizar seu aplicativo, remover arquivos de configuração do App Engine e gerenciar um servidor da Web, incluindo como iniciá-lo.

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 deste codelab é ter um app de exemplo dos Módulos 2 ou 3 em funcionamento. Se você não tiver um, recomendamos concluir qualquer um dos tutoriais (links acima) antes de prosseguir. Caso você já esteja familiarizado com o conteúdo deles, comece pegando uma das pastas de código abaixo.

Este tutorial inicia, seja seu ou o nosso. Este codelab orienta você durante a migração e, quando você terminar, ele deverá corresponder principalmente ao que está na pasta de repositórios FINISH do módulo 5.

O diretório dos arquivos START (seus ou os nossos) ficará assim:

$ 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 não quer mais aprender sobre o Docker e quer conteinerizar seu aplicativo do App Engine para ser executado no Cloud Run ou em qualquer outra plataforma de hospedagem de contêiner. Se você tiver interesse em 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 (em inglês)

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. A Procfile tem uma função semelhante à diretiva app.yaml entrypoint. Para o app de exemplo, Procfile vai executar python main.py para iniciar o servidor de desenvolvimento do Flask. Se quiser, use um servidor da Web de produção, como gunicorn, e adicione-o a requirements.txt. Saiba mais sobre como implantar a partir do código-fonte usando Buildpacks nesta página de documentos do Cloud Run.

Só é necessário mover a diretiva app.yaml entrypoint para um Procfile. Se você não tiver um, use o servidor de desenvolvimento Flask por enquanto, porque este é apenas um exemplo de app de teste para familiarizar os usuários com essa migração. Seu app será um comando de inicialização específico que você conhece melhor. Internamente, o serviço do Cloud Run cria um service.yaml que se parece com um app.yaml. Acesse um link como este para conferir o service.yaml gerado automaticamente 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 lá junto com sua biblioteca de cliente do Datastore (Cloud Datastore ou Cloud NBS). 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 buildpacks não oferecem suporte ao Python 2, então não vamos discutir isso aqui. Os aplicativos Python 3 em execução em contêineres no Cloud Run são semelhantes aos aplicativos Python 3 do App Engine, em 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 diretamente para Procfile. Resumindo onde uma diretiva de ponto de entrada ficaria entre as duas plataformas: isso se traduz diretamente no seguinte: também mostrando o equivalente do Docker para fins de 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 do Python, como fizemos acima, mas os desenvolvedores podem optar por algo mais poderoso para produção, como o exemplo do 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

Depois que a configuração do App Engine for substituída por Buildpacks e atualizações do arquivo de origem, tudo estará pronto para ser executado 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 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

Se você usar esse, selecione o mesmo nome de serviço SVC_NAME e o nome desejado para REGION, não a seleção do menu indexado como fizemos interativamente 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

Seu código vai corresponder ao que está na pasta de 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 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 daqui, a próxima etapa é aprender a fazer o mesmo com o Docker no codelab do Módulo 4 (link abaixo) ou trabalhar em outra migração para o 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 de repositório dos Módulos 2 e 3 (INÍCIO) e 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: