Observação: o Python 2.7 chegou ao fim do suporte em 31 de janeiro de 2024. Os aplicativos Python 2.7 atuais continuarão a ser executados e a receber tráfego. No entanto, o App Engine pode bloquear a reimplantação de aplicativos que usam ambientes de execução após o término da data de suporte. Recomendamos que você migre para a versão compatível mais recente do Python.

Ambiente de execução do Python

Com o App Engine, crie aplicativos da Web usando a linguagem de programação Python e aproveite as muitas bibliotecas e ferramentas do Python que os desenvolvedores profissionais usam para criar aplicativos da Web de nível internacional. O aplicativo Python é executado na infraestrutura escalonável do Google e usa armazenamento persistente e serviços de larga escala.

Introdução

O App Engine executa o código do aplicativo Python usando um interpretador pré-carregado do Python em um ambiente seguro "colocado no sandbox". O app recebe solicitações da Web, realiza trabalhos e envia respostas interagindo com esse ambiente.

Um app da Web do Python interage com o servidor da Web do App Engine usando o protocolo WSGI. Dessa maneira, os apps podem usar qualquer biblioteca de aplicativos da Web compatíveis com WSGI. O App Engine inclui uma biblioteca de aplicativos da Web simples, chamada webapp2, para facilitar os primeiros passos. Para aplicativos maiores, as bibliotecas de terceiros consolidadas, como o Django, funcionam bem com o App Engine.

O interpretador do Python pode executar qualquer código Python, inclusive os módulos dele que você incluir em seu aplicativo, e a biblioteca padrão do Python. O interpretador não pode carregar módulos do Python com código em C. Trata-se de um ambiente Python "puro".

O ambiente seguro em "sandbox" isola o aplicativo para serviço e segurança. Ele garante que os apps só possam executar ações que não interfiram no desempenho e na escalonabilidade de outros apps. Por exemplo, um app não pode gravar dados no sistema de arquivos local ou estabelecer conexões de rede arbitrárias. Em vez disso, os apps usam serviços escalonáveis fornecidos pelo App Engine para armazenar dados e se comunicar pela Internet. O interpretador do Python gera uma exceção quando um app tenta importar um módulo do Python da biblioteca padrão conhecida por não funcionar de acordo com as restrições de sandbox.

A plataforma do App Engine oferece muitos serviços que o código pode chamar. O aplicativo também pode configurar tarefas programadas executadas em intervalos especificados.

Como selecionar o ambiente de execução do Python 2

Especifique o ambiente de execução do Python no arquivo de configuração app.yaml, que é usado para implantar o aplicativo no App Engine. Por exemplo, adicione o seguinte ao arquivo app.yaml para usar a versão 2.7 do Python (em inglês):

runtime: python27
api_version: 1
threadsafe: true
...

O primeiro elemento, runtime, seleciona o ambiente de execução do Python.

O segundo elemento, api_version, seleciona qual versão do ambiente de execução do Python usar. Quando este documento foi elaborado, o App Engine só tinha uma versão do ambiente Python, 1. Se a equipe do App Engine alguma vez precisar lançar alterações no ambiente que possam não ser compatíveis com o código atual, ela fará isso com um novo identificador de versão. Seu aplicativo continuará usando a versão selecionada até que você altere a configuração da api_version e faça o upload do aplicativo.

Para mais informações sobre o arquivo app.yaml e sobre como implantar o aplicativo no App Engine, consulte os tópicos sobre Referência app.yaml, Como migrar para o Python 2.7 e Como implantar um aplicativo Python.

Sandbox

Para permitir que o App Engine distribua solicitações para aplicativos em vários servidores da Web e evitar que um aplicativo interfira no outro, o aplicativo é executado em um ambiente em sandbox restrito. Nesse ambiente, o aplicativo pode executar código, armazenar e consultar os dados no Datastore, usar os serviços de e-mail, busca de URL e usuários do App Engine, além de examinar a solicitação da Web do usuário e preparar a resposta.

Um aplicativo do App Engine não pode:

gravar no sistema de arquivos. Os aplicativos precisam usar o Datastore para armazenar dados permanentes. É permitido ler o sistema de arquivos, e todos os arquivos enviados com o aplicativo estão disponíveis;
demorar para responder. Uma solicitação da Web para um aplicativo precisa ser processada em poucos segundos. Os processos que levam muito tempo para responder são encerrados para evitar sobrecarregar o servidor da Web;
fazer outros tipos de chamadas do sistema.

Como colocar no sandbox em Python

É possível fazer upload e usar arquivos .pyc ao usar o ambiente de execução do Python 2.7, mas não é possível fazer upload das versões .py e .pyc do mesmo arquivo. É possível fazer o upload de arquivos .zip contendo arquivos .py ou .pyc (ou uma combinação). Uma série de advertências importantes se aplicam se você fizer upload de arquivos .pyc:

Para um script CGI, o gerenciador de scripts ainda precisa usar a extensão de arquivo .py, mesmo que você faça upload de um arquivo .pyc.
Por padrão, os arquivos .pyc são pulados durante a implantação. Você precisa modificar o elemento skip_files no arquivo app.yaml para que o novo valor não faça com que os arquivos .pyc sejam ignorados.
Use o Python 2.7 para criar o arquivo .pyc. Se você tiver uma versão diferente do Python (como Python 2.6) na sua máquina de desenvolvimento, será necessário adquirir a versão 2.7 para criar um arquivo .pyc compatível.

Python puro 2

O código completo do ambiente de tempo de execução do Python precisa ser Python puro, e não incluir extensões C ou outros códigos que precisam ser compilados.

O ambiente inclui a biblioteca padrão do Python. Alguns módulos foram desativados porque as funções básicas deles não são compatíveis com o App Engine, como rede ou gravação no sistema de arquivos. Além disso, o módulo os está disponível, mas com recursos não compatíveis desativados. Uma tentativa de importar um módulo não compatível ou de usar um recurso não compatível gerará uma exceção.

Alguns módulos da biblioteca padrão foram substituídos ou personalizados para funcionar com o App Engine. Esses módulos variam entre os dois tempos de execução do Python, conforme descrito abaixo.

Bibliotecas personalizadas no Python versão 2.7

No tempo de execução do Python versão 2.7, os seguintes módulos foram substituídos ou personalizados:

tempfile está desativado, exceto para TemporaryFile, que tem o alias definido como StringIO (links em inglês).
logging está disponível e o uso dele é altamente recomendado. Consulte Logging.

Além da biblioteca padrão do Python e das bibliotecas do App Engine, o ambiente de execução do Python versão 2.7 inclui várias bibliotecas de terceiros.

Como adicionar bibliotecas de terceiros do Python

Inclua bibliotecas de terceiros do Python em seu aplicativo, inserindo o código no diretório do aplicativo. Se você criar um link simbólico para o diretório de uma biblioteca no diretório do aplicativo, esse link será seguido e a biblioteca será incluída no app implantado no App Engine.

O caminho de inclusão do módulo Python inclui o diretório raiz do aplicativo, que é o diretório que contém o arquivo app.yaml. Os módulos do Python que você cria no diretório raiz do aplicativo estão disponíveis usando um caminho da raiz. Não se esqueça de criar os arquivos __init__.py necessários nos subdiretórios para que o Python reconheça esses subdiretórios como pacotes. Verifique também se as bibliotecas não precisam de nenhuma extensão C.

Linhas de execução

As linhas de execução podem ser criadas na versão 2.7 do Python usando os módulos thread ou threading. As linhas de execução serão unidas pelo ambiente de execução quando a solicitação terminar. Dessa maneira, elas não poderão ser executadas após o término da solicitação.

Linhas de execução em segundo plano

O código em execução em uma instância com escalonamento manual ou básico pode iniciar uma linha de execução em segundo plano que resista à solicitação que o gera. Isso permite que uma instância execute tarefas periódicas ou programadas arbitrárias ou continue trabalhando em segundo plano depois que uma solicitação é retornada ao usuário.

Um os.environ e as entradas de registro da linha de execução de segundo plano são independentes das entradas da linha de execução de geração.

Importe o módulo google.appengine.api.background_thread do SDK para o App Engine.

from google.appengine.api import background_thread

A classe BackgroundThread é como o threading.Threadclass do Python normal, mas pode "superar" a solicitação que a gera. Há também a função start_new_background_thread() que cria uma linha de execução de segundo plano e a inicia:

# sample function to run in a background thread
def change_val(arg):
    global val
    val = arg

if auto:
    # Start the new thread in one command
    background_thread.start_new_background_thread(change_val, ['Cat'])
else:
    # create a new thread and start it
    t = background_thread.BackgroundThread(
        target=change_val, args=['Cat'])
    t.start()

O número máximo de threads simultâneos em segundo plano criados pela API App Engine é de 10 por instância. Esse limite não se aplica a segmentos comuns do Java não relacionados à API App Engine.

Ferramentas

O SDK para App Engine inclui ferramentas para testar seu aplicativo, fazer upload de seus arquivos de aplicativo, gerenciar índices do Datastore, fazer o download de dados de registro e fazer upload de grandes quantidades de dados para o Datastore.

O servidor de desenvolvimento executa o aplicativo no computador local para testá-lo. O servidor simula os serviços e as restrições de sandbox do Datastore. O servidor de desenvolvimento também pode gerar configurações para índices do Datastore com base nas consultas que o app realiza durante o teste.

A ferramenta gcloud gerencia todas as interações de linha de comando com o aplicativo em execução no App Engine. Use gcloud app deploy para fazer upload do aplicativo no App Engine ou para atualizar arquivos de configuração individuais, como a configuração de índice do Datastore, que permite criar novos índices antes de implantar o código. É possível também ver os dados de registro do app e analisar o desempenho dele usando suas próprias ferramentas.

Simultaneidade e latência

A latência do seu aplicativo tem o maior impacto no número de instâncias necessárias para disponibilizar o tráfego. Se você processa solicitações rapidamente, uma única instância pode manipular muitas solicitações.

As instâncias com linha de execução única podem manipular uma solicitação simultânea. Portanto, há uma relação direta entre a latência e o número de solicitações que podem ser manipuladas na instância por segundo. Por exemplo, a latência de 10 ms é igual a 100 solicitações por segundo por instância.

As instâncias com vários threads podem processar várias solicitações simultâneas. Portanto, há uma relação direta entre a CPU consumida e o número de solicitações por segundo.

Os apps do Python versão 2.7 aceitam solicitações simultâneas. Dessa maneira, uma única instância pode processar novas solicitações enquanto aguarda a conclusão de outras solicitações. A simultaneidade reduz grandemente o número de instâncias que seu aplicativo requer, mas você precisa projetar seu aplicativo para vários segmentos.

Por exemplo, se uma instância B4 (aproximadamente 2,4 GHz) consome 10 milhões de ciclos/solicitação, você pode processar 240 solicitações/segundo/instância. Se ela consome 100 milhões de ciclos/solicitação, você pode processar 24 solicitações/segundo/instância. Esses números são o caso ideal, mas são bem realistas em termos do que é possível realizar em uma instância.

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_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 ID do projeto do Google Cloud associado ao aplicativo.
`PORT`	A porta que recebe solicitações HTTP.

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