Extensão do suporte para serviços incluídos no App Engine: parte 1 (módulo 17)

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.

Antes, os desenvolvedores precisavam migrar dos "serviços agrupados" legados do App Engine, como o Datastore e o Memcache, antes de fazer upgrade das versões de linguagem, duas tarefas potencialmente desafiadoras em sequência. Ao disponibilizar muitos dos principais serviços agrupados no serviço do App Engine de segunda geração, os desenvolvedores agora podem migrar os apps para os ambientes de execução mais recentes e continuar usando (a maioria) dos serviços agrupados. Este codelab mostra como fazer upgrade de um app de exemplo do Python 2 para o 3, mantendo o uso do serviço incluído do Datastore (pela biblioteca NDB do App Engine). O uso da maioria dos serviços agrupados exige apenas uma pequena atualização no código, como será abordado neste tutorial. No entanto, há outros que exigem mudanças mais extensas, que serão abordadas na "Parte 2", um módulo e codelab de acompanhamento.

Você vai aprender a

  • Portar um app de amostra do App Engine do Python 2 para o 3
  • Atualizar a configuração do app para incluir o SDK do App Engine
  • Adicione o código do SDK ao app para oferecer suporte a serviços agrupados em ambientes de execução de segunda geração, como Python 3.

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

O serviço original do App Engine foi lançado em 2008 e veio com um conjunto de APIs legadas (agora conhecidas como serviços agrupados) para facilitar a criação e implantação de aplicativos globalmente pelos desenvolvedores. Esses serviços incluem Datastore, Memcache e Task Queue. Embora convenientes, os usuários começaram a se preocupar com a portabilidade dos apps ao usar APIs proprietárias que os vinculavam ao App Engine e queriam que os apps fossem mais portáteis. Isso, junto com o fato de que muitos desses serviços incluídos estão amadurecendo para se tornarem produtos independentes do Cloud, levou a equipe do App Engine a lançar a plataforma de próxima geração em 2018 sem eles.

Hoje, os desenvolvedores do Python 2 estão ansiosos para fazer upgrade para o Python 3. Um app 2.x que usa serviços agrupados precisava ser migrado para fora desses serviços antes de ser portado para a versão 3.x, representando um par de migrações forçadas consecutivas, que também podem ser desafiadoras. Para ajudar nessa transição, a equipe do App Engine apresentou no outono de 2021 um "buraco de minhoca" para o passado, permitindo que apps executados em ambientes de execução de próxima geração acessem muitos desses serviços incluídos. Embora essa versão não inclua todos os serviços disponíveis nos ambientes de execução originais, os principais, como Datastore, Task Queue e Memcache, estão disponíveis.

Este codelab demonstra as mudanças necessárias para fazer upgrade do app para o Python 3, preservando o uso de serviços agrupados. O objetivo é fazer com que seus apps sejam executados nos ambientes de execução mais recentes, permitindo que você migre dos serviços em pacote para equivalentes autônomos do Cloud ou alternativas de terceiros no seu próprio ritmo, em vez de ser um bloqueador para um upgrade para a versão 3.x. Embora não seja mais necessário migrar dos serviços agrupados, isso oferece mais portabilidade e flexibilidade em termos de onde seus apps podem ser hospedados, incluindo a mudança para plataformas que podem atender melhor às suas cargas de trabalho ou simplesmente permanecer no App Engine enquanto faz upgrade para uma versão de linguagem mais moderna, conforme descrito acima.

O app de exemplo do Módulo 1 em Python 2 usa o serviço em pacote do Datastore pelo App Engine NDB. O app já migrou frameworks do webapp2 para o Flask, concluído no codelab do Módulo 1, mas com o uso do Datastore intacto.

Este tutorial inclui as seguintes etapas:

  1. Configuração/Pré-trabalho
  2. Atualizar a configuração
  3. Modificar o código do aplicativo

3. Configuração/Pré-trabalho

Esta seção explica como:

  1. Configurar seu projeto do Cloud
  2. Receber app de amostra do valor de referência
  3. (Re)Implantar e validar o app de referência

Essas etapas garantem que você esteja começando com um código funcional.

1. Configurar projeto

Se você concluiu o codelab do Módulo 1, recomendamos reutilizar o mesmo projeto (e código). Se preferir, crie um novo projeto na nuvem ou reutilize outro projeto existente. Verifique se o projeto tem uma conta de faturamento ativa em que o serviço do App Engine foi ativado.

2. Receber app de amostra do valor de referência

Um dos pré-requisitos para este codelab é ter um app do App Engine do Módulo 1 em funcionamento. Conclua o codelab do Módulo 1 (recomendado) ou copie o app do Módulo 1 do repositório. Independentemente de você usar o nosso ou o seu, o código do Módulo 1 é o que vamos "COMEÇAR". Este codelab orienta você em cada etapa, concluindo com um código semelhante ao que está na pasta "FINISH" do repositório do Módulo 7.

Independente do app do Módulo 1 que você usar, a pasta vai ser parecida com a abaixo, possivelmente com uma pasta lib também:

$ ls
README.md               appengine_config.py     requirements.txt
app.yaml                main.py                 templates

3. (Re) Implantar aplicativo de referência

Siga estas etapas para (re)implantar o app do módulo 1:

  1. Exclua a pasta lib se houver uma e execute: pip install -t lib -r requirements.txt para preencher lib novamente. Talvez seja necessário usar o comando pip2 se você tiver o Python 2 e o 3 instalados.
  2. Verifique se você instalou e inicializou a ferramenta de linha de comando gcloud e revisou o uso dela.
  3. Defina seu projeto na nuvem com gcloud config set project PROJECT_ID se não quiser inserir seu PROJECT_ID com cada comando gcloud emitido.
  4. Implante o app de exemplo com gcloud app deploy
  5. Confirme se o app do módulo 1 está funcionando como esperado, sem problemas ao mostrar as visitas mais recentes (ilustrado abaixo).

a7a9d2b80d706a2b.png

4. Atualizar a configuração

Depois de executar essas etapas e verificar se o web app funciona, você estará pronto para migrar o app para o Python 3, começando com a configuração.

Adicionar SDK a requirements.txt

O ambiente de execução do Python 3 do App Engine reduz significativamente a sobrecarga do uso de bibliotecas de terceiros. Basta listá-las em requirements.txt. Para usar os serviços incluídos no Python 3, adicione o pacote do SDK do App Engine, appengine-python-standard, a ele. O pacote do SDK se junta ao Flask do Módulo 1:

flask
appengine-python-standard

Atualizar o app.yaml

Siga as etapas abaixo para aplicar as mudanças de configuração ao arquivo app.yaml:

  1. Substitua a diretiva runtime pela versão compatível do Python 3. Por exemplo, especifique python310 para o Python 3.10.
  2. Exclua as diretivas threadsafe e api_version, já que nenhuma delas é usada no Python 3.
  3. Exclua toda a seção handlers, já que esse app só tem gerenciadores de script. Se o app tiver gerenciadores de arquivos estáticos, deixe-os intactos em handlers.
  4. O ambiente de execução do Python 3 não é compatível com bibliotecas integradas de terceiros, como o ambiente de execução do Python 2. Se seu app tiver uma seção libraries em app.yaml, exclua toda a seção. Os pacotes obrigatórios só precisam ser listados em requirements.txt, como bibliotecas não integradas. Nosso app de exemplo não tem uma seção libraries. Portanto, vá para a próxima etapa.
  5. Crie um conjunto de diretivas app_engine_apis definido como true para usá-lo. Isso corresponde a adicionar o pacote do SDK do App Engine a requirements.txt acima.

Resumo das mudanças necessárias em app.yaml:

ANTES:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

AFTER:

runtime: python310
app_engine_apis: true

Outros arquivos de configuração

Como todos os pacotes de terceiros só precisam ser listados em requirements.txt, a menos que você tenha algo especial em appengine_config.py, ele não é necessário. Portanto, exclua-o. Da mesma forma, como todas as bibliotecas de terceiros são instaladas automaticamente durante o processo de build, não é necessário copiá-las ou vendê-las. Isso significa que não há mais o comando pip install nem a pasta lib. Portanto, exclua-os. Resumindo:

  • Excluir arquivo appengine_config.py
  • Excluir lib pasta?

Isso conclui todas as mudanças de configuração necessárias.

5. Modificar o código do aplicativo

Para acessar a maioria dos serviços incluídos disponíveis no ambiente de execução do Python 3, é necessário um pequeno trecho de código que encapsula o objeto de aplicativo da interface de gateway do servidor da Web (WSGI) em main.py. A função de wrapper é google.appengine.api.wrap_wsgi_app(). Para usá-la, importe e encapsule o objeto WSGI com ela. Faça as mudanças abaixo para refletir a atualização necessária do Flask em main.py:

ANTES:

from flask import Flask, render_template, request
from google.appengine.ext import ndb

app = Flask(__name__)

AFTER:

from flask import Flask, render_template, request
from google.appengine.api import wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)

Consulte a documentação para exemplos de encapsulamento do WSGI em outros frameworks Python.

Embora esse exemplo funcione para dar ao app acesso à maioria dos serviços em pacote no Python 3, outros, como o Blobstore e o Mail, exigem código adicional. Vamos abordar essas amostras em outro módulo de migração.

Concluímos todas as mudanças necessárias para adicionar o uso de serviços incluídos do App Engine ao app de exemplo do módulo 1. O aplicativo já é compatível com Python 2 e 3. Portanto, não há outras mudanças para portar para o Python 3 além do que você já fez na configuração. A etapa final é implantar esse app modificado no ambiente de execução do Python 3 do App Engine de próxima geração e confirmar se as atualizações foram bem-sucedidas.

6. Resumo/limpeza

Esta seção conclui o codelab implantando o app e verificando se ele funciona conforme o esperado e em qualquer saída refletida. Depois da validação do app, faça uma limpeza e pense nas próximas etapas.

Implantar e verificar o aplicativo

Implante o app Python 3 com gcloud app deploy e confirme se ele funciona como no Python 2. Nenhuma funcionalidade muda, então a saída deve ser idêntica ao app do Módulo 1:

a7a9d2b80d706a2b.png

Observações finais

Parabéns por dar o primeiro passo para portar seus apps do App Engine em Python 2 para Python 3, mantendo o uso dos serviços incluídos por enquanto.

Limpar

Geral

Se você terminou por enquanto, recomendamos que desative o app do App Engine para evitar cobranças. No entanto, se você quiser testar ou experimentar mais, a plataforma do App Engine tem uma cota sem custo financeiro. Portanto, enquanto você não exceder esse nível de uso, não vai receber cobranças. Isso é para computação, mas também pode haver cobranças por serviços relevantes do App Engine. Consulte a página de preços para mais informações. Se essa migração envolver outros serviços do Cloud, eles serão cobrados separadamente. Em qualquer caso, se aplicável, consulte a seção "Específico para este codelab" abaixo.

Para total transparência, a implantação em uma plataforma de computação sem servidor do Google Cloud, como o App Engine, gera custos mínimos de build e armazenamento. O Cloud Build e o Cloud Storage têm cotas sem custo financeiro próprias. O armazenamento dessa imagem usa parte dessa cota. No entanto, talvez você more em uma região que não tem um nível sem custo financeiro. Por isso, fique de olho no uso do armazenamento para minimizar possíveis custos. As "pastas" específicas do Cloud Storage que você precisa analisar incluem:

  • console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
  • console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
  • Os links de armazenamento acima dependem da sua PROJECT_ID e *LOC*ação. Por exemplo, "us" se o app estiver hospedado nos EUA.

Por outro lado, se você não quiser continuar com este aplicativo ou outros codelabs de migração relacionados e quiser excluir tudo completamente, desligue seu projeto.

Específico para este codelab

Os serviços listados abaixo são exclusivos deste codelab. Consulte a documentação de cada produto para mais informações:

Próximas etapas

Há várias opções a partir daqui:

  1. Atualizar o código usando serviços agrupados que exigem mais mudanças no código
  2. Migrar de serviços agrupados para produtos autônomos do Cloud
  3. Migrar do App Engine para outra plataforma sem servidor do Cloud

O acesso a outros serviços agrupados, como Blobstore, Mail e Deferred, exige mais mudanças no código. Os módulos de migração que se concentram em migrar dos serviços agrupados legados do App Engine incluem:

O App Engine não é mais a única plataforma sem servidor no Google Cloud. Se você tem um app pequeno do App Engine ou um com funcionalidade limitada e quer transformá-lo em um microsserviço independente, ou se quer dividir um app monolítico em vários componentes reutilizáveis, esses são bons motivos para considerar a migração para o Cloud Functions. 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. Esses cenários são abordados nos seguintes módulos:

  • Migrar do App Engine para o Cloud Functions: consulte o Módulo 11
  • Migrar do App Engine para o Cloud Run: consulte o Módulo 4 para contentorizar seu app com o Docker ou o Módulo 5 para fazer isso sem contêineres, conhecimento do Docker ou Dockerfiles

A mudança 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.

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.

7. Outros recursos

Confira abaixo mais recursos para desenvolvedores que querem saber mais sobre este ou outros módulos de migração e produtos relacionados. Isso inclui locais para enviar feedback sobre o conteúdo, links para o código e vários documentos que podem ser úteis.

Problemas/feedback do codelab

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 1 (START) e do Módulo 1b (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.

Codelab

Python 2

Python 3

Módulo 1

código

N/A

Módulo 17 (este codelab)

N/A

code (mod1b-flask)

Recursos on-line

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

Pacotes de serviços do App Engine

Documentação geral do App Engine

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.