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.
Neste codelab, você vai aprender a incluir e usar o Memcache do App Engine no app de exemplo do codelab do módulo 1. Vamos adicionar o uso do Memcache neste tutorial do módulo 12 e, em seguida, migrar para o Cloud Memorystore no módulo 13.
Você vai aprender a
- Usar a API/biblioteca Memcache do App Engine
- Adicionar armazenamento em cache a um app básico do App Engine NDB em Python 2 Flask
O que é necessário
- Um projeto do Google Cloud Platform com uma conta de faturamento do GCP ativa
- Habilidades básicas em Python
- Conhecimento prático de comandos comuns do Linux
- Conhecimento básico sobre desenvolvimento e implantação de apps do App Engine
- Um aplicativo do App Engine do Módulo 1 funcional. Conclua o codelab (recomendado) ou copie o app do repositório.
Pesquisa
Como você vai usar este tutorial?
Como você classificaria sua experiência com Python?
Como você classificaria sua experiência de uso dos serviços do Google Cloud?
2. Contexto
Para migrar do Memcache do App Engine, adicione o uso dele ao app Flask e App Engine NDB resultante do codelab do módulo 1. O app de exemplo mostra as dez visitas mais recentes do usuário. Se o mesmo usuário atualizar o navegador, não será ideal criar continuamente novas entidades de visita e buscar as visitas mais recentes do Datastore. Por isso, vamos armazenar em cache essas visitas mais recentes.
Se o mesmo visitante acessar a página, essas visitas serão retornadas do cache. Se um novo usuário visitar o site ou se uma hora tiver passado, o cache será limpo e substituído pelas entradas mais recentes (sem mencionar uma nova visita registrada). Com essa integração do Memcache do App Engine implementada, podemos migrar para o Cloud Memorystore no próximo codelab (Módulo 13).
Este tutorial inclui as seguintes etapas:
- Configuração/Pré-trabalho
- Atualizar a configuração
- Modificar o código 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 o codelab do Módulo 1, 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 se o App Engine está ativado.
2. Receber app de amostra do valor de referência
Um dos pré-requisitos para este codelab é ter um app de exemplo do Módulo 1. Se você não tiver um, conclua qualquer um dos tutoriais (links acima) antes de continuar. Caso contrário, se você já estiver familiarizado com o conteúdo, comece com o código do Módulo 1 abaixo.
Independentemente de você usar o nosso ou o nosso, o código do Módulo 1 é o que faremos. Este codelab orienta você em cada etapa, concluindo com um código semelhante ao que está na pasta do repositório do Módulo 11 (FINISH).
- INICIAR: Pasta do módulo 1 (Python 2)
- CONCLUIR: pasta do módulo 12 (Python 2)
- Repositório completo (para clonar ou fazer o download do arquivo ZIP)
O diretório dos arquivos do Módulo 1 (seus ou nossos) deve ter esta 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:
- Conheça melhor a ferramenta de linha de comando
gcloud - Reimplantar o aplicativo de amostra com
gcloud app deploy - Confirmar se o aplicativo é executado no App Engine sem problemas
Depois de executar essas etapas com sucesso e verificar se o app da Web funciona (com uma saída semelhante à abaixo), você estará pronto para adicionar o uso de armazenamento em cache ao app.

4. Atualizar a configuração
Não é necessário fazer mudanças nos arquivos de configuração padrão do App Engine (app.yaml, requirements.txt, appengine_config.py).
5. Modificar arquivos do aplicativo
Como estamos apenas adicionando uma API do App Engine, não há pacotes externos envolvidos. Isso significa que não é necessário atualizar arquivos de configuração (app.yaml, requirements.txt, appengine_config.py). Há apenas um arquivo de aplicativo, main.py, então todas as mudanças nesta seção afetam apenas esse arquivo.
Importações
A etapa mais importante é importar a biblioteca do Memcache, google.appengine.api.memcache. Como vamos armazenar em cache as visitas mais recentes por uma hora, também vamos adicionar uma constante para o número de segundos em uma hora. Confira abaixo como o código fica antes e depois dessa mudança:
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 memcache
from google.appengine.ext import ndb
app = Flask(__name__)
HOUR = 3600
Adicionar armazenamento em cache com suporte do Memcache
A mudança mais significativa é adicionar o uso de armazenamento em cache no nosso aplicativo. Mais especificamente, precisamos armazenar em cache as visitas mais recentes, verificar se as visitas em cache estão disponíveis e tentar usar os resultados em cache o máximo possível, de acordo com nosso plano. Estas são as etapas que o app vai seguir para alcançar nossa meta:
- Defina a visita atual e chame-a de
visitor. - Tentar buscar o
visitsmais recente do cache - Se o cache estiver vazio ou o visitante mais recente (
visits[0]['visitor']) for diferente dovisitoratual: armazene essa visita mais recente, busque as visitas mais recentes e as armazene em cache por uma hora. - Mostrar
visitsao usuário pelo modelo da Web
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:
@app.route('/')
def root():
'main application (GET) handler'
# check for (hour-)cached visits
ip_addr, usr_agt = request.remote_addr, request.user_agent
visitor = '{}: {}'.format(ip_addr, usr_agt)
visits = memcache.get('visits')
# register visit & run DB query if cache empty or new visitor
if not visits or visits[0]['visitor'] != visitor:
store_visit(ip_addr, usr_agt)
visits = list(fetch_visits(10))
memcache.set('visits', visits, HOUR) # set() not add()
return render_template('index.html', visits=visits)
Confira uma representação ilustrada das mudanças feitas:

Concluímos todas as mudanças necessárias para adicionar o uso do App Engine memcache ao app de exemplo do Módulo 1. Vamos criar e implantar esse app para conferir o funcionamento dele.
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 as etapas de limpeza e considere as próximas etapas.
Implantar e verificar o aplicativo
Implante o app novamente com gcloud app deploy e confirme se ele funciona. Agora, seu código precisa corresponder ao que está em FINISH, a pasta do módulo 12. A saída precisa ser idêntica ao app do Módulo 1 implantado anteriormente:

A única coisa que fizemos foi acelerar a experiência do mesmo usuário. Quando eles atualizarem, você vai receber os resultados diretamente do cache, o que não cria uma nova visita nem faz uma busca do Datastore.
Parabéns por concluir o codelab do módulo 12 para adicionar o uso do serviço memcache do App Engine ao nosso aplicativo de exemplo. Agora você tem a opção de fazer a portabilidade desse app Python 2 para o Python 3 na etapa bônus.
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/imagesconsole.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com- Os links de armazenamento acima dependem da sua
PROJECT_IDe *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:
- O serviço Memcache do App Engine tem duas versões diferentes, cada uma com sua própria estrutura de preços. Portanto, é necessário acompanhar esse uso em relação ao faturamento.
- O serviço App Engine Datastore é fornecido pelo Cloud Datastore (Cloud Firestore no modo Datastore), que também tem um nível sem custo financeiro. Consulte a página de preços para mais informações.
Próximas etapas
A próxima migração lógica a ser considerada é abordada no Módulo 13, mostrando aos desenvolvedores como migrar do serviço memcache do App Engine para o Cloud Memorystore. Todas essas migrações são opcionais e estão disponíveis para usuários que querem modernizar os aplicativos. O serviço Cloud Memorystore é uma atualização significativa do memcache do App Engine por vários motivos:
- O Cloud Memorystore não é sem servidor. Isso significa que você precisa alocar um servidor para o cache. O Cloud Memorystore também não tem um nível sem custo financeiro. Ambos podem ter um impacto significativo no custo.
- O Cloud Memorystore é compatível com dois mecanismos de armazenamento subjacentes diferentes (mecanismos de cache): Redis e Memcached.
- O Cloud Memorystore (para Redis) tem um conjunto de atributos muito mais rico e detalhado do que o Memcache do App Engine.
- Para usar o Cloud Memorystore, configure um servidor do Cloud Memorystore, adicione-o a uma rede VPC do Google Cloud e faça com que o app do App Engine use essa rede para se comunicar com o servidor do Memorystore.
Se você não acha que precisa de todos os recursos disponíveis no Cloud Memorystore ou está preocupado com os efeitos dele no custo, pode continuar usando o Memcache do App Engine.
Além do Módulo 13, há várias outras migrações possíveis, como Cloud NDB e Cloud Datastore ou Cloud Tasks. Também há migrações entre produtos para o Cloud Run e o Cloud Functions. Você pode encontrar todos eles no repositório de migração.
Outra possível próxima etapa é a migração para o Python 3, que é abordada na próxima seção como uma etapa opcional.
7. BÔNUS: migração para Python 3
Visão geral
Esta seção inclui conteúdo bônus opcional que migra o aplicativo do módulo 12 que acabamos de concluir para o Python 3. Começamos com a configuração e depois o aplicativo.
Simplifique o app.yaml
Um dos benefícios do ambiente de execução do Python 3 é que o app.yaml pode ser significativamente simplificado.
ANTES:
Confira abaixo o que está em app.yaml após a conclusão do Módulo 12:
runtime: python27
threadsafe: yes
api_version: 1
handlers:
- url: /.*
script: main.app
Como o ambiente de execução do Python 3 exige que os frameworks da Web façam o próprio roteamento, todos os gerenciadores de rotas em app.yaml precisam ser alterados para auto. Se não houver arquivos estáticos sendo veiculados, os usuários poderão remover toda a seção handlers:. Além disso, threadsafe e api_version foram descontinuados.
AFTER:
Com as mudanças necessárias descritas acima, este é o app.yaml substituto para Python 3:
runtime: python39
app_engine_apis: true
A única linha que precisa de uma explicação é app_engine_apis: true. Quando os serviços legados do App Engine ficaram disponíveis para ambientes de execução de segunda geração em 2021, alguns ambientes de execução, incluindo o Python 3, exigiram bootstrapping adicional para acessar essas APIs, como ndb, taskqueue e memcache. Essa linha na configuração tem essa finalidade.
Atualizar requirements.txt
Outra inicialização das APIs originais é necessária em requirements.txt: o acesso ao novo SDK do App Engine precisa ser incluído.
ANTES:
Veja abaixo o que está em app.yaml após a conclusão do Módulo 12:
flask
AFTER:
Basta adicionar o SDK do App Engine para Python, e você terá o seguinte:
flask
appengine-python-standard
Excluir appengine_config.py e lib
Os ambientes de execução do App Engine de última geração reformulam o uso de pacotes de terceiros:
- As bibliotecas integradas são aquelas verificadas pelo Google e disponibilizadas nos servidores do App Engine, provavelmente porque contêm código C/C++ que os desenvolvedores não podem implantar na nuvem. Elas não estão mais disponíveis nos ambientes de execução de segunda geração.
- Não é mais necessário copiar bibliotecas não integradas (às vezes chamadas de "vendoring" ou "self-bundling") em ambientes de execução de segunda geração. Em vez disso, eles precisam ser listados em
requirements.txt, em que o sistema de build os instala automaticamente em seu nome no momento da implantação.
Como resultado dessas mudanças no gerenciamento de pacotes de terceiros, não é necessário ter o arquivo appengine_config.py nem a pasta lib. Portanto, exclua esses itens. Nos ambientes de execução de segunda geração, o App Engine instala automaticamente os pacotes de terceiros listados em requirements.txt. Resumindo:
- Nenhuma biblioteca de terceiros auto-empacotada ou copiada. Liste-as em
requirements.txt. - Não há
pip installem uma pastalib, o que significa que não há um período de pastalib - Nenhuma ficha integrada de terceiros (portanto, nenhuma seção
libraries) emapp.yaml. Liste-as emrequirements.txt. - Não há bibliotecas de terceiros para referenciar no app, o que significa que não há arquivo
appengine_config.py
Listar todas as bibliotecas de terceiros desejadas em requirements.txt é o único requisito do desenvolvedor.
Atualizar o aplicativo para usar o SDK do App Engine
Como mencionado acima, os apps Python 3 exigem algumas modificações para acessar os serviços incluídos do App Engine:
- Agrupar o SDK do App Engine (em
requirements.txt) - Ativar o SDK do App Engine (em
app.yaml) - Unir objeto WSGI (em
main.py)
O primeiro par foi concluído acima. Portanto, o último requisito é atualizar main.py.
ANTES:
Confira abaixo o main.py do Python 2 ao final do Módulo 12:
from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb
app = Flask(__name__)
HOUR = 3600
AFTER:
Para a porta do Python 3, importe o SDK e encapsule o objeto do app Flask com ele (o wrapper do SDK), resultando no seguinte:
from flask import Flask, render_template, request
from google.appengine.api import memcache, wrap_wsgi_app
from google.appengine.ext import ndb
app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
HOUR = 3600
Os desenvolvedores precisam fazer essas mudanças nos apps Python ao migrar da versão 2.x para a 3.x para acessar os serviços agrupados. Se você não estiver usando o Flask, também há exemplos de Django e Pyramid na documentação. Se o código do Python 2 não for um app da Web, basta incluir o pacote do SDK ao fazer a portabilidade para o Python 3. O código do aplicativo foi originalmente criado para funcionar com Python 2 e 3, então não são necessárias outras mudanças de compatibilidade.
Implante o aplicativo
Depois de concluir as mudanças acima, você pode implantar o app de exemplo atualizado. Não há problema em implantar uma versão do app em Python 3 sobre uma versão original em Python 2 no mesmo projeto do GCP. O comportamento do app deve permanecer o mesmo. Se você precisar comparar seu app atualizado com o nosso, consulte a pasta do módulo 12b no repositório de migração. Para saber mais sobre o suporte aos serviços incluídos do App Engine nos ambientes de execução mais recentes, como o Python 3, consulte o anúncio de lançamento do recurso e o codelab do módulo 17.
Parabéns por concluir a etapa bônus no Módulo 12! Consulte também a documentação sobre como preparar arquivos de configuração para o ambiente de execução do Python 3. Consulte a seção "Resumo/Limpeza" acima para ver as próximas etapas e fazer a limpeza.
8. 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 2 (START) e do Módulo 12 (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 |
código (não abordado neste tutorial) | ||
Módulo 12 (este codelab) |
Referências on-line
Confira abaixo recursos on-line que podem ser relevantes para este tutorial:
App Engine
- Documentação do App Engine
- Tempo de execução do Python 2 no App Engine (ambiente padrão)
- Tempo de execução do Python 3 no App Engine (ambiente padrão)
- Diferenças entre os ambientes de execução do Python 2 e 3 no App Engine (ambiente padrão)
- Guia de migração do App Engine (ambiente padrão) do Python 2 para o 3
- Informações sobre preços e cotas do App Engine
- Lançamento da plataforma App Engine de segunda geração (2018)
- Comparação entre plataformas de primeira e segunda geração
- Suporte de longo prazo para ambientes de execução legados
- Repositório de exemplos de migração da documentação
- Repositório de exemplos de migração gerado pela comunidade
Cloud Memorystore e Cloud Datastore
- Página do produto Cloud Memorystore
- Documentação do Cloud Memorystore para Redis
- Documentação do Cloud Memorystore para Memcached
- Informações sobre preços do Cloud Memorystore (para Redis)
- Documentação do Cloud Datastore
- Informações de preços do Cloud Datastore
Outras informações da nuvem
- Python no Google Cloud Platform
- Bibliotecas de cliente do Python para Google Cloud
- Nível "Sempre sem custo financeiro" do Google Cloud
- SDK do Google Cloud (ferramenta de linha de comando
gcloud) - Toda a documentação do Google Cloud
Vídeos
- Serverless Migration Station (em inglês)
- Expedições sem servidor
- Inscreva-se no Google Cloud Tech
- Inscreva-se no Google Developers
Licença
Este conteúdo está sob a licença Atribuição 2.0 Genérica da Creative Commons.