Ambiente de execução do Python 3

O ambiente de execução do Python 3 é a pilha de software responsável por instalar o código do serviço da Web e as dependências dele, além de executar o serviço do App Engine.

O ambiente de execução do Python 3 para App Engine no ambiente padrão é declarado no arquivo app.yaml:

runtime: pythonVERSION

Em que VERSION é a versão MAJORMINOR do Python. Por exemplo, o Python 3.12 usa 312.

Para outras versões compatíveis do Python e a versão do Ubuntu correspondente à sua versão do Python, consulte a Programação de suporte do ambiente de execução.

Versões do Python 3

O ambiente de execução do Python 3 usa a versão estável mais recente da versão especificada no arquivo app.yaml. O App Engine é atualizado automaticamente para novas versões de patch, mas não atualiza automaticamente a versão secundária.

Por exemplo, um aplicativo implantado no Python 3.7.0 pode ser atualizado automaticamente para o Python 3.7.1, mas ele não será atualizado automaticamente para a próxima versão secundária, o Python 3.8.0.

Faça um teste

Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho do App Engine em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Faça um teste gratuito do App Engine

O App Engine executa apps Python 3 em um contêiner protegido pelo gVisor em uma distribuição do Linux atualizada do Ubuntu.

Dependências

Durante a implantação, o App Engine usa o gerenciador de pacotes Python pip para instalar as dependências definidas no arquivo de metadados requirements.txt (em inglês) localizado no diretório raiz do projeto. Não é preciso fazer o upload das dependências, porque é feita nova instalação pelo App Engine.

No momento, a especificação de dependência que usa o padrão Pipfile/Pipfile.lock não é compatível, e seu projeto não pode ter esses arquivos.

Inicialização do aplicativo

O ambiente de execução inicia o app executando o comando especificado no campo entrypoint no arquivo app.yaml. Se você tiver configurado um ponto de entrada do servidor da Web Gunicorn no arquivo app.yaml, também precisará adicionar gunicorn ao seu arquivo requirements.txt.

O ponto de entrada deve iniciar um servidor da Web que realiza detecções na porta especificada pela variável de ambiente PORT. Exemplo:

entrypoint: gunicorn -b :$PORT main:app

O framework da Web usado pelo app é responsável por encaminhar solicitações para os gerenciadores apropriados no app.

Se o aplicativo atender aos requisitos a seguir, o App Engine iniciará o app com o servidor da Web gunicorn se você não especificar o campo entrypoint:

  • A raiz do diretório do app contém um arquivo main.py com um objeto compatível com WSGI chamado app.

  • Seu app não contém arquivos Pipfile ou Pipfile.lock.

Se você não especificar um ponto de entrada para o ambiente de execução do Python 3, o App Engine vai configurar e iniciar o servidor da Web Gunicorn padrão.

Práticas recomendadas do ponto de entrada

  • Verifique se o módulo Python necessário para executar o ponto de entrada especificado em app.yaml está presente no arquivo requirements.txt. Adicione gunicorn ao arquivo requirements.txt somente se um endpoint gunicorn for especificado explicitamente no arquivo app.yaml.

  • Para um melhor desempenho, o ponto de entrada deve ser leve, porque ele é executado sempre que for criada uma nova instância do aplicativo.

  • O campo do ponto de entrada pode ser usado para ajustar o desempenho do aplicativo. Por exemplo, se você usar gunicorn como seu servidor da Web, será possível usar a sinalização --workers (em inglês) no campo do ponto de entrada para configurar o número de workers que exibem seu aplicativo.

    O número de workers especificados precisa corresponder à classe de instância do aplicativo do App Engine:

    Classe da instância Workers
    F1 2
    F2 4
    F4 8
    F4_1G 8
    B1 2
    B2 4
    B4 8
    B4_1G 8
    B8 8

    Esta orientação serve como ponto de partida para selecionar o número de workers. Talvez seja necessário usar um número diferente de workers dependendo das características de desempenho do aplicativo. O exemplo abaixo mostra uma implantação do App Engine que usa dois workers gunicorn para a exibição de aplicativos:

    entrypoint: gunicorn -b :$PORT -w 2 main:app
    
  • Recomendamos que você configure o servidor da Web para detectar e responder a solicitações HTTP na porta especificada pela variável de ambiente $PORT. O uso da porta padrão 8080 impede que o App Engine use a camada NGINX para compactar respostas HTTP. Se você usar a porta 8080, os avisos sobre a porta 8080 e NGINX serão exibidos nos arquivos de registro do aplicativo.

Outros frameworks da Web

Além do Django e do Flask, é possível usar outros frameworks da Web com o App Engine, como uwsgi e Tornado. O exemplo a seguir mostra como usar uwsgi com o App Engine:

runtime: python39
entrypoint: uwsgi --http-socket :$PORT --wsgi-file main.py --callable app --master --processes 1 --threads 2
uwsgi==2.0.22
Flask==3.0.0

Variáveis de ambiente

As seguintes variáveis de ambiente são definidas pelo ambiente de execução:

Variável de ambiente Descrição
GAE_APPLICATION O ID do aplicativo do App Engine. Esse ID tem o prefixo "region code~", como "e~" para aplicativos implantados na Europa.
GAE_DEPLOYMENT_ID O ID da implantação atual.
GAE_ENV O ambiente do App Engine. Defina como standard.
GAE_INSTANCE O ID da instância em que o serviço é executado no momento.
GAE_MEMORY_MB A quantidade de memória disponível para o processo do aplicativo em MB.
GAE_RUNTIME O ambiente de execução especificado no seu arquivo app.yaml.
GAE_SERVICE O nome do serviço especificado no seu arquivo app.yaml. Se nenhum nome de serviço for especificado, ele será definido como default.
GAE_VERSION O rótulo da versão atual do serviço.
GOOGLE_CLOUD_PROJECT O código do projeto do Google Cloud associado ao aplicativo.
PORT A porta que recebe solicitações HTTP.
NODE_ENV (disponível apenas no ambiente de execução do Node.js) Definido como production quando o serviço for implantado.

É possível definir outras variáveis de ambiente no arquivo app.yaml, mas os valores acima não podem ser modificados, exceto para NODE_ENV.

HTTPS e proxies de encaminhamento

O App Engine encerra as conexões HTTPS no balanceador de carga e encaminha as solicitações para o aplicativo. Em alguns aplicativos, é necessário determinar o protocolo e o IP de solicitação originais. O endereço IP do usuário está disponível no cabeçalho X-Forwarded-For padrão. Os aplicativos que necessitam dessa informação precisam configurar a biblioteca da Web para confiar no proxy.

Sistema de arquivos

O ambiente de execução inclui um sistema de arquivos completo. O sistema de arquivos é somente leitura, exceto pelo local /tmp, que é um disco virtual que armazena dados na RAM da instância do App Engine.

Servidor de metadados

Cada instância do aplicativo pode usar o servidor de metadados do App Engine para consultar informações sobre a instância e o projeto.

É possível acessar o servidor de metadados por meio dos endpoints a seguir:

  • http://metadata
  • http://metadata.google.internal

As solicitações enviadas ao servidor de metadados precisam incluir o cabeçalho Metadata-Flavor: Google. Esse cabeçalho indica que a solicitação foi enviada para recuperar valores de metadados.

A tabela a seguir lista os endpoints em que é possível fazer solicitações HTTP para metadados específicos.

Endpoint de metadados Descrição
/computeMetadata/v1/project/numeric-project-id Número do projeto atribuído ao seu projeto.
/computeMetadata/v1/project/project-id ID do projeto atribuído ao seu projeto.
/computeMetadata/v1/instance/region A região em que a instância está em execução.
/computeMetadata/v1/instance/service-accounts/default/aliases
/computeMetadata/v1/instance/service-accounts/default/email E-mail da conta de serviço padrão atribuído ao seu projeto.
/computeMetadata/v1/instance/service-accounts/default/ Lista todas as contas de serviço padrão do seu projeto.
/computeMetadata/v1/instance/service-accounts/default/scopes Lista todos os escopos compatíveis com as contas de serviço padrão.
/computeMetadata/v1/instance/service-accounts/default/token Retorna o token de autenticação que pode ser usado para autenticar o aplicativo em outras Google Cloud APIs.

Por exemplo, para recuperar o ID do projeto, envie uma solicitação para http://metadata.google.internal/computeMetadata/v1/project/project-id.