Módulo 11: Como migrar do Google App Engine para o Cloud Functions

1. Visão geral

A série de codelabs da Serverless Migration Station (tutoriais práticos e autoguiados) e os vídeos relacionados têm como objetivo ajudar os desenvolvedores sem servidor do Google Cloud a modernizar os aplicativos orientando-os em uma ou mais migrações, principalmente a migração de serviços legados. Isso torna seus apps mais portáteis e oferece mais opções e flexibilidade, permitindo que você se integre e acesse uma variedade maior de produtos do Cloud e faça upgrade mais fácil para versões de linguagem mais recentes. Embora o foco inicial seja nos 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 em outro lugar, se aplicável.

Há situações em que você não tem um "aplicativo inteiro" para exigir os recursos do App Engine ou do Cloud Run. Se o código consistir apenas em um microsserviço ou uma função simples, o Cloud Functions provavelmente será mais adequado. Neste codelab, você vai aprender a migrar apps simples do App Engine (ou separar apps maiores em vários microsserviços) e implantá-los no Cloud Functions, outra plataforma sem servidor criada especificamente para casos de uso como este.

Você vai aprender a

  • Usar o Cloud Shell
  • Ativar a API Google Cloud Translation
  • Autenticar as solicitações de API
  • Converter um pequeno app do App Engine para execução no Cloud Functions
  • Implantar seu código no Cloud Functions

O que é necessário

Pesquisa

Como você vai usar este tutorial?

Apenas leitura Ler e fazer os exercícios

Como você classificaria sua experiência com Python?

Iniciante Intermediário Proficiente

Como você classificaria sua experiência de uso dos serviços do Google Cloud?

Iniciante Intermediário Proficiente

2. Contexto

Os sistemas PaaS, como o Google App Engine e o Cloud Functions, oferecem muitas conveniências para os usuários. Essas plataformas sem servidor permitem que sua equipe técnica se concentre na criação de soluções de negócios em vez de gastar tempo investigando plataformas para usar e determinando a quantidade de hardware necessária. Os aplicativos podem ser escalonados automaticamente de acordo com a necessidade, reduzir escala vertical para zero com pagamento por uso para controlar custos e usar uma variedade de linguagens de desenvolvimento comuns.

No entanto, embora o desenvolvimento de aplicativos da Web full-stack ou back-ends complexos para apps móveis seja uma ótima opção para o App Engine, muitas vezes os desenvolvedores estão tentando colocar alguma funcionalidade on-line, como atualizar um feed de notícias ou mostrar o placar mais recente do jogo de playoff do time da casa. Embora haja uma lógica de programação para os dois cenários, nenhum deles parece ser um "aplicativo" completo que exija a capacidade do App Engine. É aí que entra o Cloud Functions.

O Cloud Functions é usado para implantar o pequeno trecho de código que:

  • Não faz parte de um aplicativo inteiro
  • Não é necessário em um stack de desenvolvimento inteiro
  • Está em um aplicativo ou back-end de app para dispositivos móveis único que se concentra em uma coisa

Também é possível usar o Cloud Functions para dividir um aplicativo grande e monolítico em vários microsserviços, cada um usando um banco de dados comum compartilhado, como o Cloud Firestore ou o Cloud SQL. E se você quiser que sua função ou microsserviço seja conteinerizado e executado sem servidor no Cloud Run, também é possível fazer isso.

Nosso app de amostra do App Engine, que apareceu em quase todos os tutoriais de migração, é um app curto com funcionalidade básica que funciona tão bem no Cloud Functions. Neste tutorial, você vai aprender a modificar esse app para que ele seja executado no Cloud Functions. Do ponto de vista do App Engine, como as funções são mais simples do que apps inteiros, sua experiência de início deve ser mais fácil (e rápida), com menos "sobrecarga" em geral. Essa migração conta com estas etapas:

  • Configuração/Pré-trabalho
  • Remover arquivos de configuração
  • Modificar arquivos do aplicativo

3. Configuração/Pré-trabalho

Este codelab começa com a versão em Python 3 do app de amostra do Cloud NDB do App Engine para módulo 2 porque o Cloud Functions não é compatível com o Python 2. Primeiro, vamos configurar o projeto, receber o código e implantar o app de referência para confirmar que estamos começando com um código funcional.

1. Configurar projeto

Se você concluiu o codelab do Módulo 2 (e o portou para o Python 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 com o serviço do App Engine 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. Se você não tiver um, conclua qualquer um dos tutoriais vinculados acima antes de continuar. Caso contrário, se você já estiver familiarizado com o conteúdo, comece pegando o código do Módulo 2 abaixo.

Independentemente de você usar o seu ou o nosso, o código do Módulo 2 em Python 3 é o que vamos usar. Este codelab do Módulo 11 orienta você em cada etapa, concluindo com um código semelhante ao que está na pasta do repositório do Módulo 11 (FINISH).

O diretório do Python 3 do Module 2 (os seus arquivos ou os nossos) 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 converter em uma função do Cloud.

4. Remover arquivos de configuração

O arquivo app.yaml é um artefato do App Engine que não é usado com o Cloud Functions. Portanto, exclua-o agora. Se você não fizer isso ou se esquecer, não haverá problemas, já que o Cloud Functions não usa esse arquivo. Essa é a única mudança de configuração, já que requirements.txt permanece idêntico ao que era no Módulo 2.

Se você também estiver portando um app do App Engine em Python 2 para Python 3, exclua appengine_config.py e a pasta lib, se houver uma. São artefatos do App Engine não usados no ambiente de execução do Python 3.

5. Modificar arquivos do aplicativo

Há apenas um arquivo de aplicativo, main.py, então todas as mudanças necessárias para migrar para o Cloud Functions ocorrem nesse arquivo.

Importações

Como estamos trabalhando apenas com funções, não é necessário um framework de aplicativo da Web. No entanto, para facilitar, quando as funções do Cloud Functions baseadas em Python são chamadas, elas recebem automaticamente um objeto de solicitação para que seu código use conforme necessário. A equipe do Cloud Functions o selecionou para ser um objeto de solicitação do Flask transmitido à sua função.

Como os frameworks da Web não fazem parte do cenário do Cloud Functions, não há importações do Flask a menos que seu app use outros recursos do Flask. Esse é o nosso caso, já que a renderização de modelos ainda está acontecendo após a conversão para uma função. Isso significa que uma chamada para flask.render_template() ainda é necessária, portanto, a importação do Flask. Como não há framework da Web, não é necessário instanciar um app Flask. Portanto, exclua app = Flask(__name__). Seu código vai ficar assim antes e depois de aplicar as mudanças:

ANTES:

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

AFTER:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

Se você depender do objeto app (app) ou de qualquer outra infraestrutura de framework da Web, resolva todas essas dependências, encontrando soluções alternativas adequadas, removendo o uso delas completamente ou encontrando proxies. Só então é possível converter o código em uma função do Cloud. Caso contrário, é melhor ficar no App Engine ou colocar o app em contêiner para o Cloud Run.

Atualizar a assinatura da função do gerenciador principal

As mudanças necessárias na assinatura da função são as seguintes:

  1. O Flask não é mais usado depois de converter o app em uma função do Cloud, então remova os decoradores de rota.
  2. O Cloud Functions transmite automaticamente o objeto Request do Flask como um parâmetro. Portanto, crie uma variável para ele. No nosso app de exemplo, vamos chamar de request.
  3. As funções do Cloud implantadas precisam ter um nome. Nosso gerenciador principal foi chamado adequadamente de root() no App Engine para descrever o que ele era (o gerenciador de aplicativos raiz). Como uma função do Cloud, não faz muito sentido usar esse nome. Em vez disso, vamos implantar a Cloud Function com o nome visitme. Use esse nome também para a função Python. Da mesma forma, nos módulos 4 e 5, também nomeamos o serviço do Cloud Run como visitme.

Confira o antes e o depois com essas atualizações:

ANTES:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

AFTER:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

Concluímos todas as atualizações necessárias. As mudanças feitas só afetaram o código de "infraestrutura" do aplicativo. Nenhuma mudança é necessária no código principal do aplicativo, e nenhuma funcionalidade dele foi alterada. Confira uma representação ilustrativa das mudanças feitas para demonstrar esse ponto:

668f30e3865b27a9.png

Desenvolvimento e teste locais

Enquanto o App Engine tem o dev_appserver.py servidor de desenvolvimento local, o Cloud Functions tem o Functions Framework. Com essa estrutura, é possível desenvolver e testar localmente. Seu código pode ser implantado no Cloud Functions, mas também em outras plataformas de computação, como o Compute Engine, o Cloud Run ou até mesmo em sistemas locais ou de nuvem híbrida compatíveis com o Knative. Confira abaixo mais links para o Functions Framework.

6. Criar e implantar

A implantação no Cloud Functions é um pouco diferente da implantação no App Engine. Como nenhum arquivo de configuração é usado fora de requirements.txt, mais informações sobre o código precisam ser especificadas na linha de comando. Implante sua nova função do Cloud acionada por HTTP executada em Python 3.10 com este comando:

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

A saída será semelhante a esta:

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

Depois que a função for implantada, use o URL da saída da implantação e acesse o app. O URL tem o seguinte formato: REGION-PROJECT_ID.cloudfunctions.net/visitme. A saída precisa ser idêntica à de quando você implantou o app no App Engine:

2732ae9218f011a2.png

Assim como na maioria dos outros codelabs e vídeos da série, a funcionalidade básica do app não muda. O objetivo é aplicar uma técnica de modernização e fazer com que o app funcione exatamente como antes, mas com uma infraestrutura mais recente. Por exemplo, migrar de um serviço legado mais antigo do App Engine para o produto independente do Cloud que o substituiu ou, como neste tutorial, mover um app para outra plataforma sem servidor do Google Cloud.

7. Resumo/limpeza

Parabéns por converter este pequeno app do App Engine em uma função do Cloud Functions. Outro caso de uso adequado: dividir um grande app monolítico do App Engine em uma série de microsserviços, cada um como uma função do Cloud. Essa é uma técnica de desenvolvimento mais moderna que resulta em um componente mais "plug-and-play" (como a pilha JAM). Ele permite misturar e combinar, além de reutilizar o código, que são dois objetivos. Outro benefício é que esses microsserviços continuam sendo depurados com o tempo, o que significa código estável e custos de manutenção gerais mais baixos.

Limpar

Depois de concluir este codelab, você pode desativar o app do App Engine do módulo 2 (temporariamente ou permanentemente) para evitar cobranças. A plataforma do App Engine tem uma cota sem custo financeiro. Assim, você não vai receber cobranças enquanto permanecer no nível de uso dela. O mesmo se aplica ao Datastore. Consulte a página de preços do Cloud Datastore para mais detalhes.

A implantação em plataformas como o App Engine e o Cloud Functions gera custos mínimos de build e armazenamento. Em algumas regiões, o Cloud Build e o Cloud Storage têm cotas sem custo financeiro próprias. As builds consomem parte dessa cota. Monitore seu uso do armazenamento para minimizar possíveis custos, principalmente se sua região não tiver um nível sem custo financeiro.

Infelizmente, o Cloud Functions não tem um recurso de "desativação". Faça backup do código e exclua a função. Você pode fazer isso de novo com o mesmo nome depois. No entanto, se você não quiser continuar com outros codelabs de migração e quiser excluir tudo completamente, desligar seus projetos do Cloud.

Próximas etapas

Além deste tutorial, outros módulos de migração incluem a conteinerização do seu app do App Engine para o Cloud Run. Confira os links para os codelabs do Módulo 4 e do Módulo 5:

  • Módulo 4: migrar para o Cloud Run com o Docker
  • Contentorize seu app para ser executado no Cloud Run com o Docker
  • Essa migração permite que você permaneça no Python 2.
  • 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.
  • Requer que seu app já tenha sido migrado para o Python 3 (o Buildpack não é compatível com o Python 2)

Muitos dos outros módulos se concentram em mostrar aos desenvolvedores como migrar dos serviços agrupados do App Engine para substituições autônomas do Cloud:

  • Módulo 2: migrar do App Engine ndb para o Cloud NDB
  • Módulos 7 a 9: migrar das tarefas push da fila de tarefas do App Engine para o Cloud Tasks
  • Módulos 12 e 13: migrar do Memcache do App Engine para o Cloud Memorystore
  • Módulos 15 e 16: migrar do Blobstore do App Engine para o Cloud Storage
  • Módulos 18 e 19: migrar da fila de tarefas do App Engine (tarefas pull) para o Cloud Pub/Sub

Se a contêinerização se tornou parte do seu fluxo de trabalho de desenvolvimento de aplicativos, principalmente se ele consistir em um pipeline de CI/CD (integração contínua/entrega ou implantação contínua), considere migrar para o Cloud Run em vez do Cloud Functions. 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 Dockerfiles. Seja considerando o Cloud Functions ou o Cloud Run, a mudança para outra plataforma sem servidor é opcional. Recomendamos que você considere as melhores opções para seus apps e casos de uso antes de fazer qualquer mudança.

Independente do módulo de migração que você considerar em seguida, 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 oferece orientações sobre quais migrações considerar e a "ordem" relevante dos módulos de migração.

8. 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 repositório do módulo 8 (START) e Módulo 9 (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 3

Módulo 2

código

Módulo 11

código

Recursos on-line

Confira abaixo recursos on-line que podem ser relevantes para este tutorial:

App Engine

Cloud Functions

Outras informações da nuvem

Vídeos

Licença

Este conteúdo está sob a licença Atribuição 2.0 Genérica da Creative Commons.