Referência do app.yaml

Você pode definir as configurações do aplicativo do App Engine no arquivo app.yaml. Este arquivo especifica como os caminhos do URL correspondem aos gerenciadores de solicitação e aos arquivos estáticos. O arquivo app.yaml também contém informações sobre o código do aplicativo, como o ID do aplicativo e o identificador da versão mais recente.

Exemplo

O exemplo a seguir corresponde a um arquivo app.yaml de um aplicativo Python:

runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /
  script: home.app

- url: /index\.html
  script: home.app

- url: /stylesheets
  static_dir: stylesheets

- url: /(.*\.(gif|png|jpg))$
  static_files: static/\1
  upload: static/.*\.(gif|png|jpg)$

- url: /admin/.*
  script: admin.app
  login: admin

- url: /.*
  script: not_found.app

Uma diretiva script: pode conter um caminho de arquivo que termina em .py, o que significa que o script usa CGI, ou um caminho do módulo Python, com nomes de pacotes separados por pontos, o que significa que o script usa WSGI.

Sintaxe

A sintaxe do arquivo app.yaml está no formato YAML. Para saber mais sobre essa sintaxe, consulte o site do YAML.

O formato YAML é compatível com comentários. As linhas iniciadas com o caractere de cerquilha (#) são ignoradas:

# This is a comment.

Os padrões de caminho de URL e arquivo usam a sintaxe de expressões regulares estendidas POSIX, excluindo elementos e classes de compilação. São aceitas tanto as referências inversas às correspondências agrupadas (por exemplo, \1) quanto as extensões Perl: \w \W \s \S \d \D.

Elemento Descrição
application

A abordagem recomendada consiste em remover o elemento application do arquivo app.yaml e, no lugar dele, usar uma sinalização de linha de comando para especificar o ID do aplicativo:

  • Para usar o comando gcloud app deploy, especifique a sinalização --project:
    
    gcloud app deploy --project [YOUR_PROJECT_ID]
  • Para usar o comando appcfg.py update, especifique a sinalização -A:
    
    appcfg.py update -A [YOUR_PROJECT_ID]

Para mais informações sobre como usar esses comandos, consulte Como implantar o aplicativo.

O ID do aplicativo é o código do projeto especificado na criação do aplicativo no Console do Google Cloud Platform.

api_version

Obrigatório. A versão da API no ambiente de tempo de execução específico usado pelo aplicativo.

Quando o Google anunciar o suporte para uma nova versão da API do ambiente de tempo de execução, o aplicativo implantado continuará usando a versão para a qual ele foi escrito. Para atualizar o aplicativo para uma nova versão da API, altere esse valor e implante novamente o aplicativo no App Engine. Quando você especifica o valor 1, o ambiente de tempo de execução mais recente aceito é usado sempre que você implanta esse aplicativo (atualmente).

No momento, o App Engine tem uma versão do ambiente de tempo de execução python27: 1

auto_id_policy Opcional. Se você estiver configurando identificadores de entidade automaticamente, poderá alterar o método empregado definindo a política de código automática. As seguintes opções são válidas:
default
Padrão. Usa códigos automáticos dispersos que são grandes, inteiros e bem distribuídos, e ao mesmo tempo, pequenos o suficiente para serem representados por flutuadores de 64 bits.
legacy
A opção legada ficará obsoleta em uma versão futura e em algum momento será removida. Para mais informações consulte a postagem do blog que anuncia essa alteração.
builtins

Opcional. O SDK do Python inclui vários gerenciadores integrados para funções de aplicativo comuns. A diretiva builtins permite incluir gerenciadores específicos no app.yaml.

Os seguintes gerenciadores internos estão disponíveis para uso:

appstats
Ativa Appstats em /_ah/stats/, que você pode usar para medir o desempenho do aplicativo. Para usar o Appstats, você também precisa instalar o gravador de eventos.
deferred
Ativa o gerenciador deferido em /_ah/queue/deferred. Esse builtin permite que os desenvolvedores usem deferred.defer() para simplificar a criação de tarefas da fila de tarefas. Consulte também Trabalho em segundo plano com a biblioteca deferida.
remote_api
Ativa o builtin remote_api em /_ah/remote_api/. Este builtin permite que aplicativos remotos com as credenciais adequadas acessem o armazenamento de dados de maneira remota.
Exemplo:

builtins:
- deferred: on
- appstats: on

A diretiva builtins é uma instância especial da diretiva includes. Cada diretiva builtin é equivalente, no Python, a uma diretiva includes com um caminho expandido. Exemplo:


builtins:
- name: on

É equivalente a:


includes:
- $PYTHON_LIB/google/appengine/ext/builtins/name/

Quando você usa builtins no arquivo app.yaml, todos os gerenciadores que são definidos no arquivo include.yaml integrado substituirão os gerenciadores definidos no arquivo app.yaml. No entanto, se você incluir um arquivo que use builtins ou includes, os gerenciadores serão adicionados por ordem da hierarquia de inclusão. Em outras palavras, os gerenciadores de inclusão do "pai" são adicionados antes dos builtins das inclusões do "filho", e assim por diante.

Por exemplo, considere o seguinte app.yaml, que usa os gerenciadores integrados do appstats:


handlers:
- url: /.*
  script: main.app
builtins:
- appstats: on

A lista resultante de gerenciadores é:


[/_ah/stats, /.*]

Se app.yaml usar uma diretiva "includes":


includes:
- included.yaml

E o arquivo included.yaml usar builtins:


handlers:
- url: /.*
  script: main.app
builtins:
- appstats: on

A lista resultante de gerenciadores será:


[/.*, /_ah/stats]

A ordem de colocação da cláusula builtins em um arquivo .yaml não altera o comportamento.

default_expiration

Opcional. Define um período de cache padrão global para todos os gerenciadores de arquivos estáticos de um aplicativo. Você também pode configurar a duração de um cache para gerenciadores de arquivos estáticos específicos. O valor é uma string de números e unidades, separados por espaços, em que as unidades podem ser d para dias, h para horas, m para minutos e s para segundos. Por exemplo, "4d 5h" define a expiração do cache como 4 dias e 5 horas após o arquivo ser solicitado pela primeira vez. Se omitida, o servidor de produção definirá a expiração em 10 minutos.

Exemplo:

runtime: python27
api_version: 1
threadsafe: true

default_expiration: "4d 5h"

handlers:
# ...

Para mais informações, consulte Expiração do cache estático.

env_variables

Opcional. Você pode definir variáveis de ambiente no arquivo app.yaml para disponibilizá-las para o aplicativo.

As variáveis de ambiente com o prefixo GAE são reservadas para uso do sistema e não são permitidas no arquivo app.yaml.

Essas variáveis estarão disponíveis no dicionário os.environ:

env_variables:
  DJANGO_SETTINGS_MODULE: 'myapp.settings'
error_handlers

Opcional. Usado para configurar páginas de erro personalizadas que são retornadas para diferentes tipos de erro.

Este elemento pode conter os seguintes elementos:

error_code
Opcional. O error_code pode ser uma das seguintes opções:
over_quota
Indica que o aplicativo excedeu uma cota de recursos
dos_api_denial
Indica que a solicitação foi bloqueada pela configuração da Proteção do DoS do aplicativo.
timeout
Veiculado se um prazo for alcançado antes que haja uma resposta do aplicativo.

O código do erro é opcional. Se ele não for especificado, o arquivo fornecido será a resposta de erro padrão do aplicativo.

file
Cada entrada de arquivo indica um arquivo estático a ser veiculado no lugar da resposta de erro genérica. Se você especificar um elemento file sem um error_code correspondente, o arquivo estático será a página de erro padrão do aplicativo. Os dados de erro personalizados precisam ter menos de 10 kilobytes.
Exemplo

error_handlers:
  - file: default_error.html

  - error_code: over_quota
    file: over_quota.html
handlers

Obrigatório. Uma lista de padrões de URL e de descrições de como eles precisam ser processados. O App Engine pode processar os URLs executando o código do aplicativo ou veiculando os arquivos estáticos enviados com o código, como imagens, CSS ou JavaScript.

Consultar a sintaxe de gerenciadores e subelementos

includes

Opcional. A diretiva includes permite a inclusão do arquivo de configuração em qualquer biblioteca ou serviço no aplicativo. Por exemplo, você pode incluir uma biblioteca de administração de usuários da seguinte maneira:


includes:
- lib/user_admin.yaml

O App Engine resolve o caminho incluído na seguinte ordem:

  • Caminho absoluto ou relativo do diretório em uso. O caminho especificado tem resolução em um arquivo.
  • Relativo ao diretório do aplicativo, que também é conhecido como caminho de base. O caminho de base e o caminho têm resolução em um arquivo.
  • Relativo ao arquivo que incluía o arquivo atual. O local do arquivo de referência e o caminho de inclusão têm resolução no arquivo incluído.

Se a diretiva include especificar um diretório, o App Engine procurará nesse diretório um arquivo chamado include.yaml. Se a diretiva de inclusão for um arquivo, então esse arquivo específico será incluído. O uso de includes recupera apenas os seguintes tipos de diretivas do arquivo de destino (se presente):

Os padrões de skip_files incluídos são adicionados aos que estão no app.yaml ou à lista padrão, se não houver uma lista explícita em app.yaml.

inbound_services

Opcional. Antes de poder receber e-mail, o aplicativo precisa ser configurado para ativar o serviço. Ative o serviço em um aplicativo Python incluindo uma seção inbound_services no arquivo app.yaml.

Os seguintes serviços de entrada estão disponíveis:

mail
Permite que o aplicativo receba e-mail.
warmup
Ativa solicitações de aquecimento. Consulte Como configurar solicitações de aquecimento.
Exemplo:

inbound_services:
  - mail
  - warmup
instance_class

Opcional. A classe de instância deste serviço.

Os seguintes valores estão disponíveis dependendo do escalonamento do serviço:

Escalonamento automático
F1, F2, F4, F4_1G
Padrão: F1 atribuído se você não especificar uma classe de instância com o elemento automatic_scaling.
Escalonamento básico e manual
B1, B2, B4, B4_1G, B8
Padrão: B2 atribuído se você não especificar uma classe de instância com o elemento basic_scaling ou manual_scaling.
libraries

Opcional. O ambiente de execução do Python 2.7 inclui algumas bibliotecas de terceiros. Algumas estão disponíveis por padrão. Outras estão disponíveis apenas quando configuradas. Indique qual versão você quer usar especificando os valores name e version.


libraries:
- name: PIL
  version: "1.1.7"
- name: webob
  version: "latest"
        

Observe que, quando você especifica latest, o SDK determina a versão mais recente da biblioteca no momento da implantação. Depois de implantada, a versão da biblioteca não será alterada. A única maneira de receber uma versão diferente da biblioteca é implantar novamente.

Se você está desenvolvendo um aplicativo que ainda não tem usuários: não é necessário rastrear novas versões. Mas se o aplicativo estiver sendo usado ativamente, cuidado. Talvez você se surpreenda ao constatar que ele começou a usar uma nova versão de biblioteca não compatível com versões anteriores.

Para ver uma lista das bibliotecas de terceiros incluídas, consulte Bibliotecas de terceiros. Você pode usar bibliotecas de terceiros puramente em Python instalando-as em um diretório local.

Se você estiver usando o ambiente flexível, consulte Como usar bibliotecas do Python no ambiente flexível.

module

Observação: os módulos agora são denominados serviços.

Para gerenciar o aplicativo com a ferramenta gcloud, use o elemento serviço.

Para usar a ferramenta appcfg, os serviços precisam ser declarados em arquivos app.yaml como módulos, por exemplo:


module: service-name

Obrigatório ao criar um serviço. Opcional para o serviço default. É necessário que todos os serviços e versões tenham um nome. Esse nome pode conter números, letras e hifens. Ele não pode ter mais de 63 caracteres nem ser iniciado ou terminado por um hífen. Escolha um nome exclusivo para cada serviço e versão. Não reutilize nomes de serviços em versões e vice-versa.

runtime

Obrigatório. Nome do ambiente de tempo de execução do App Engine usado por este aplicativo. Para especificar o Python, use python27.


runtime: python27
service

Anteriormente, os serviços eram conhecidos como módulos.

Compatível somente com a ferramenta gcloud ou com plug-ins baseados no Cloud SDK, por exemplo: gcloud app deploy.

Para usar a ferramenta appcfg, consulte módulo.

Obrigatório ao criar um serviço. Opcional para o serviço default. É necessário que todos os serviços e versões tenham um nome. Esse nome pode conter números, letras e hifens. Ele não pode ter mais de 63 caracteres nem ser iniciado ou terminado por um hífen. Escolha um nome exclusivo para cada serviço e versão. Não reutilize nomes de serviços em versões e vice-versa.

Exemplo:

service: service_name

Observação: o comando gcloud app deploy é compatível com versões anteriores e aceita arquivos app.yaml existentes que incluem serviços declarados como módulos, por exemplo:


module: service_name
skip_files

Opcional. O elemento skip_files especifica quais arquivos no diretório do aplicativo não serão enviados para o App Engine. O valor é uma expressão regular ou uma lista de expressões regulares. Qualquer nome de arquivo que corresponda a uma das expressões regulares é omitido na lista de arquivos para upload quando é feito o upload do aplicativo. Os nomes dos arquivos são relativos ao diretório do projeto.

O skip_files tem o seguinte padrão:


skip_files:
- ^(.*/)?#.*#$
- ^(.*/)?.*~$
- ^(.*/)?.*\.py[co]$
- ^(.*/)?.*/RCS/.*$
- ^(.*/)?\..*$

O padrão exclui arquivos de backup Emacs com nomes nos formatos #...# e ...~, arquivos .pyc e .pyo, arquivos em um diretório de controle de revisão RCS e arquivos ocultos Unix com nomes que começam com um ponto (.).

Para ampliar a lista de expressões regulares acima, copie e cole essa lista no app.yaml e adicione suas próprias expressões regulares. Por exemplo, para ignorar arquivos com nomes que terminam em .bak, além dos padrões, adicione uma entrada como esta para skip_files:


skip_files:
- ^(.*/)?#.*#$
- ^(.*/)?.*~$
- ^(.*/)?.*\.py[co]$
- ^(.*/)?.*/RCS/.*$
- ^(.*/)?\..*$
- ^(.*/)?.*\.bak$

Para ignorar um diretório completo, adicione o nome do diretório à lista. Por exemplo, para ignorar um diretório denominado logs, adicione a seguinte linha às descritas anteriormente:


skip_files:
- logs/
threadsafe

Obrigatório. Configura o aplicativo para usar solicitações simultâneas. Se estiver usando a biblioteca de threads do Python, os dados locais do thread, conforme retornados por threading.local(), serão limpos após cada solicitação.


threadsafe: [true | false]

Observação: a diretiva threadsafe é necessária para aplicativos Python 2.7. threadsafe: true requer que todos os gerenciadores de script sejam WSGI. Ou seja, cada script tem de ser especificado em uma diretiva script: usando o caminho do módulo Python, com nomes de pacotes separados por pontos. O último componente de uma diretiva script: usando um caminho do módulo Python é o nome de uma variável global no service:. Essa variável precisa ser um aplicativo WSGI e geralmente é denominada app por convenção.

version

A abordagem recomendada é remover o elemento version do arquivo app.yaml e, no lugar dele, usar uma sinalização de linha de comando para especificar o código da versão:

  • Para usar o comando gcloud app deploy, especifique a sinalização -v:
    
    gcloud app deploy -v [YOUR_VERSION_ID]
  • Para usar o comando appcfg.py update, especifique a sinalização -V:
    
    appcfg.py update -V [YOUR_VERSION_ID]

Para mais informações sobre como usar esses comandos, consulte Como implantar o aplicativo.

Um identificador da versão do código do aplicativo que você implanta no App Engine.

O código da versão pode conter letras minúsculas, dígitos e hifens. Ele não pode começar com o prefixo ah- e os nomes default e latest são reservados e não podem ser usados.

Observação: os nomes das versões têm que começar com uma letra, para distingui-las de instâncias numéricas que são sempre especificadas por um número. Isso evita a ambiguidade com URLs como 123.my-service.appspot.com, que pode ser interpretado de duas maneiras: se a versão "123" existir, o destino será a versão "123" do serviço fornecido. Se essa versão não existir, o destino será a instância número 123 da versão padrão do serviço.

Cada versão de um aplicativo mantém a própria cópia do app.yaml. Quando um aplicativo é enviado, a versão mencionada no arquivo app.yaml sendo enviado é a criada ou substituída pelo upload. Um administrador pode alterar qual versão do aplicativo está veiculando o tráfego usando o Console do Google Cloud Platform. Além disso, ele também pode testar outras versões antes de configurá-las para receber o tráfego.

Elemento handlers

O elemento handlers é obrigatório no app.yaml. O elemento fornece uma lista de padrões de URL e descrições de como eles serão processados. O App Engine pode processar os URLs executando o código do aplicativo ou veiculando arquivos estáticos enviados com o código, como imagens, CSS ou JavaScript.

Os padrões são avaliados na ordem em que aparecem no arquivo app.yaml, de cima para baixo. O primeiro mapeamento com padrão que corresponde ao URL é usado para processar a solicitação.

A tabela a seguir lista os subelementos do elemento handlers que controlam o comportamento de scripts, arquivos e diretórios estáticos e outras configurações.

Elemento Descrição
application_readable Opcional. Booleano. Por padrão, os arquivos declarados em gerenciadores de arquivos estáticos são enviados como dados estáticos e são veiculados somente para usuários finais. Eles não podem ser lidos no aplicativo. Se este campo for definido como verdadeiro, os arquivos também serão enviados como dados de código para que possam ser lidos no aplicativo. Ambos os uploads são cobrados de acordo com o código e as cotas de recursos de armazenamento de dados estáticos.
auth_fail_action

Opcional. Descreve a ação realizada quando o elemento login é especificado para um gerenciador e o usuário está desconectado. Ele tem dois valores possíveis:

redirect
Padrão. O usuário é redirecionado para a página de login do Google ou /_ah/login_required se a autenticação OpenID for usada. O usuário é redirecionado novamente para o URL do aplicativo depois de fazer login ou de criar uma conta.
unauthorized
A solicitação é rejeitada com um código de status HTTP 401 e uma mensagem de erro.

Se um aplicativo precisar de um comportamento diferente, o próprio aplicativo poderá implementar o processamento dos logins de usuário. Consulte a API Users para ver mais informações.

O exemplo a seguir requer um login no diretório /profile/ e um login de administrador no /admin/:


handlers:
- url: /profile/.*
  script: user_profile.app
  login: required

- url: /admin/.*
  script: admin.app
  login: admin

- url: /.*
  script: welcome.app

Você pode configurar um gerenciador para recusar o acesso a URLs protegidos quando o usuário não tiver feito login, em vez de redirecionar o usuário para a página de login, adicionando auth_fail_action: unauthorized na configuração do gerenciador:


handlers:
- url: /secure_api/.*
  script: api_handler.app
  login: required
  auth_fail_action: unauthorized
expiration Opcional. É recomendável que a duração de um arquivo estático veiculado por este gerenciador seja armazenada em cache por proxies e navegadores da Web. O valor é uma string de números e unidades, separados por espaços, em que as unidades podem ser d para dias, h para horas, m para minutos e s para segundos. Por exemplo, "4d 5h" define a expiração do cache para 4 dias e 5 horas após a o arquivo ser solicitado pela primeira vez. Se omitido, o default_expiration do aplicativo é usado. Consulte Expiração do cache estático para ver mais detalhes.
http_headers

Opcional. Você pode definir cabeçalhos HTTP para ver respostas dos gerenciadores de diretório ou arquivo estático. Se você precisar definir cabeçalhos HTTP nos gerenciadores de script, faça isso no código do aplicativo.

Exemplo

handlers:
- url: /images
  static_dir: static/images
  http_headers:
    X-Foo-Header: foo
    X-Bar-Header: bar value

Suporte ao CORS

Esse recurso é importante no suporte ao compartilhamento de recursos entre origens (CORS, na sigla em inglês), como o acesso aos arquivos hospedados por outro aplicativo do App Engine.

Por exemplo, um aplicativo de jogo mygame.appspot.com que acesse os recursos hospedados por myassets.appspot.com. No entanto, se mygame tentar fazer uma XMLHttpRequest JavaScript para myassets, ele não terá êxito a menos que o gerenciador de myassets retorne um cabeçalho de resposta Access-Control-Allow-Origin: contendo o valor http://mygame.appspot.com.

Para que o gerenciador de arquivo estático retorne esse valor de cabeçalho de resposta solicitado, faça o seguinte:


handlers:
- url: /images
  static_dir: static/images
  http_headers:
    Access-Control-Allow-Origin: http://mygame.appspot.com

Observação: para permitir que todos acessem os recursos, use o curinga '*', em vez de http://mygame.appspot.com.

login

Opcional. Determina se o gerenciador de URL exige que o usuário faça login. Este elemento tem três valores possíveis:

optional
Padrão. Não requer que o usuário faça login.
required
Se o usuário tiver feito login, o gerenciador prosseguirá normalmente. Caso contrário, a ação determinada em auth_fail_action será realizada.
admin
Assim como em required, esse valor executará auth_fail_action se o usuário não tiver feito login. Além disso, se o usuário não for um administrador do aplicativo, ele receberá uma mensagem de erro independentemente da configuração de auth_fail_action. Se o usuário for um administrador, o gerenciador prosseguirá.

Quando um gerenciador de URL com uma configuração de login diferente de optional corresponde a um URL, o gerenciador primeiro verifica se o usuário fez login no aplicativo usando a opção de autenticação. Caso contrário, por padrão, o usuário será redirecionado para a página de login. Você também pode usar auth_fail_action para configurar o aplicativo para simplesmente rejeitar as solicitações de um gerenciador de usuários que não estejam devidamente autenticados, em vez de redirecionar o usuário para a página de login.

Observação: a restrição de login para admin também é atendida em solicitações internas com cabeçalhos especiais X-Appengine apropriados configurados pelo App Engine. Por exemplo, as tarefas programadas do cron atendem à restrição de admin, porque o App Engine define um cabeçalho HTTP X-AppEngine-Cron: true nas respectivas solicitações. No entanto, as solicitações não satisfazem à restrição de login required porque as tarefas programadas do cron não são executadas como qualquer usuário.

mime_type

Opcional. Se especificado, todos os arquivos veiculados por este gerenciador serão veiculados usando o tipo MIME especificado. Se não especificado, o tipo MIME de um arquivo será derivado da extensão do nome do arquivo.

Para ver mais informações sobre os possíveis tipos de mídia MIME, consulte o site sobre os tipos de mídia IANA MIME

redirect_http_response_code

Opcional. redirect_http_response_code é usado com a configuração secure para definir o código de resposta do HTTP retornado na realização de um redirecionamento definido pela configuração de secure. O elemento redirect_http_response_code tem estes valores possíveis:

301
Código de resposta movido permanentemente.
302
Código de resposta encontrado.
303
Ver outro código de resposta.
307
Código de resposta de redirecionamento temporário.
Exemplo

handlers:
- url: /youraccount/.*
  script: accounts.app
  login: required
  secure: always
  redirect_http_response_code: 301

Quando a solicitação de um usuário for redirecionada, o código de status do HTTP será definido com o valor do parâmetro redirect_http_response_code. Se o parâmetro não estiver presente, 302 será retornado.

script

Opcional. Especifica o caminho para o script a partir do diretório raiz do aplicativo:


handlers:
# The root URL (/) is handled by the WSGI application named
# "app" in home.py. No other URLs match this pattern.
- url: /
  script: home.app

# The URL /index.html is also handled by the home.py script.
- url: /index\.html
  script: home.app

# A regular expression can map parts of the URL to the
# path of the script.
- url: /browse/(books|videos|tools)
  script: \1.catalog.app

# All other URLs use the WSGI application named in "app"
# in not_found.py.
- url: /.*
  script: not_found.app

Uma diretiva script: precisa ser um caminho de importação do Python. Por exemplo, package.module.app, que aponta para um aplicativo WSGI. O último componente de uma diretiva script: usando um caminho do módulo Python é o nome de uma variável global no módulo. Essa variável precisa ser um aplicativo WSGI e geralmente é denominada app por convenção.

Observação: assim como para uma instrução import do Python, cada subdiretório que é um pacote precisa conter um arquivo denominado __init__.py.

secure Opcional. Qualquer gerenciador de URL pode usar a configuração secure, incluindo gerenciadores de scripts e de arquivos estáticos. O elemento secure tem os seguintes valores possíveis:
optional
Tanto solicitações HTTP como HTTPS com URLs que correspondem ao gerenciador são bem-sucedidas sem redirecionamentos. O aplicativo pode examinar a solicitação para determinar qual protocolo foi usado e responder de acordo com essa informação. Este é o padrão quando secure não é fornecido para um gerenciador.
never
As solicitações para um URL que correspondem a este gerenciador e usam HTTPS são redirecionadas automaticamente para o URL equivalente do HTTP.
always
As solicitações para um URL que correspondem a esse gerenciador e que não usam HTTPS são redirecionadas automaticamente para o URL HTTPS com o mesmo caminho. Os parâmetros de consulta são preservados para o redirecionamento.
Exemplo

handlers:
- url: /youraccount/.*
  script: accounts.app
  login: required
  secure: always

Quando a solicitação HTTPS de um usuário é redirecionada para ser uma solicitação HTTP, os parâmetros da consulta são removidos da solicitação. Isso evita que um usuário envie acidentalmente dados de consulta destinada a uma conexão segura por uma não segura.

O servidor Web de desenvolvimento não é compatível com as conexões HTTPS. Ele ignora o parâmetro secure. Dessa forma, os caminhos a serem usados com HTTPS podem ser testados com o uso de conexões HTTP regulares para o servidor Web de desenvolvimento.

Para acessar o URL appspot.com com controle de versão do aplicativo, substitua os pontos que geralmente separariam os componentes do subdomínio do URL pela string "-dot-". Por exemplo: https://desired_version-dot-your_app_id.appspot.com/.

O login e o logout das contas do Google sempre são realizados por meio de uma conexão segura, sem relação com a configuração dos URLs do aplicativo.

Para usar domínios personalizados com HTTPS, você primeiro tem que ativar e configurar o SSL para o App Engine com o domínio.

static_dir

Opcional. O caminho para o diretório que contém os arquivos estáticos, do diretório raiz do aplicativo. Tudo que vier depois do final do padrão url correspondente é anexado ao static_dir para formar o caminho completo para o arquivo solicitado.

Cada arquivo no diretório estático é veiculado usando o tipo MIME que corresponde à própria extensão de nome de arquivo, a menos que seja substituído pela configuração mime_type do diretório. Todos os arquivos no diretório específico são enviados como arquivos estáticos, e nenhum deles pode ser executado como script.

Todos os arquivos deste diretório são enviados com o aplicativo como arquivos estáticos. O App Engine armazena e veicula arquivos estáticos separadamente dos arquivos do aplicativo. Os arquivos estáticos não estão disponíveis no sistema de arquivos do aplicativo por padrão. Isso pode ser alterado definindo a opção application_readable como "verdadeiro".

Exemplo:

handlers:
# All URLs beginning with /stylesheets are treated as paths to
# static files in the stylesheets/ directory.
- url: /stylesheets
  static_dir: stylesheets
static_files

Opcional. Um gerenciador de padrão de arquivo estático associa um padrão de URL com caminhos para arquivos estáticos enviados com o aplicativo. A expressão regular do padrão de URL pode definir os agrupamentos de expressões regulares a serem usados na construção do caminho do arquivo. Você pode usar isso em vez de static_dir para mapear arquivos específicos em uma estrutura de diretório sem mapear o diretório inteiro.

Exemplo:

handlers:
# All URLs ending in .gif .png or .jpg are treated as paths to
# static files in the static/ directory. The URL pattern is a
# regular expression, with a grouping that is inserted into the
# path to the file.
- url: /(.*\.(gif|png|jpg))$
  static_files: static/\1
  upload: static/.*\.(gif|png|jpg)$

O App Engine armazena e veicula arquivos estáticos separadamente dos arquivos do aplicativo. Os arquivos estáticos não estão disponíveis no sistema de arquivos do aplicativo por padrão. Isso pode ser alterado definindo a opção application_readable como "verdadeiro".

Os arquivos estáticos não podem ser iguais aos arquivos do código do aplicativo. Se um caminho de arquivo estático corresponder a um caminho para um script usado em um gerenciador dinâmico, o script não ficará disponível para o gerenciador dinâmico.

upload

Opcional. Uma expressão regular que corresponde aos caminhos de arquivo para todos os arquivos que serão referenciados por este gerenciador. Isso é necessário porque o gerenciador não pode determinar quais arquivos no diretório do aplicativo correspondem aos padrões de url e static_files específicos. Os arquivos estáticos são enviados e processados separadamente dos arquivos de aplicativos. O exemplo acima pode usar o seguinte padrão de upload: archives/(.*)/items/(.*)

url

Elemento obrigatório em handlers. O padrão de URL, como expressão regular. A expressão pode conter agrupamentos que podem ser referenciados no caminho do arquivo para o script com referências à expressão regular. Por exemplo, /profile/(.*)/(.*) corresponderia ao URL /profile/edit/manager e usaria edit e manager como o primeiro e o segundo agrupamentos.

O padrão de URL tem algumas diferenças de comportamento quando usado com os seguintes elementos:

static_dir
Usa um prefixo de URL. O padrão expresso regular não pode conter agrupamentos quando usado com o elemento static_dir. Todos os URLs iniciados por esse prefixo são processados por este gerenciador, usando a porção do URL após o prefixo como parte do caminho do arquivo.
static_files
Um gerenciador de padrão de arquivo estático associa um padrão de URL com caminhos para arquivos estáticos enviados com o aplicativo. A expressão regular do padrão de URL pode definir agrupamentos de expressões regulares a serem usados na construção do caminho do arquivo. Você pode usar isso em vez de static_dir para mapear arquivos específicos em uma estrutura de diretório sem mapear o diretório inteiro.

Elementos de escalonamento

Para saber mais sobre o escalonamento dos aplicativos do Google App Engine, consulte Como escalonar instâncias dinâmicas.

A tabela a seguir lista as opções para definir como especificar se o aplicativo precisa ser escalonado.

Elemento Descrição
automatic_scaling

Opcional. O escalonamento automático é esperado por padrão com uma classe de instância padrão de F1, a menos que especificado o contrário.

O elemento automatic_scaling define os níveis mínimo e máximo para o número de instâncias, latência e conexões simultâneas de um serviço.

Este elemento pode conter os seguintes elementos:

max_concurrent_requests

Opcional. O número de solicitações simultâneas que uma instância de escalonamento automático pode aceitar antes do programador gerar uma nova instância (Padrão: 8, Máximo: 80).

Pode ocorrer aumento da latência da API se esta configuração for muito alta. Observe que o programador pode gerar uma nova instância antes que o número máximo real de solicitações seja atingido.

max_idle_instances

O número máximo de instâncias ociosas que o App Engine precisa manter para esta versão. O valor padrão é "automático". Lembre-se do seguinte:

  • Com um valor máximo elevado, o número de instâncias ociosas é reduzido mais gradualmente quando os níveis de carga retornam ao normal após um pico. Isso ajuda o aplicativo a manter um desempenho constante durante as flutuações na carga da solicitação. No entanto, isso também aumenta o número de instâncias ociosas (e os custos de execução consequentes) durante esses períodos de carga intensa.
  • Com um valor máximo reduzido, os custos de execução ficam mais baixos. No entanto, isso pode afetar o desempenho devido aos níveis de carga voláteis.

Observação: ao retornar aos níveis normais após um pico de carga, o número de instâncias ociosas pode exceder temporariamente o máximo especificado. No entanto, você não será cobrado por mais instâncias do que o número máximo especificado.

max_pending_latency

A quantidade máxima de tempo que o App Engine permite que uma solicitação aguarde na fila pendente antes que uma nova instância seja iniciada para resolver isso. O valor padrão é "30 ms".

  • Com um valor máximo baixo, o App Engine inicia novas instâncias mais cedo para solicitações pendentes, o que melhora o desempenho, mas aumenta os custos de execução.
  • Com um valor máximo alto, os usuários podem aguardar mais tempo para que as solicitações deles sejam atendidas (se houver solicitações pendentes e sem instâncias ociosas para veiculá-las). No entanto, será mais barato para executar o aplicativo.
min_idle_instances

O número mínimo de instâncias ociosas a serem mantidas pelo App Engine nesta versão. Aplica-se apenas à versão padrão de um serviço, porque outras versões não podem receber tráfego elevado. Lembre-se do seguinte:

  • Com um valor mínimo baixo, os custos de execução são reduzidos durante os períodos ociosos. No entanto, talvez menos instâncias fiquem imediatamente disponíveis para responder a um pico de carga inesperado.
  • Com um valor mínimo alto, é possível preparar o aplicativo para picos rápidos na carga de solicitação. O App Engine mantém o número mínimo de "instâncias residentes" em execução o tempo todo. Assim, uma instância está sempre disponível para veicular uma solicitação recebida. Você é cobrado por instâncias residentes, independentemente de elas estarem processando solicitações. Para que as instâncias residentes funcionem corretamente, verifique se as solicitações de aquecimento estão ativadas e se o aplicativo as processa. A coluna Disponibilidade da página Instância do Console do Google Cloud Platform indica se uma instância é residente ou dinâmica.

    Se você definir um número mínimo de instâncias ociosas, a latência pendente terá menos efeito no desempenho do aplicativo. Como o App Engine mantém as instâncias ociosas em reserva, é improvável que as solicitações entrem na fila pendente, exceto em picos de carga excepcionalmente elevados. Você precisará testar o aplicativo e o volume de tráfego esperado para determinar o número ideal de instâncias a serem mantidas em reserva.

min_pending_latency

A quantidade mínima de tempo que o App Engine permite que uma solicitação aguarde na fila pendente antes que uma nova instância seja iniciada para processá-la.

  • Com um valor mínimo baixo, as solicitações precisam passar menos tempo na fila pendente quando todas as instâncias existentes estão ativas. Isso melhora o desempenho, mas aumenta o custo de execução do aplicativo.
  • Com um valor mínimo alto, as solicitações continuarão pendentes por mais tempo se todas as instâncias existentes estiverem ativas. Isso reduz os custos de operação, mas aumenta o tempo que os usuários precisam aguardar para que as solicitações sejam veiculadas.
Exemplo

service: my-service
runtime: python27
api_version: 1
instance_class: F2
automatic_scaling:
  min_idle_instances: 5
  max_idle_instances: automatic  # default value
  min_pending_latency: 30ms  # default value
  max_pending_latency: automatic
  max_concurrent_requests: 50
basic_scaling

Opcional. O elemento basic_scaling define o número de instâncias de um serviço.

Este elemento pode conter os seguintes elementos:

idle_timeout
Opcional. A instância encerrará essa quantidade de tempo depois de receber a última solicitação. O padrão é 5 minutos.
max_instances
Obrigatório. O número máximo de instâncias a serem criadas pelo App Engine para esta versão do serviço. Isso é útil para limitar os custos de um serviço.
Exemplo

service: my-service
runtime: python27
api_version: 1
instance_class: B8
basic_scaling:
  max_instances: 11
  idle_timeout: 10m
manual_scaling

Opcional. O elemento manual_scaling permite o escalonamento manual de um serviço e define o número de instâncias de um serviço.

Este elemento pode conter os seguintes elementos:

instances
O número de instâncias a serem atribuídas ao serviço no início.
Exemplo

service: my-service
runtime: python27
api_version: 1
instance_class: B8
manual_scaling:
  instances: 5

Expiração do cache estático

Salvo instrução contrária, os proxies e navegadores da Web retêm os arquivos carregados de um site por um período de tempo limitado.

Você pode definir um período de cache padrão global para todos os gerenciadores de arquivos estáticos de um aplicativo, basta incluir o elemento default_expiration de nível superior. Você também pode configurar uma duração de cache para gerenciadores de arquivos estáticos específicos.

O tempo de expiração será enviado nos cabeçalhos de resposta do HTTP Cache-Control e Expires e, portanto, os arquivos provavelmente serão armazenados em cache pelo navegador do usuário, bem como por servidores de proxy de armazenamento em cache intermediários, como os provedores de serviços de Internet. Depois que um arquivo é transmitido com um tempo de expiração determinado, geralmente não há como removê-lo de caches intermediários, mesmo que o usuário limpe seu próprio cache do navegador. A reimplantação de uma nova versão do aplicativo não redefinirá nenhum cache. Portanto, se você planeja modificar um arquivo estático, ele tem que ter um tempo de expiração curto (menos de uma hora). Na maioria dos casos, o tempo de expiração padrão de 10 minutos é apropriado.

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

Enviar comentários sobre…

Ambiente padrão do App Engine para Python