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

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.

Há situações em que você não tem "todo o app" 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. Este codelab ensina como migrar aplicativos simples do App Engine (ou dividir aplicativos maiores em vários microsserviços) e implantá-los no Cloud Functions, outra plataforma sem servidor criada especificamente para casos de uso como esse.

Você vai aprender a

  • Usar o Cloud Shell
  • Ative a API Google Cloud Translation
  • Autenticar as solicitações de API
  • Converter um pequeno aplicativo 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. Com essas plataformas sem servidor, sua equipe técnica pode se concentrar na criação de soluções empresariais, em vez de gastar tempo investigando as plataformas para usar e determinar a quantidade necessária de hardware. Os aplicativos podem escalonar automaticamente conforme necessário e reduzir a zero com o pagamento por utilização para controlar os custos. Além disso, eles permitem várias linguagens de desenvolvimento comuns atualmente.

No entanto, embora o desenvolvimento de aplicativos da Web de pilha completa ou back-ends complexos para aplicativos móveis seja uma ótima opção para o App Engine, muitas vezes os desenvolvedores estão tentando colocar algumas funcionalidades on-line, como atualizar um feed de notícias ou conferir a pontuação mais recente do jogo do time da casa. Embora exista uma lógica de programação para os dois cenários, nenhum parece ser "aplicação" completa que não precisam dos recursos do App Engine. É aí que entra o Cloud Functions.

O Cloud Functions é usado para implantar pequenas partes do código que:

  • não fazem parte de um aplicativo inteiro.
  • não é necessária em toda a pilha de desenvolvimento.
  • 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 uma função ou um microsserviço conteinerizado e executado sem servidor no Cloud Run, também é possível fazer isso.

Nosso aplicativo de exemplo do App Engine que aparece em quase todos os tutoriais de migração é um aplicativo curto com funcionalidade básica que funciona bem no Cloud Functions. Neste tutorial, você vai aprender a modificar esse app para execução no Cloud Functions. Da perspectiva do App Engine, como as funções são mais simples do que aplicativos inteiros, sua experiência inicial deve ser mais fácil (e mais rápida) e 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 Python 3 do aplicativo de exemplo do App Engine para Cloud NBS do módulo 2 porque o Cloud Functions não é compatível com o Python 2. Primeiro, vamos configurar nosso projeto, receber o código e implantar o app de referência para confirmar que estamos começando com o código de trabalho.

1. Configurar projeto

Se você concluiu o codelab do Módulo 2 (e o transferiu para o Python 3), recomendamos reutilizar o mesmo projeto e código. Outra opção é criar um novo projeto ou reutilizar um projeto existente. 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 deste codelab é ter um app de exemplo do Módulo 2 em funcionamento. Se você não tiver uma, conclua um dos tutoriais mencionados acima antes de prosseguir. Caso você já esteja familiarizado com o conteúdo, comece com o código do Módulo 2 abaixo.

Não importa se você usa o seu ou o nosso, o código Python 3 do Módulo 2 é onde vamos INICIAR. Este codelab do Módulo 11 orienta você em cada etapa e conclui com um código semelhante ao que está na pasta de repositório do Módulo 11 (FINISH).

O diretório dos arquivos INÍCIOS do Módulo 2 do Python 3 (os seus ou os nossos) deverá 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, você poderá convertê-las em uma função do Cloud.

4. Remover arquivos de configuração

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

Se você também estiver transferindo um aplicativo do App Engine do Python 2 para o Python 3, exclua appengine_config.py e a pasta lib, se houver. Eles são artefatos do App Engine não utilizados no ambiente de execução do Python 3.

5. Modificar arquivos do aplicativo

Como há apenas um arquivo de aplicativo, main.py, todas as mudanças necessárias para migrar para o Cloud Functions ocorrem nele.

Importações

Como só trabalhamos com funções, não é necessário ter uma estrutura de aplicativo da Web. No entanto, por conveniência, quando Cloud Functions baseadas em Python são chamadas, elas recebem automaticamente um objeto de solicitação para seu código usar conforme necessário. A equipe do Cloud Functions selecionou esse objeto como um objeto de solicitação Flask transmitido para sua função.

Como os frameworks da Web não fazem parte do cenário do Cloud Functions, não são feitas importações do Flask, a menos que seu app use outros recursos dessa biblioteca. Esse é o nosso caso, já que a renderização do modelo ainda ocorre após a conversão para uma função, o que significa que ainda é necessário chamar flask.render_template(). Portanto, ele é importado do Flask. A ausência de framework da Web significa que não é necessário instanciar um app Flask. Portanto, exclua app = Flask(__name__). O código vai ficar assim, antes e depois da aplicação das mudanças:

ANTES:

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

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

DEPOIS:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

Se você depende do objeto do app (app) ou de qualquer outra infraestrutura de framework da Web, precisa resolver todas essas dependências, encontrar soluções alternativas adequadas, remover totalmente o uso ou encontrar proxies. Só depois disso você poderá converter seu código em uma função do Cloud. Caso contrário, é melhor continuar no App Engine ou conteinerizar seu app para o Cloud Run

Atualizar 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 após a conversão do app em uma função do Cloud. Portanto, 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 chamá-lo de request.
  3. As funções do Cloud implantadas precisam ser nomeadas. Nosso gerenciador principal recebeu o nome root() adequado no App Engine para descrever o que era o gerenciador de aplicativos raiz. Como uma função do Cloud, não faz menos sentido usar esse nome. Em vez disso, implantaremos a função do Cloud com o nome visitme. Portanto, use-a como o nome da função do Python também. Da mesma forma, nos Módulos 4 e 5, também nomeamos o serviço do Cloud Run de visitme.

Confira o que acontece antes e depois dessas 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)

DEPOIS:

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)

Isso conclui todas as atualizações necessárias. Observe que as alterações feitas afetaram apenas a "infraestrutura" do aplicativo o código-fonte. Nenhuma mudança é necessária no código principal do aplicativo, e a funcionalidade do app não foi alterada. Aqui está uma representação pictórica das alterações que foram feitas para ilustrar este ponto:

668f30e3865b27a9.png

Desenvolvimento e teste locais

Enquanto o App Engine tem o servidor de desenvolvimento local do dev_appserver.py, o Cloud Functions tem o Functions Framework. Com esse framework, é possível desenvolver e testar localmente. É possível implantar seu código no Cloud Functions ou em outras plataformas de computação, como o Compute Engine, o Cloud Run ou até mesmo em sistemas de nuvem híbrida ou no local com suporte ao Knative. Veja abaixo links adicionais para o Functions Framework.

6. Criar e implantar

A implantação no Cloud Functions é um pouco diferente da implantação do 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 a nova função do Cloud acionada por HTTP em execução no 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'

Após a implantação da função, use o URL da saída da implantação e acesse o app. O URL tem o formato: REGION-PROJECT_ID.cloudfunctions.net/visitme. A resposta será idêntica à de quando você o implantou anteriormente no App Engine:

2732ae9218f011a2.png

Assim como na maioria dos outros codelabs e vídeos da série, a funcionalidade de referência do app não vai mudar. O objetivo é aplicar uma técnica de modernização e fazer com que o app funcione exatamente como antes, mas com uma infraestrutura mais nova. Por exemplo, migrar de um serviço legado do App Engine mais antigo para um produto autônomo do Cloud substituto ou, como no caso deste tutorial, mover um app para outra plataforma sem servidor do Google Cloud.

7. Resumo/limpeza

Parabéns por converter este pequeno aplicativo do App Engine em uma função do Cloud. Outro caso de uso apropriado: dividir um aplicativo grande e 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 uma (como "pilha JAM"). Ela permite mistura e correspondência e reutilização de código, que são duas metas, mas outro benefício é que esses microsserviços continuarão sendo depurados ao longo do tempo, o que significa código estável e menor custo geral de manutenção.

Limpar

Após concluir este codelab, você poderá desativar o app do App Engine do Módulo 2 (temporariamente ou permanentemente) para evitar incorrer em cobranças. A plataforma do App Engine tem uma cota sem custo financeiro, então você não será cobrado enquanto permanecer dentro do nível de uso. 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 incorre em menores custos de build e armazenamento. Em algumas regiões, o Cloud Build tem a própria cota sem custo financeiro, assim como o Cloud Storage. Os builds consomem parte dessa cota. Esteja ciente do uso do armazenamento para minimizar os possíveis custos, especialmente se sua região não tiver um nível sem custo financeiro desse tipo.

O Cloud Functions não tem uma função "desativar" . Faça backup do código e exclua a função. Você poderá reimplantá-lo com o mesmo nome depois. No entanto, se você não for continuar com outros codelabs de migração e quiser excluir tudo completamente, encerre seus projetos do Cloud.

Próximas etapas

Além deste tutorial, outros módulos de migração que serão abordados incluem a conteinerização do seu aplicativo do App Engine para Cloud Run. Consulte os links para os codelabs dos Módulos 4 e 5:

  • Módulo 4: migrar para o Cloud Run com 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 mostram aos desenvolvedores como migrar dos serviços agrupados do App Engine para substituições independentes do Cloud:

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

Se a conteinerização se tornou parte do fluxo de trabalho de desenvolvimento de aplicativos, principalmente se consiste em um pipeline de CI/CD (integração/entrega contínua ou implantação), 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 com o Cloud Functions ou o Cloud Run, mudar 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.

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 (INÍCIO) e do Módulo 9 (FINISH) podem ser encontrados na tabela abaixo. Eles também podem ser acessados no repositório de todas as migrações de codelab do App Engine. 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

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

App Engine

Cloud Functions

Outras informações sobre a nuvem

Vídeos

Licença

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