Migre do Python 2.7 para o tempo de execução do Python 3 mais recente

Esta página aborda as instruções para migrar dos motores de execução do Python de primeira geração para os de segunda geração. Para atualizar a app de segunda geração para usar a versão mais recente suportada do Python, consulte o artigo Atualize uma aplicação existente.

O Python 2.7 atingiu o fim do suporte a 31 de janeiro de 2024. As suas aplicações Python 2.7 existentes vão continuar a ser executadas e a receber tráfego. No entanto, o App Engine pode bloquear a nova implementação de aplicações que usam tempos de execução após a data de fim do suporte. Recomendamos que migre para a versão suportada mais recente do Python seguindo as diretrizes nesta página.

A migração para o tempo de execução do Python 3 permite-lhe usar funcionalidades de linguagem atualizadas e criar apps mais portáteis, com código idiomático. O tempo de execução do Python 3 usa a versão mais recente do intérprete Python de código aberto fornecido pela Python Software Foundation. As apps criadas no tempo de execução do Python 3 podem usar o ecossistema avançado de pacotes e frameworks do Python na sua app, incluindo os que usam código C, declarando dependências num ficheiro requirements.txt.

Vista geral do processo de migração em tempo de execução

Recomendamos a seguinte abordagem incremental à migração do tempo de execução, na qual mantém uma aplicação funcional e testável durante todo o processo:

1. Atualize a sua app para ser compatível com o Python 3.

   Estão disponíveis várias soluções para ajudar com esta atualização. Por exemplo, use Six, Python-Future ou Python-Modernize.

   Para mais informações sobre este passo do processo de migração do tempo de execução, consulte o artigo Portabilidade de código do Python 2 para o Python 3 no site de documentação da Python Software Foundation.

2. Escolha uma destas estratégias de implementação para qualquer serviço integrado do App Engine que a sua app use:

   1. Migre os serviços agrupados antigos na sua app Python 2 para serviços Google Cloud desagrupados, serviços de terceiros ou outras substituições recomendadas.

   2. Continue a usar serviços agrupados antigos nas suas apps Python 3. Esta abordagem dá-lhe flexibilidade para mudar para serviços desagrupados mais tarde no ciclo de migração.

      Nota: nem todos os serviços incluídos antigos disponíveis para o Python 2 têm um serviço correspondente no Python 3, pelo que têm de ser migrados para um serviço Google Cloud ou de terceiros antes da portabilidade para o Python 3.

   Certifique-se de que testa a sua app após migrar cada serviço.

3. Prepare os ficheiros de configuração do App Engine para o tempo de execução do Python 3. Várias alterações importantes afetam as definições de configuração no app.yaml, incluindo, entre outras:

   • Agora, considera-se que as apps são seguras para vários threads. Se a sua aplicação não for segura para threads, deve definir max_concurrent_requests no seu app.yaml como 1. Esta definição pode resultar na criação de mais instâncias do que as necessárias para uma app segura para vários processos e gerar custos desnecessários.

   • O ficheiro app.yaml já não encaminha pedidos para os seus scripts. Em alternativa, tem de usar uma framework Web com encaminhamento na app e atualizar ou remover todos os controladores script no app.yaml. Para ver um exemplo de como o fazer com a framework Flask, consulte o exemplo de código do guia de migração do App Engine no GitHub.

     Para saber como alterar este e outros ficheiros de configuração, consulte a secção Ficheiros de configuração.

4. Nos runtimes de segunda geração, os registos de apps já não estão aninhados nos registos de pedidos. São necessários passos adicionais para apresentar a vista aninhada dos registos de pedidos e de apps no Explorador de registos. Para mais informações, consulte o artigo Migre para o Cloud Logging.

5. Teste e implemente a sua app atualizada num ambiente Python 3.

   Depois de todos os testes serem aprovados, implemente a app atualizada no App Engine, mas impeça o encaminhamento automático do tráfego para a nova versão. Use a divisão de tráfego para migrar lentamente o tráfego da sua app no tempo de execução do Python 2 para a app no tempo de execução do Python 3. Se tiver problemas, pode encaminhar todo o tráfego para uma versão estável até o problema ser corrigido.

Para ver exemplos de como converter as suas apps Python 2 para Python 3, pode consultar estes recursos adicionais.

Principais diferenças entre os tempos de execução do Python 2 e do Python 3

A maioria das alterações que tem de fazer durante a migração do tempo de execução decorre das seguintes diferenças entre os tempos de execução do Python 2 e do Python 3:

• Diferenças na utilização da memória
• Diferenças na utilização da CPU
• Diferenças nos cabeçalhos dos pedidos
• Diferenças entre os trabalhadores do Gunicorn
• Problemas de compatibilidade entre o Python 2 e o Python 3
• Serviços incluídos do App Engine no tempo de execução do Python 3
• Diferenças entre ficheiros de configuração
• É necessária uma framework Web para encaminhar pedidos de conteúdo dinâmico
• Apps com apenas conteúdo estático
• Diferenças nos testes
• Diferenças na implementação

Diferenças na utilização de memória

Os tempos de execução de segunda geração têm uma base de utilização de memória mais elevada em comparação com os tempos de execução de primeira geração. Isto deve-se a vários fatores, como diferentes versões de imagens base e diferenças na forma como as duas gerações calculam a utilização de memória.

Os runtimes de segunda geração calculam a utilização de memória da instância como a soma do que um processo de aplicação usa e o número de ficheiros de aplicação armazenados em cache dinamicamente na memória. Para evitar que as aplicações com utilização intensiva de memória sofram encerramentos de instâncias devido à ultrapassagem dos limites de memória, atualize para uma classe de instância maior com mais memória.

Diferenças na utilização da CPU

Os tempos de execução de segunda geração podem observar uma base mais elevada de utilização da CPU no início a frio da instância. Consoante a configuração de escalabilidade de uma aplicação, isto pode ter efeitos secundários não intencionais, como um número de instâncias superior ao previsto, se uma aplicação estiver configurada para ser dimensionada com base na utilização da CPU. Para evitar este problema, reveja e teste as configurações de escalabilidade da aplicação para garantir que o número de instâncias é aceitável.

Diferenças nos cabeçalhos dos pedidos

Os tempos de execução de primeira geração permitem que os cabeçalhos de pedidos com carateres de sublinhado (por exemplo, X-Test-Foo_bar) sejam encaminhados para a aplicação. Os tempos de execução de segunda geração introduzem o Nginx na arquitetura do anfitrião. Como resultado desta alteração, os tempos de execução de segunda geração estão configurados para remover automaticamente os cabeçalhos com carateres de sublinhado (_). Para evitar problemas com a aplicação, evite usar carateres de sublinhado nos cabeçalhos dos pedidos da aplicação.

Diferenças entre trabalhadores do Gunicorn

Para os tempos de execução do Python 3+, o número de trabalhadores do Gunicorn tem um impacto direto na utilização de memória. O aumento na utilização de memória é diretamente proporcional ao aumento no número de trabalhadores. Para reduzir o consumo de memória, considere reduzir o número de trabalhadores do Gunicorn. Consulte as práticas recomendadas de ponto de entrada para obter instruções sobre a configuração da contagem de trabalhadores do Gunicorn

Problemas de compatibilidade entre o Python 2 e o Python 3

Quando o Python 3 foi lançado pela primeira vez em 2008, foram introduzidas várias alterações incompatíveis com versões anteriores na linguagem. Algumas destas alterações requerem apenas atualizações menores ao código, como alterar a declaração print para uma função print(). Outras alterações podem exigir atualizações significativas ao seu código, como a atualização da forma como processa dados binários, texto e strings.

Muitas bibliotecas populares de código aberto, incluindo as bibliotecas padrão do Python, também mudaram quando passaram do Python 2 para o Python 3.

Serviços incluídos do App Engine no tempo de execução do Python 3

Para reduzir o esforço e a complexidade da migração, o ambiente padrão do App Engine permite-lhe aceder a muitos serviços e APIs agrupados legados no tempo de execução do Python 3, como o Memcache. A sua app Python 3 pode chamar as APIs de serviços incluídos através de bibliotecas idiomáticas da linguagem e aceder à mesma funcionalidade que no tempo de execução do Python 2.

Nota: para ver a lista completa de APIs de serviços agrupados antigos disponíveis para Python 3, consulte as APIs disponíveis de serviços agrupados antigos.

Também tem a opção de usar Google Cloud produtos que oferecem uma funcionalidade semelhante à dos serviços agrupados antigos. Recomendamos que considere migrar para os produtos não agrupados Google Cloud , uma vez que tal permite tirar partido das melhorias contínuas e das novas funcionalidades.

Para os serviços incluídos que não estão disponíveis como produtos separados no Google Cloud, como o processamento de imagens, a pesquisa e as mensagens, pode usar os fornecedores externos sugeridos ou outras soluções alternativas.

Ficheiros de configuração

Antes de poder executar a sua app no tempo de execução do Python 3 do ambiente padrão do App Engine, pode ter de alterar alguns dos ficheiros de configuração que o App Engine usa:

• app.yaml. O comportamento de alguns campos no seu ficheiro de configuração foi modificado.app.yaml Remova todos os campos descontinuados e atualize outros campos conforme descrito no guia de migração.

• requirements.txt. Crie este ficheiro para instalar dependências de terceiros, incluindo pacotes Python que requerem extensões C nativas. O App Engine instala automaticamente estas dependências durante a implementação da app no runtime do Python 3. Anteriormente, para instalar dependências no tempo de execução do Python 2, tinha de listar as bibliotecas copiadas ou auto-agrupadas neste ficheiro e, em seguida, executar um comando pip install -t lib -r requirements.txt ou listar as bibliotecas de terceiros "incorporadas" necessárias para a sua app no ficheiro app.yaml.

• appengine_config.py. Este ficheiro não é usado no tempo de execução do Python 3 e é ignorado se for implementado. Anteriormente, no tempo de execução do Python 2, este ficheiro era usado para configurar módulos Python e direcionar a app para bibliotecas de terceiros copiadas ou auto-agrupadas.

Framework Web necessário para encaminhar pedidos de conteúdo dinâmico

No tempo de execução do Python 2, pode criar controladores de URL no ficheiro app.yaml para especificar que app executar quando um URL ou um padrão de URL específico é pedido.

No tempo de execução do Python 3, a sua app tem de usar uma framework Web, como o Flask ou o Django, para encaminhar pedidos de conteúdo dinâmico em vez de usar controladores de URL em app.yaml. Para conteúdo estático, pode continuar a criar processadores de URLs no ficheiro app.yaml da sua app.

Apps com apenas conteúdo estático

Quando alojar uma app Web estática no App Engine, especifica controladores no ficheiro app.yaml para mapear URLs para os seus ficheiros estáticos.

No Python 2, se um pedido não corresponder a nenhum dos controladores especificados no ficheiro app.yaml, o App Engine devolve um código de erro 404.

No Python 3, se um pedido não corresponder a nenhum dos processadores, o App Engine procura um ficheiro main.py e devolve um erro 5xx se não for encontrado um ficheiro main.py. Uma vez que as apps do App Engine com apenas conteúdo estático não requerem um ficheiro main.py, a maioria dos utilizadores vê este erro, além de ver erros de início de instâncias nos registos da app.

Para manter o mesmo comportamento de devolver um erro 404 quando nenhum dos processadores estáticos corresponder e para evitar erros nos registos, pode:

• Adicione um controlador estático geral que aponte para um diretório vazio no ficheiro app.yaml
• Adicione uma app dinâmica simples no ficheiro main.py para devolver um erro 404

Exemplos de utilização de qualquer uma das opções:

app.yaml

Crie um diretório vazio no diretório da app raiz, como empty/. Na secção do controlador do ficheiro app.yaml, crie um novo controlador no final para captar todos os outros padrões de URL e especifique o diretório empty nos elementos static_files e upload:

  handlers:
  - url:
    .
    .
    .
  - url: /(.*)$
    static_files: empty/\1
    upload: empty/.*$

main.py

Crie um ficheiro main.py e adicione o seguinte código para devolver um erro 404:

  def app(env, start_response):
    start_response('404 Not Found', [('Content-Type','text/html')])
    return [b"Not Found"]

Testes

Recomendamos que use uma abordagem de teste idiomática para Python em vez de depender de dev_appserver. Por exemplo, pode usar venv para criar um ambiente Python 3 local isolado. Pode usar qualquer framework de testes padrão do Python para escrever os seus testes de unidade, integração e sistema. Também pode considerar configurar versões de desenvolvimento dos seus serviços ou usar os emuladores locais que estão disponíveis para muitos produtos Google Cloud.

Opcionalmente, pode usar a versão de pré-visualização do dev_appserver, que suporta o Python 3. Para saber mais acerca desta funcionalidade de testes, consulte o artigo Usar o servidor de desenvolvimento local.

A implementar

As implementações através do appcfg.py não são suportadas para o Python 3. Em alternativa, use a gcloud ferramenta de linha de comandos para implementar a sua app.

Registo

O registo no tempo de execução do Python 3 segue a norma de registo no Cloud Logging. No tempo de execução do Python 3, os registos da app já não são agrupados com os registos de pedidos, mas são separados em registos diferentes. Para saber mais sobre como ler e escrever registos no tempo de execução do Python 3, consulte o guia de registo.

Recursos de migração adicionais

Para mais informações sobre como migrar as suas apps do App Engine para serviços na nuvem autónomos ou o tempo de execução do Python 3, pode consultar estes recursos do App Engine:

• Vídeos e laboratórios de programação de migração de apps sem servidor
• Exemplos contribuídos pela comunidade para a migração de apps do Python 2 para o Python 3