Python 2 Runtime Environment

Com o App Engine, pode criar aplicações Web usando a linguagem de programação Python e tirar partido das muitas bibliotecas, ferramentas e frameworks para Python que os programadores profissionais usam para criar aplicações Web de classe mundial. A sua aplicação Python é executada na infraestrutura escalável da Google e usa serviços e armazenamento persistente em grande escala.

Introdução

O App Engine executa o código da sua aplicação Python através de um intérprete Python pré-carregado num ambiente "sandbox" seguro. A sua app recebe pedidos da Web, realiza tarefas e envia respostas através da interação com este ambiente.

Uma app Web Python interage com o servidor Web do App Engine através do protocolo WSGI, pelo que as apps podem usar qualquer framework de app Web compatível com WSGI. O App Engine inclui uma framework de aplicações Web simples, denominada webapp2, para facilitar o início. Para aplicações maiores, as frameworks de terceiros desenvolvidas, como o Django, funcionam bem com o App Engine.

O intérprete Python pode executar qualquer código Python, incluindo módulos Python que inclui na sua aplicação, bem como a biblioteca padrão do Python. O intérprete não pode carregar módulos Python com código C. Trata-se de um ambiente Python "puro".

O ambiente "sandbox" seguro isola a sua aplicação para fins de serviço e segurança. Garante que as apps só podem realizar ações que não interfiram com o desempenho e a escalabilidade de outras apps. Por exemplo, uma app não pode escrever dados no sistema de ficheiros local nem estabelecer ligações de rede arbitrárias. Em alternativa, as apps usam serviços escaláveis fornecidos pelo App Engine para armazenar dados e comunicar através da Internet. O intérprete do Python gera uma exceção quando uma app tenta importar um módulo do Python da biblioteca padrão que se sabe que não funciona nas restrições da sandbox.

A plataforma App Engine oferece muitos serviços que o seu código pode chamar. A sua aplicação também pode configurar tarefas agendadas que são executadas em intervalos especificados.

Selecionar o tempo de execução do Python 2

Especifica o ambiente de execução do Python no app.yamlficheiro de configuração, que é usado para implementar a sua aplicação no App Engine. Por exemplo, pode adicionar o seguinte ao ficheiro app.yaml para usar a versão 2.7 do Python:

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

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

O segundo elemento, api_version, seleciona a versão do ambiente de execução do Python a usar. No momento da redação deste artigo, o App Engine só tem uma versão do ambiente Python, 1. Se a equipa do App Engine precisar de lançar alterações ao ambiente que possam não ser compatíveis com o código existente, fá-lo-á com um novo identificador de versão. A sua app vai continuar a usar a versão selecionada até alterar a definição api_version e carregar a app.

Para mais informações sobre o ficheiro app.yaml e como implementar a sua app no App Engine, consulte os tópicos app.yaml de referência, Migrar para o Python 2.7 e Implementar uma app Python.

A sandbox

Para permitir que o App Engine distribua pedidos de aplicações por vários servidores Web e para impedir que uma aplicação interfira com outra, a aplicação é executada num ambiente de "isolamento de processos" (sandbox) restrito. Neste ambiente, a aplicação pode executar código, armazenar e consultar os dados no Datastore, usar os serviços de correio, obtenção de URLs e utilizadores do App Engine, bem como examinar o pedido Web do utilizador e preparar a resposta.

Uma aplicação do App Engine não pode:

  • escrever no sistema de ficheiros. As aplicações têm de usar o Datastore para armazenar dados persistentes. A leitura do sistema de ficheiros é permitida e todos os ficheiros da aplicação carregados com a aplicação estão disponíveis.

  • responder lentamente. Um pedido Web a uma aplicação tem de ser processado em alguns segundos. Os processos que demoram muito tempo a responder são terminados para evitar sobrecarregar o servidor Web.

  • Fazer outros tipos de chamadas de sistema.

Sandbox no Python

Pode carregar e usar ficheiros .pyc quando usar o tempo de execução do Python 2.7, mas não pode carregar uma versão .py e uma versão .pyc do mesmo ficheiro. Pode carregar ficheiros .zip que contenham ficheiros .py ou .pyc (ou uma combinação). Aplicam-se várias ressalvas importantes se carregar ficheiros .pyc:

  • Para um script CGI, o processador de scripts deve continuar a usar a extensão de ficheiro .py, mesmo que carregue um ficheiro .pyc.
  • Por predefinição, os ficheiros .pyc são ignorados durante a implementação. Tem de substituir o elemento skip_files no seu ficheiro app.yaml para que o novo valor não faça com que os ficheiros .pyc sejam ignorados.
  • Tem de usar o Python 2.7 para criar o ficheiro .pyc. Se tiver uma versão diferente do Python (como o Python 2.6) no seu computador de desenvolvimento, tem de obter a versão 2.7 para criar um ficheiro .pyc compatível.

Python 2 puro

Todo o código para o ambiente de tempo de execução do Python tem de ser Python puro e não incluir extensões C nem outro código que tenha de ser compilado.

O ambiente inclui a biblioteca padrão do Python. Alguns módulos foram desativados porque as respetivas funções essenciais não são suportadas pelo App Engine, como a rede ou a escrita no sistema de ficheiros. Além disso, o módulo os está disponível, mas com as funcionalidades não suportadas desativadas. Uma tentativa de importar um módulo não suportado ou usar uma funcionalidade não suportada vai gerar uma exceção.

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

Bibliotecas personalizadas na versão 2.7 do Python

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 StringIO.

  • O registo está disponível e a sua utilização é altamente recomendada! Consulte a secção Registo.

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

Adicionar bibliotecas Python de terceiros

Pode incluir bibliotecas Python de terceiros na sua aplicação colocando o código no diretório da aplicação. Se criar um link simbólico para o diretório de uma biblioteca no diretório da aplicação, esse link é seguido e a biblioteca é incluída na app que implementa no App Engine.

O caminho de inclusão do módulo Python inclui o diretório raiz da sua aplicação, que é o diretório que contém o ficheiro app.yaml. Os módulos Python que criar no diretório raiz da sua aplicação estão disponíveis através de um caminho a partir da raiz. Não se esqueça de criar os ficheiros __init__.py necessários nos subdiretórios para que o Python reconheça esses subdiretórios como pacotes. Certifique-se também de que as suas bibliotecas não precisam de extensões C.

Discussões

É possível criar threads na versão 2.7 do Python através dos módulos thread ou threading. Tenha em atenção que os threads são unidos pelo tempo de execução quando o pedido termina, pelo que os threads não podem ser executados após o fim do pedido.

Discussões em segundo plano

O código executado numa instância com dimensionamento manual ou básico pode iniciar uma thread em segundo plano que pode sobreviver ao pedido que a gera. Isto permite que uma instância execute tarefas periódicas ou agendadas arbitrárias, ou continue a funcionar em segundo plano depois de um pedido ter sido devolvido ao utilizador.

As entradas de registo e os.environ de uma discussão em segundo plano são independentes das da discussão de origem.

Tem de importar o módulo google.appengine.api.background_thread do SDK para o App Engine.

from google.appengine.api import background_thread

A classe BackgroundThread é semelhante à classe threading.Threadclass normal do Python, mas pode "sobreviver" ao pedido que a gera. Também existe a função start_new_background_thread() que cria uma tarefa em 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 processos em segundo plano simultâneos criados pela API App Engine é de 10 por instância. (Este limite não se aplica a threads Java normais não relacionadas com a API App Engine.)

Ferramentas

O SDK do App Engine inclui ferramentas para testar a sua aplicação, carregar os ficheiros da aplicação, gerir os índices do Datastore, transferir dados de registo e carregar grandes quantidades de dados para o Datastore.

O servidor de desenvolvimento executa a sua aplicação no computador local para testar a aplicação. O servidor simula os serviços do Datastore e as restrições da sandbox. O servidor de desenvolvimento também pode gerar a configuração para os índices do Datastore com base nas consultas que a app executa durante os testes.

A ferramenta gcloud processa todas as interações de linha de comandos com a sua aplicação em execução no App Engine. Usa o gcloud app deploy para carregar a sua aplicação para o App Engine ou para atualizar ficheiros de configuração individuais, como a configuração do índice do Datastore, que lhe permite criar novos índices antes de implementar o seu código. Também pode ver os dados de registo da sua app para analisar o desempenho da app com as suas próprias ferramentas.

Simultaneidade e latência

A latência da sua aplicação tem o maior impacto no número de instâncias necessárias para publicar o seu tráfego. Se processar pedidos rapidamente, uma única instância pode processar muitos pedidos.

As instâncias de thread único podem processar um pedido simultâneo. Por conseguinte, existe uma relação direta entre a latência e o número de pedidos que podem ser processados na instância por segundo. Por exemplo, uma latência de 10 ms é igual a 100 pedidos/segundo/instância.

As instâncias com várias linhas de execução podem processar muitos pedidos simultâneos. Por conseguinte, existe uma relação direta entre a CPU consumida e o número de pedidos/segundo.

As apps Python versão 2.7 suportam pedidos concorrentes, pelo que uma única instância pode processar novos pedidos enquanto aguarda que outros pedidos sejam concluídos. A simultaneidade reduz significativamente o número de instâncias de que a sua app precisa, mas tem de conceber a app para processamento multithread.

Por exemplo, se uma instância B4 (aproximadamente 2,4 GHz) consumir 10 Mcycles/pedido, pode processar 240 pedidos/segundo/instância. Se consumir 100 Mcycles/pedido, pode processar 24 pedidos/segundo/instância. Estes números são o caso ideal, mas são bastante realistas em termos do que pode realizar numa instância.

Variáveis de ambiente

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

Variável de ambiente Descrição
GAE_APPLICATION O ID da sua aplicação do App Engine. Este ID tem o prefixo "region code~", como "e~" para aplicações implementadas na Europa.
GAE_DEPLOYMENT_ID O ID da implementação atual.
GAE_ENV O ambiente do App Engine. Definido como standard.
GAE_INSTANCE O ID da instância na qual o seu serviço está atualmente em execução.
GAE_RUNTIME O tempo de execução especificado no ficheiro app.yaml.
GAE_SERVICE O nome do serviço especificado no ficheiro app.yaml. Se não for especificado nenhum nome de serviço, este é definido como default.
GAE_VERSION A etiqueta da versão atual do seu serviço.
GOOGLE_CLOUD_PROJECT O Google Cloud ID do projeto associado à sua aplicação.
PORT A porta que recebe pedidos HTTP.

Pode definir variáveis de ambiente adicionais no seu ficheiro app.yaml, mas os valores acima não podem ser substituídos.