Ambiente de execução do Python 2

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.

O Guia de primeiros passos do Python apresenta uma introdução interativa ao desenvolvimento de aplicativos da Web com o Python e o App Engine.

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

Você especifica o ambiente de tempo de execução do Python no arquivo de configuração app.yaml, usado para implantar o aplicativo no App Engine. Por exemplo, adicione o seguinte comando ao arquivo app.yaml para usar o Python versão 2.7:

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 tempo de execução do Python que será usada. 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 existente, ela fará isso com um novo identificador de versão. O app continuará usando a versão selecionada até você alterar a configuração api_version e fazer upload dele.

Para mais informações sobre o arquivo app.yaml e como implantar o aplicativo no App Engine, consulte os tópicos Referência do app.yaml, Como migrar para o Python 2.7 e Como implantar um app 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 dados no Cloud 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 Cloud Datastore para armazenar dados persistentes. É 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

Você pode fazer upload e usar arquivos .pyc ao utilizar o tempo de execução do Python 2.7, mas não pode fazer upload de uma versão .py e .pyc do mesmo arquivo. Faça upload de arquivos .zip contendo arquivos .py ou .pyc (ou uma combinação). Uma série de advertências importantes serão aplicadas caso você faça upload de arquivos .pyc:

  • Para um script CGI, o gerenciador de scripts ainda precisa usar a extensão .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 evitar que os arquivos .pyc sejam pulados.
  • Você precisa usar o Python 2.7 para criar o arquivo .pyc. Se você tiver uma versão diferente do Python (como o Python 2.6) na máquina de desenvolvimento, consiga 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 ambiente de execução do Python versão 2.7, os seguintes módulos foram substituídos ou personalizados:

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 do Python inclui o diretório raiz do aplicativo, que é aquele 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 obrigatórios nos subdiretórios. Dessa maneira, o Python reconhece esses subdiretórios como pacotes. Verifique também se as bibliotecas não precisam de nenhuma extensão C.

Threads

Os threads podem ser criados no Python versão 2.7 usando os módulos thread ou threading. Os threads serão unidos pelo tempo de execução quando a solicitação terminar. Dessa maneira, os threads não poderão ser executados após o término da solicitação.

Threads em segundo plano

O código em execução nas instâncias de escalonamento manual ou básico pode iniciar um thread em segundo plano capaz de sobreviver à solicitação que o gera. Isso permite que as instâncias executem tarefas periódicas ou programadas arbitrárias ou continuem funcionando em segundo plano depois que uma solicitação é retornada ao usuário.

As entradas de registro de um thread em segundo plano os.environ são independentes das entradas do thread de geração.

Você precisa 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 é como a threading.Threadclass regular do Python, mas pode "sobreviver" à solicitação que o gera. Existe também uma função start_new_background_thread() que cria um thread em segundo plano e o 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 segmentos 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 o aplicativo, fazer upload dos arquivos de aplicativo, gerenciar índices do Cloud Datastore, fazer o download de dados de registro e fazer upload de grandes volumes de dados para o Cloud 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 Cloud Datastore. O servidor de desenvolvimento também pode gerar configuração para índices do Cloud Datastore com base nas consultas que o aplicativo executa durante os testes.

A ferramenta gcloud processa todas as interações de linha de comando com o aplicativo em execução no App Engine. Você usa gcloud app deploy para fazer upload do aplicativo no App Engine ou atualizar arquivos de configuração individuais, como a configuração do índice do Cloud 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 lidar com muitas solicitações.

As instâncias de thread único podem processar uma solicitação simultânea. Portanto, há uma relação direta entre a latência e número de solicitações que podem ser processadas na instância por segundo. Por exemplo, a latência de 10 ms é igual a 100 pedidos/segundo/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.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Ambiente padrão do App Engine para Python 2