Migrar um Node.js do Cloud do App Engine para Python 2 e App Cloud Tasks para Python 3 e Cloud Datastore (módulo 9)

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.

O objetivo deste codelab é fazer a portabilidade do app de exemplo do Módulo 8 para o Python 3, além de mudar o acesso ao Datastore (Cloud Firestore no modo Datastore) do uso do Cloud NDB para a biblioteca de cliente nativa do Cloud Datastore e fazer upgrade para a versão mais recente da biblioteca de cliente do Cloud Tasks.

Adicionamos o uso da fila de tarefas para tarefas de push no Módulo 7 e migramos esse uso para o Cloud Tasks no Módulo 8. Neste módulo 9, vamos continuar com o Python 3 e o Cloud Datastore. Quem usa filas de tarefas para tarefas pull vai migrar para o Cloud Pub/Sub e deve consultar os módulos 18 e 19.

Você vai aprender a

  • Portar o app de exemplo do módulo 8 para o Python 3
  • Mudar o acesso ao Datastore do Cloud NDB para as bibliotecas de cliente do Cloud Datastore
  • Fazer upgrade para a versão mais recente da biblioteca de cliente do Cloud Tasks

O que é necessário

Pesquisa

Como você usará este tutorial?

Apenas leitura Leitura e 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 Módulo 7 demonstra como usar tarefas push da fila de tarefas do App Engine em apps Python 2 Flask App Engine. No Módulo 8, você migra esse app da fila de tarefas para o Cloud Tasks. No Módulo 9, você continua essa jornada e porta o app para o Python 3, além de mudar o acesso ao Datastore do uso do Cloud NDB para a biblioteca de cliente nativa do Cloud Datastore.

Como o Cloud NDB funciona para Python 2 e 3, ele é suficiente para usuários do App Engine que fazem a portabilidade dos apps do Python 2 para o 3. Uma migração adicional de bibliotecas de cliente para o Cloud Datastore é completamente opcional, e há apenas um motivo para considerar isso: você tem apps que não são do App Engine (e/ou apps do App Engine Python 3) que já usam a biblioteca de cliente do Cloud Datastore e quer consolidar sua base de código para acessar o Datastore com apenas uma biblioteca de cliente. O Cloud NDB foi criado especificamente para desenvolvedores do App Engine em Python 2 como uma ferramenta de migração para Python 3. Portanto, se você ainda não tiver um código usando a biblioteca de cliente do Cloud Datastore, não precisa considerar essa migração.

Por fim, o desenvolvimento da biblioteca de cliente do Cloud Tasks continua apenas no Python 3. Portanto, estamos "migrando" de uma das versões finais do Python 2 para a versão equivalente do Python 3. Felizmente, não há mudanças incompatíveis do Python 2, o que significa que não é preciso fazer mais nada aqui.

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ê comece com um código funcional e que ele esteja pronto para migração para os serviços do Cloud.

1. Configurar projeto

Se você concluiu o codelab do Módulo 8, reutilize 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 um app do App Engine ativado. Encontre o ID do projeto, porque você vai precisar dele durante este codelab. Use-o sempre que encontrar a variável PROJECT_ID.

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

Um dos pré-requisitos é um app do App Engine do Módulo 8 em funcionamento. Conclua o codelab do Módulo 8 (recomendado) ou copie o app do Módulo 8 do repositório. Não importa se você usa o seu ou o nosso, o código do Módulo 8 é onde vamos começar ("START"). Este codelab orienta você na migração, concluindo com um código semelhante ao que está na pasta do repositório do Módulo 9 ("FINISH").

Independente do app do Módulo 7 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 e validar o app de referência

Siga estas etapas para implantar o app do módulo 8:

  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 pip2 se você tiver o Python 2 e o 3 instalados na sua máquina de desenvolvimento.
  2. Verifique se você instalou e inicializou a ferramenta de linha de comando gcloud e se revisou o uso dela.
  3. (Opcional) Defina seu projeto na nuvem com gcloud config set project PROJECT_ID se não quiser inserir PROJECT_ID com cada comando gcloud emitido.
  4. Implante o app de exemplo com gcloud app deploy
  5. Confirme se o app é executado conforme o esperado sem problemas. Se você concluiu o codelab do módulo 8, o app mostra os principais visitantes e as visitas mais recentes (ilustrado abaixo). Na parte de baixo, há uma indicação das tarefas mais antigas que serão excluídas.

4aa8a2cb5f527079.png

4. Atualizar a configuração

requirements.txt

O novo requirements.txt é quase igual ao do módulo 8, com apenas uma grande mudança: substitua google-cloud-ndb por google-cloud-datastore. Faça essa mudança para que seu arquivo requirements.txt fique assim:

flask
google-cloud-datastore
google-cloud-tasks

Esse arquivo requirements.txt não tem números de versão, o que significa que as versões mais recentes estão selecionadas. Se houver incompatibilidades, o uso de números de versão para bloquear versões funcionais de um app é uma prática padrão.

app.yaml

O ambiente de execução do App Engine de segunda geração não oferece suporte a bibliotecas de terceiros integradas, como na versão 2.x, nem à cópia de bibliotecas não integradas. O único requisito para pacotes de terceiros é listá-los em requirements.txt. Como resultado, toda a seção libraries de app.yaml pode ser excluída.

Outra atualização é que o ambiente de execução do Python 3 exige o uso de frameworks da Web que fazem o próprio roteamento. Como resultado, todos os gerenciadores de script precisam ser alterados para auto. No entanto, como todas as rotas precisam ser alteradas para auto, e não há arquivos estáticos disponibilizados por esse app de exemplo, é irrelevante ter qualquer gerenciador. Portanto, remova também toda a seção handlers.

A única coisa necessária em app.yaml é definir o ambiente de execução para uma versão compatível do Python 3, como 3.10. Faça essa mudança para que o novo app.yaml abreviado seja apenas esta linha:

runtime: python310

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:

  1. Nenhuma biblioteca de terceiros auto-empacotada ou copiada. Liste-as 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. Nenhuma ficha integrada de terceiros (portanto, nenhuma seção libraries) em app.yaml. Liste-as em requirements.txt.
  4. 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.

5. Atualizar arquivos do aplicativo

Há apenas um arquivo de aplicativo, main.py, então todas as mudanças nesta seção afetam apenas esse arquivo. Abaixo, há uma ilustração de "diferenças" sobre as mudanças gerais que precisam ser feitas para refatorar o código atual no novo app. Não é necessário ler o código linha por linha. O objetivo é apenas ter uma visão geral do que é necessário nessa refatoração. Se quiser, abra em uma nova guia ou faça o download e aumente o zoom.

5d043768ba7be742.png

Atualizar importações e inicialização

A seção de importação em main.py do módulo 8 usa o Cloud NDB e o Cloud Tasks. Ela deve ter esta aparência:

ANTES:

from datetime import datetime
import json
import logging
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import ndb, tasks

app = Flask(__name__)
ds_client = ndb.Client()
ts_client = tasks.CloudTasksClient()

A geração de registros é simplificada e aprimorada nos ambientes de execução de segunda geração, como o Python 3:

  • Para uma experiência abrangente de geração de registros, use o Cloud Logging.
  • Para um registro simples, basta enviar para stdout (ou stderr) via print()
  • Não é necessário usar o módulo logging do Python. Portanto, remova-o.

Portanto, exclua a importação de logging e troque google.cloud.ndb por google.cloud.datastore. Da mesma forma, mude ds_client para apontar para um cliente do Datastore em vez de um cliente do NDB. Com essas mudanças, a parte de cima do novo app vai ficar assim:

AFTER:

from datetime import datetime
import json
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import datastore, tasks

app = Flask(__name__)
ds_client = datastore.Client()
ts_client = tasks.CloudTasksClient()

Migrar para o Cloud Datastore

Agora é hora de substituir o uso da biblioteca de cliente NDB pelo Datastore. O App Engine NDB e o Cloud NDB exigem um modelo de dados (classe). Para este app, é Visit. A função store_visit() funciona da mesma forma em todos os outros módulos de migração: ela registra uma visita criando um novo registro Visit, salvando o endereço IP e o user agent (tipo de navegador) de um cliente visitante.

ANTES:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

No entanto, o Cloud Datastore não usa uma classe de modelo de dados. Portanto, exclua a classe. Além disso, o Cloud Datastore não cria automaticamente um carimbo de data/hora quando os registros são criados. É necessário fazer isso manualmente com a chamada datetime.now().

Sem a classe de dados, seu store_visit() modificado vai ficar assim:

AFTER:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    entity = datastore.Entity(key=ds_client.key('Visit'))
    entity.update({
        'timestamp': datetime.now(),
        'visitor': '{}: {}'.format(remote_addr, user_agent),
    })
    ds_client.put(entity)

A função principal é fetch_visits(). Ele não apenas executa a consulta original para os Visits mais recentes, mas também extrai o carimbo de data/hora do último Visit exibido e cria a tarefa de envio por push que chama /trim (portanto, trim()) para excluir em massa os Visits antigos. Confira como ele usa o Cloud NDB:

ANTES:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    with ds_client.context():
        data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return (v.to_dict() for v in data), oldest_str

As principais mudanças:

  1. Troque a consulta do Cloud NDB pelo equivalente do Cloud Datastore. Os estilos de consulta são um pouco diferentes.
  2. O Datastore não exige o uso de um gerenciador de contexto nem a extração de dados (com to_dict()), como o Cloud NDB.
  3. Substituir chamadas de geração de registros por print()

Depois de essas mudanças, o fetch_visits() vai ficar assim:

AFTER:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

Normalmente, isso é tudo o que é necessário. Infelizmente, há um problema grave.

(Possivelmente) Criar uma nova fila (push)

No Módulo 7, adicionamos o uso do taskqueue do App Engine ao app do Módulo 1. Um dos principais benefícios de ter tarefas push como um recurso legado do App Engine é que uma fila "padrão" é criada automaticamente. Quando esse app foi migrado para o Cloud Tasks no Módulo 8, a fila padrão já estava lá. Por isso, ainda não precisávamos nos preocupar com ela. Isso muda aqui no Módulo 9.

Um aspecto importante a considerar é que o novo aplicativo do App Engine não usa mais os serviços do App Engine. Portanto, não é mais possível presumir que o App Engine cria automaticamente uma fila de tarefas em um produto diferente (Cloud Tasks). Como está escrito, a criação de uma tarefa em fetch_visits() (para uma fila inexistente) vai falhar. Uma nova função é necessária para verificar se a fila ("default") existe e, se não, criar uma.

Chame essa função de _create_queue_if() e adicione-a ao aplicativo logo acima de fetch_visits(), porque é onde ela é chamada. O corpo da função a ser adicionada:

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

A função create_queue() do Cloud Tasks exige o caminho completo do nome da fila ,exceto o nome da fila. Para simplificar, crie outra variável PATH_PREFIX representando o QUEUE_PATH menos o nome da fila (QUEUE_PATH.rsplit('/', 2)[0]). Adicione a definição dela perto da parte de cima para que o bloco de código com todas as atribuições de constantes fique assim:

_, PROJECT_ID = google.auth.default()
REGION_ID = 'REGION_ID'    # replace w/your own
QUEUE_NAME = 'default'     # replace w/your own
QUEUE_PATH = ts_client.queue_path(PROJECT_ID, REGION_ID, QUEUE_NAME)
PATH_PREFIX = QUEUE_PATH.rsplit('/', 2)[0]

Agora modifique a última linha em fetch_visits() para usar _create_queue_if(), primeiro criando a fila, se necessário, e criando a tarefa depois:

    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

Agora, _create_queue_if() e fetch_visits() vão ficar assim no agregado:

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

Além de ter que adicionar esse código extra, o restante do código do Cloud Tasks permanece praticamente intacto desde o Módulo 8. A última parte do código a ser analisada é o gerenciador de tarefas.

Atualizar o gerenciador de tarefas (push)

No manipulador de tarefas, trim(), o código do Cloud NDB consulta visitas mais antigas do que a mais antiga exibida. Ele usa uma consulta somente de chaves para acelerar as coisas. Por que buscar todos os dados se você só precisa dos IDs de visita? Depois de ter todos os IDs de visita, exclua-os em lote com a função delete_multi() do Cloud NDB.

ANTES:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    with ds_client.context():
        keys = Visit.query(
                Visit.timestamp < datetime.fromtimestamp(oldest)
        ).fetch(keys_only=True)
        nkeys = len(keys)
        if nkeys:
            logging.info('Deleting %d entities: %s' % (
                    nkeys, ', '.join(str(k.id()) for k in keys)))
            ndb.delete_multi(keys)
        else:
            logging.info(
                    'No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

Assim como fetch_visits(), a maior parte das mudanças envolve a troca do código do Cloud NDB pelo Cloud Datastore, o ajuste dos estilos de consulta, a remoção do uso do gerenciador de contexto e a mudança das chamadas de registro para print().

AFTER:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    query = ds_client.query(kind='Visit')
    query.add_filter('timestamp', '<', datetime.fromtimestamp(oldest))
    query.keys_only()
    keys = list(visit.key for visit in query.fetch())
    nkeys = len(keys)
    if nkeys:
        print('Deleting %d entities: %s' % (
                nkeys, ', '.join(str(k.id) for k in keys)))
        ds_client.delete_multi(keys)
    else:
        print('No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

Não há mudanças no gerenciador principal do aplicativo root().

Portar para o Python 3

Este app de exemplo foi projetado para ser executado no Python 2 e no Python 3. Todas as mudanças específicas do Python 3 foram abordadas anteriormente nas seções relevantes deste tutorial. Não são necessárias etapas adicionais nem bibliotecas de compatibilidade.

Atualização do Cloud Tasks

A versão final da biblioteca de cliente do Cloud Tasks compatível com o Python 2 é a 1.5.0. No momento em que este artigo foi escrito, a versão mais recente da biblioteca de cliente para Python 3 era totalmente compatível com essa versão. Portanto, não são necessárias mais atualizações.

Atualização do modelo HTML

Nenhuma mudança é necessária no arquivo de modelo HTML, templates/index.html. Assim, concluímos todas as mudanças necessárias para chegar ao app do módulo 9.

6. Resumo/limpeza

Implantar e verificar o aplicativo

Depois de concluir as atualizações de código, principalmente a portabilidade para o Python 3, implante o app com gcloud app deploy. A saída deve ser idêntica aos apps dos módulos 7 e 8, exceto que você moveu o acesso ao banco de dados para a biblioteca de cliente do Cloud Datastore e fez upgrade para o Python 3:

App visitme do módulo 7

Esta etapa conclui o codelab. Compare seu código com o que está na pasta do módulo 9. Parabéns!

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

Isso conclui nossa migração das tarefas push da fila de tarefas do App Engine para o Cloud Tasks. A migração opcional do Cloud NDB para o Cloud Datastore também é abordada por conta própria (sem a fila de tarefas ou o Cloud Tasks) no Módulo 3. Além do módulo 3, há outros módulos de migração focados na transição dos serviços agrupados legados do App Engine. Considere:

  • Módulo 2: migrar do NDB do App Engine para o NDB do Cloud
  • Módulo 3: migrar do Cloud NDB para o Cloud Datastore
  • 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: fila de tarefas do App Engine (tarefas de extração) para o Cloud Pub/Sub

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

Problemas/feedback dos codelabs

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 2

Python 3

Módulo 8

código

(n/a)

Módulo 9

(n/a)

código

Recursos on-line

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

App Engine

Cloud NDB

Cloud Datastore

Cloud Tasks

Outras informações da nuvem

Licença

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