Como usar o Memcache do App Engine em apps Flask (módulo 12)

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.

Este codelab ensina a incluir e usar o Memcache do App Engine no app de exemplo do codelab do módulo 1. Adicionamos o uso do Memcache neste tutorial do Módulo 12, depois migraremos 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 aplicativo Python 2 Flask básico do App Engine NoSQL

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

Para migrar do Memcache do App Engine, adicione o uso dele ao app Flask e do App Engine NFS resultante do codelab do módulo 1. O app de exemplo mostra as dez visitas mais recentes ao usuário. Se o mesmo usuário atualizar o navegador, não é ideal criar continuamente novas entidades de visita e buscar as visitas mais recentes do Datastore, portanto, armazenaremos essas visitas mais recentes em cache.

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 tiver passado uma hora, 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 migrá-la para o Cloud Memorystore no próximo codelab (módulo 13).

Este tutorial apresenta 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

Antes de chegarmos à parte principal do tutorial, vamos configurar nosso projeto, obter o código e, em seguida, implantar o aplicativo de referência para sabermos que começamos com o código de trabalho.

1. Configurar projeto

Se você concluiu o codelab do Módulo 1, 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 e se o App Engine está 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 1 em funcionamento. Se você não tiver um, conclua um dos tutoriais (links acima) antes de prosseguir. Caso você já esteja 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 e conclui com um código semelhante ao que está na pasta de repositórios do Módulo 11 (FINISH).

O diretório dos arquivos de inicialização do Módulo 1 (seus ou nossos) deve se parecer com isto:

$ 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 e conferir que seu app da Web funciona (com uma saída semelhante à mostrada abaixo), você poderá usar o armazenamento em cache.

a7a9d2b80d706a2b.png

4. Atualizar a configuração

Nenhuma alteração é necessária nos arquivos de configuração padrão do App Engine (app.yaml, requirements.txt, appengine_config.py).

5. Modificar arquivos do aplicativo

Como estamos adicionando apenas uma API do App Engine, não há pacotes externos envolvidos, o que significa que nenhum arquivo de configuração (app.yaml, requirements.txt, appengine_config.py) precisa ser atualizado. Como há apenas um arquivo de aplicativo, main.py, todas as mudanças feitas na 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 a aparência do código antes e essa mudança:

ANTES:

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

app = Flask(__name__)

DEPOIS:

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 ao Memcache

A mudança mais significativa é a adição do uso de armazenamento em cache em nosso aplicativo. Mais especificamente, devemos armazenar as visitas mais recentes em cache, verificar se as visitas armazenadas em cache estão disponíveis e tentar usar os resultados armazenados 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:

  1. Definir visita atual e chamá-la de visitor
  2. Tentativa de buscar o visits mais recente do cache
  3. Se o cache estiver vazio ou o visitante mais recente (visits[0]['visitor']) for diferente do visitor atual: armazene essa visita mais recente, busque as visitas mais recentes e armazene-as em cache por uma hora.
  4. Mostrar visits ao usuário usando o modelo da Web

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:

@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)

Veja aqui uma representação pictórica das mudanças feitas:

b1242503602f7bf0.png

Isso conclui 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 que ele funcione.

6. Resumo/limpeza

Esta seção encerra este codelab implantando o app, verificando se ele funciona conforme o esperado e em qualquer saída refletida. Após a validação do app, execute as etapas de limpeza e considere as próximas etapas.

Implante e verifique o aplicativo

Implante o app novamente com gcloud app deploy e confirme se ele funciona. Seu código agora deve 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 que você implantou anteriormente:

a7a9d2b80d706a2b.png

Tudo o que fizemos foi acelerar a experiência do usuário para o mesmo usuário. Quando eles são atualizados, você deve receber os resultados diretamente do cache, que não cria uma nova visita nem faz uma busca no Datastore.

Parabéns por concluir o codelab do Módulo 12 sobre como incluir o uso do serviço memcache do App Engine ao nosso aplicativo de exemplo. Agora você tem a opção de transferir esse aplicativo Python 2 para o Python 3 na etapa bônus.

Limpar

Geral

Se você já tiver terminado por enquanto, recomendamos que desative seu aplicativo do App Engine para evitar cobranças. No entanto, se você quiser fazer mais testes, saiba que a plataforma do App Engine tem uma cota sem custo financeiro e, desde que você não exceda esse nível de uso, não haverá cobranças. Isso é para computação, mas também pode haver cobranças por serviços relevantes do App Engine. Portanto, consulte a página de preços para mais informações. Se essa migração envolver outros serviços do Cloud, eles serão faturados separadamente. Em ambos os casos, se aplicável, consulte a seção "Específico para este codelab". seção abaixo.

Para divulgação completa, a implantação em uma plataforma de computação sem servidor do Google Cloud, como o App Engine, incorre em menores custos de criação e armazenamento. O Cloud Build tem a própria cota sem custo financeiro, assim como o Cloud Storage. O armazenamento da imagem consome parte da cota. No entanto, talvez você more em uma região que não tenha esse nível sem custo financeiro, portanto, esteja ciente do uso do armazenamento para minimizar os possíveis custos. "Pastas" específicas do Cloud Storage que você deve 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 do PROJECT_ID e da *LOC*ação, por exemplo, "us" caso seu app esteja hospedado nos EUA.

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

Específicos deste 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 dois tipos diferentes, cada um com a própria estrutura de preços. Portanto, é necessário rastrear esse uso no que diz respeito 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, que mostra aos desenvolvedores como migrar do serviço memcache do App Engine para o Cloud Memorystore. Essas migrações são opcionais e estão disponíveis aos usuários que querem seguir várias etapas para modernizar os aplicativos. O serviço Cloud Memorystore é um upgrade significativo para o memcache do App Engine por diversos 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 os fatores podem ter um impacto significativo nos custos.
  • O Cloud Memorystore é compatível com um par de diferentes mecanismos de armazenamento subjacentes (mecanismos de cache), Redis e Memcached.
  • O Cloud Memorystore (para Redis) tem um conjunto de recursos muito mais completo e aprofundado que o Memcache do App Engine.
  • Para usar o Cloud Memorystore, é necessário configurar um servidor do Cloud Memorystore, adicioná-lo a uma rede VPC do Google Cloud e fazer com que o aplicativo do App Engine use essa rede para se comunicar com o servidor do Memorystore.

Se você não precisar de todos os recursos disponíveis no Cloud Memorystore ou se estiver preocupado com seus efeitos no custo, fique à vontade para usar o Memcache do App Engine.

Além do módulo 13, há uma série de outras migrações possíveis, como o Cloud NBS, o Cloud Datastore ou o Cloud Tasks. Há também migrações entre produtos para o Cloud Run e o Cloud Functions. Você encontra todas elas no repositório de migração.

Outra próxima etapa possível é a portabilidade para Python 3, que será abordada na próxima seção como uma etapa opcional.

7. BÔNUS: migração para Python 3

Visão geral

Esta seção é composta de conteúdo bônus opcional sobre a migração do aplicativo do módulo 12 que acabamos de terminar para o Python 3. Começamos com a configuração seguida pelo 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 conteúdo de app.yaml no fim 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 frameworks da Web façam o próprio roteamento, todos os gerenciadores de rota em app.yaml precisam ser alterados para auto. Se não houver arquivos estáticos exibidos, os usuários poderão simplesmente remover toda a seção handlers:. Além disso, o uso de threadsafe e api_version foi descontinuado.

DEPOIS:

Com as mudanças necessárias descritas, este é o substituto app.yaml do Python 3:

runtime: python39
app_engine_apis: true

A única linha que precisa de explicação é app_engine_apis: true. Quando os serviços legados do App Engine foram disponibilizados para ambientes de execução de segunda geração em 2021, alguns deles, incluindo o Python 3, vão precisar de mais bootstrap para acessar essas APIs, como ndb, taskqueue e memcache. Essa linha na configuração atende a esse propósito.

Atualizar requirements.txt

Outro bootstrapping das APIs originais é necessário em requirements.txt: o acesso ao novo SDK do App Engine precisa ser incluído.

ANTES:

Confira abaixo o conteúdo de app.yaml no fim do Módulo 12:

flask

DEPOIS:

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 de última geração do App Engine 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 têm permissão para 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 "fornecimento" ou "autoagrupamento") em ambientes de execução de segunda geração. Em vez disso, elas precisam estar listadas em requirements.txt, em que o sistema de build as instala automaticamente em seu nome no momento da implantação.

Como resultado dessas mudanças no gerenciamento de pacotes de terceiros, o arquivo appengine_config.py e a pasta lib não são necessários. Portanto, exclua-os. Nos ambientes de execução de segunda geração, o App Engine instala automaticamente pacotes de terceiros listados em requirements.txt. Resumindo:

  1. Sem bibliotecas de terceiros copiadas ou agrupadas. liste-os em requirements.txt
  2. Não há pip install em uma pasta lib, o que significa que não há um período de pasta lib
  3. Não há uma lista de bibliotecas integradas de terceiros (sem a seção libraries) no app.yaml. listá-los em requirements.txt
  4. Não há bibliotecas de terceiros para referenciar no app, o que significa que não há um arquivo appengine_config.py

O único requisito para desenvolvedores é listar todas as bibliotecas de terceiros no requirements.txt.

Atualizar o aplicativo para usar o SDK do App Engine

Como mencionado acima, os aplicativos Python 3 exigem algumas modificações para acessar os serviços incluídos no App Engine:

  1. Pacote do SDK do App Engine (em requirements.txt)
  2. Ativar o SDK do App Engine (em app.yaml)
  3. Unir objeto WSGI (em main.py)

O primeiro par foi concluído acima, então o último requisito é atualizar main.py.

ANTES:

Confira abaixo o main.py do Python 2 na conclusão 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

DEPOIS:

Para a porta do Python 3, importe o SDK e una o objeto do app Flask com ele (o wrapper do SDK). Isso terá o seguinte resultado:

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 alterações nos aplicativos Python ao fazer a portabilidade da versão 2.x para a 3.x para acessar os serviços agrupados. Se você não estiver usando Flask, há também exemplos de Django e Pyramid na documentação. Se o código Python 2 não for um app da Web, incluir apenas o pacote do SDK será suficiente para fazer a portabilidade para o Python 3. Nosso código do aplicativo foi criado originalmente para funcionar em Python 2 e 3. Portanto, nenhuma outra alteração de compatibilidade é necessária.

Implante o aplicativo

Depois de concluir as alterações acima, você poderá implantar o app de amostra atualizado. Não há problemas ao implantar uma versão Python 3 do seu aplicativo em vez de uma versão original do 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 no 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 do 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 conferir as próximas etapas e limpeza.

8. Outros recursos

Abaixo estão listados recursos adicionais para desenvolvedores que querem explorar melhor esse Módulo de migração ou o relacionado, assim como produtos relacionados. Isso inclui locais para fornecer feedback sobre esse conteúdo, links para o código e várias documentações 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 (INÍCIO) e do Módulo 12 (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 2

Python 3

Módulo 1

código

code (não apresentado neste tutorial)

Módulo 12 (este codelab)

código

código

Referências on-line

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

App Engine

Cloud Memorystore e Cloud Datastore

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.