A maior parte da funcionalidade fornecida pelos serviços incluídos legados agora é fornecida pelas Bibliotecas de cliente do Cloud. Para mais informações, consulte as alternativas recomendadas listadas abaixo.
Se a migração para uma solução desagrupada não for uma opção para seu projeto, talvez seja possível continuar usando serviços agrupados legados nos apps Python 3 como substitutos. Essa abordagem oferece flexibilidade para migrar para serviços desagrupados posteriormente no ciclo de migração.
Depois de migrar dos serviços incluídos legados, você pode continuar usando o App Engine ou migrar para o Cloud Run. O Cloud Run foi desenvolvido para melhorar a experiência do App Engine e incorpora muitos dos melhores recursos do ambiente padrão e do ambiente flexível. Para comparar recursos e entender a migração, consulte o guia de comparação entre o App Engine e o Cloud Run.
Google Cloud oferece produtos independentes com funcionalidade semelhante a alguns dos serviços legados incluídos no ambiente de execução do Python. Para os serviços legados incluídos que não estão disponíveis como produtos separados no Google Cloud, como e-mail e mensagens, este guia recomenda provedores de terceiros ou outras soluções alternativas.
Nesta página, apresentamos o caminho de migração para os serviços incluídos legados.
Entender as permissões do Google Cloud
O app migrado e os serviços do Google Cloud que ele usa não estão sendo executados no mesmo ambiente em sandbox, e o app precisa de autorização para acessar cada serviço. Por exemplo, para interagir com o Firestore no modo Datastore (Datastore) ou o Cloud Tasks, seu app precisa fornecer as credenciais de uma conta que está autorizada a acessar esses serviços.
Por padrão, os apps executados no ambiente padrão do App Engine fornecem as credenciais da conta de serviço padrão do App Engine, que está autorizada a acessar bancos de dados no mesmo projeto que o app.
Se alguma das seguintes condições for verdadeira, use um método de autenticação alternativo que forneça credenciais explicitamente:
Seu app e o banco de dados do Memorystore estão em projetos diferentes doGoogle Cloud .
Você alterou os papéis atribuídos à conta de serviço padrão do App Engine.
Para saber mais sobre métodos de autenticação alternativos, consulte Como configurar a autenticação em aplicativos de produção de servidor para servidor.
Autenticação para desenvolvimento local
Para desenvolver ou testar seu app localmente, crie e use uma conta de serviço. Não use a conta de serviço padrão do App Engine porque ela tem permissões amplas para seu projeto. Em vez disso, crie e use uma conta de serviço com as permissões mínimas necessárias para suas tarefas específicas de desenvolvimento e teste.
Para configurar uma conta de serviço e conectá-la ao seu app, consulte Como receber e fornecer credenciais da conta de serviço manualmente.
Instalar bibliotecas de cliente
Para usar os serviços do Google Cloud em um app Python, instale a biblioteca de cliente Python do serviço.Os serviços do Google Cloud também oferecem APIs REST e outras interfaces.
Para instalar uma biblioteca de cliente para o ambiente de execução do Python 3:
Adicione o nome da biblioteca ao arquivo
requirements.txtdo app. Exemplo:google-cloud-ndb
O App Engine faz o upload automático de todas as bibliotecas listadas no
arquivo requirements.txt para o ambiente de execução do Python 3.
Caminhos de migração para serviços incluídos no App Engine
Blobstore
Para armazenar e recuperar dados, use o Cloud Storage por meio das bibliotecas de cliente do Cloud. Para começar, consulte Como usar o Cloud Storage e o Guia sobre como migrar do Blobstore para o Cloud Storage. Para simular essa migração, adicione o uso do Blobstore a um app de exemplo e migre para o Cloud Storage.
Datastore
Se o aplicativo Python 2 usa o NDB para interagir com o Datastore, migre para a biblioteca do Cloud NDB. O Cloud NDB é usado principalmente como uma ferramenta de transição para a migração de aplicativos em Python 2. Recomendamos que os apps Python 3 usem a biblioteca de cliente do modo Datastore.
Veja mais detalhes em Como migrar para o Cloud NBS. Para simular essa migração com um aplicativo de amostra, consulte Como migrar do ndb do App Engine para o Cloud NDB.
Imagens
É possível veicular imagens a partir do Cloud Storage, veiculá-las diretamente ou usar uma rede de fornecimento de conteúdo (CDN) terceirizada.
Para redimensionar, converter e manipular imagens, use uma biblioteca de processamento de imagens, como Pillow ou uma interface Python para o ImageMagick.
Para usar uma dessas bibliotecas de terceiros, adicione a biblioteca como uma dependência e atualize seu código para chamar as APIs da biblioteca.
O serviço de imagens do App Engine também oferece funcionalidades para evitar solicitações dinâmicas ao seu aplicativo. Para isso, ele realiza o redimensionamento de imagens por meio de um URL de exibição. Se você quiser uma funcionalidade semelhante, será possível gerar as imagens redimensionadas com antecedência e enviá-las ao Cloud Storage para exibição. Como alternativa, é possível é usar um serviço de rede de fornecimento de conteúdo (CDN) de terceiros que ofereça redimensionamento de imagens.
Geração de registros
Recomendamos que você atualize o aplicativo para usar o Cloud Logging, que é compatível com
recursos como ver registros no explorador, fazer o download de registros, filtrar
mensagens por nível de gravidade e correlacionar mensagens de apps com solicitações específicas. Como alternativa, se preferir a simplicidade em vez da precisão dos dados, você pode gravar registros estruturados em stdout ou stderr.
Para mais informações, consulte Como gravar e visualizar registros e Como migrar para o Cloud Logging.
Memcache
Para armazenar os dados do aplicativo em cache, use o Memorystore para Redis.
Para detalhes, consulte Migrar o Memcache para o Memorystore. Para simular essa migração, adicione o uso do Memcache a um app de exemplo e migre para o Memorystore para Redis.
Para aplicativos que usam Memcache apenas para reduzir a latência para solicitações NDB (ou Cloud NDB), use o suporte integrado do Cloud NDB para Redis em vez de Memcache ou Memorystore para Redis.
Módulos
Para obter informações e modificar os serviços em execução do aplicativo, use uma combinação de variáveis de ambiente e a API App Engine Admin:
| Informações de serviços | Como acessar |
|---|---|
| ID do aplicativo atual | Por meio da variável de ambiente GAE_APPLICATION. |
| ID do projeto atual | Por meio da variável de ambiente GOOGLE_CLOUD_PROJECT. |
| Nome do serviço atual | Por meio da variável de ambiente GAE_SERVICE. |
| Versão do serviço atual | Por meio da variável de ambiente GAE_VERSION. |
| ID da instância atual | Por meio da variável de ambiente GAE_INSTANCE. |
| Nome do host padrão | Método apps.get da API Admin |
| Lista de serviços | Método apps.services.list da API Admin |
| Lista de versões de um serviço | Método apps.services.versions.list da API Admin |
| Versão padrão de um serviço, incluindo qualquer divisão de tráfego | Método apps.services.get da API Admin |
| Lista de instâncias em execução de uma versão | Método apps.services.versions.instances.list da API Admin |
Para mais informações sobre os dados disponíveis sobre os serviços em execução do seu aplicativo, consulte o ambiente de execução do Python 3 .
Namespaces
A API Namespaces permite que os aplicativos multilocatários particionem dados por locatários simplesmente especificando uma string de namespace exclusiva para cada locatário.
Enquanto o Datastore suporta multilocação diretamente, outros Google Cloud serviços não. Se o aplicativo multilocatário usa outros serviços do Google Cloud, você precisa processar a multilocação manualmente. Para ter instâncias de serviços completamente isoladas, crie projetos novos de maneira programática usando a API Cloud Resource Manager e acesse os recursos em todos os projetos.
OAuth
Em vez de usar o serviço OAuth do App Engine para verificar os tokens do OAuth 2.0,
use o método
oauth2.tokeninfo
da
API OAuth 2.0.
Pesquisar
Hospede qualquer banco de dados de pesquisa de texto completo, como o ElasticSearch no Compute Engine, e acesse-o a partir do serviço.
Fila de tarefas
O serviço de fila de tarefas do App Engine está disponível em dois modos diferentes. Migração de um dos pontos para dois produtos do Cloud diferentes.
Tarefas push
Em vez do serviço de tarefas push da fila de tarefas do App Engine para execução de código assíncrono, use as bibliotecas de cliente do Cloud Tasks com um endpoint de ambiente padrão do Python 3 como destino. Para mais informações, consulte Como migrar filas push para o Cloud Tasks.
Para simular essa migração com um app de exemplo, consulte Como usar filas push do App Engine em aplicativos Flask e Como migrar para o Cloud Tasks.
Tarefas pull
Se você usa o serviço de tarefas pull da fila de tarefas, por exemplo, enfileirando tarefas ou mensagens a serem processadas por workers separados, o Cloud Pub/Sub é uma boa alternativa. Ele oferece funcionalidade e garantias de entrega semelhantes. Como outros serviços do Cloud, o Pub/Sub fornece bibliotecas de cliente convenientes para acessar o serviço. Para mais informações, consulte Como gravar e responder a mensagens do Pub/Sub e o guia de migração Tarefas da fila de tarefas para o Pub/Sub.
Para simular essa migração com um app de exemplo, consulte Como usar tarefas pull do App Engine para um aplicativo de amostra e migrar para o Pub/Sub.
Busca de URL
Por padrão, o ambiente de execução do Python 2.7 usa o serviço de busca de URL para processar solicitações HTTP(S) de saída, mesmo se você usar bibliotecas Python padrão para emitir essas solicitações.
Se o app usa APIs de busca de URL diretamente, por exemplo, para fazer solicitações assíncronas, recomendamos migrar para uma biblioteca de Python padrão, como a biblioteca de solicitações.
Para mais informações, consulte Como migrar solicitações de saída.
Autenticação do usuário
Como alternativa, use um dos mecanismos de autenticação baseados em HTTP descritos na página Autenticação de usuários.