Arquivo de configuração app.yaml

ID da região

O REGION_ID é um código que o Google atribui com base na região selecionada ao criar o aplicativo. A inclusão de REGION_ID.r nos URLs do App Engine é opcional para aplicativos atuais e em breve será obrigatória para todos os aplicativos novos.

Para garantir uma transição tranquila, estamos atualizando lentamente o App Engine para usar IDs da região. Se ainda não tivermos atualizado seu projeto do Google Cloud, você não verá um ID da região para o aplicativo. Como o ID é opcional para os aplicativos atuais, não é necessário atualizar os URLs ou fazer outras alterações quando o ID da região está disponível para os aplicativos já existentes.

Saiba mais sobre IDs da região.

Defina as configurações do aplicativo App Engine no arquivo app.yaml. O arquivo app.yaml também contém informações sobre o código do aplicativo, o ambiente de execução do PHP e o ponto de entrada.

Cada serviço do aplicativo tem um arquivo app.yaml próprio, que atua como descritor da implantação. Primeiro, é necessário criar o arquivo app.yaml do serviço default antes de criar e implantar arquivos app.yamlde outros serviços do aplicativo.

Para PHP 7, o app.yaml precisa conter pelo menos uma entrada runtime: php73. Para uma visão geral, consulte Como definir configurações de ambiente de execução.

Estrutura do diretório

Para saber mais sobre como estruturar vários serviços no seu aplicativo, consulte Como estruturar serviços da Web no App Engine.

Exemplo

Veja a seguir um exemplo de um arquivo app.yaml para um aplicativo PHP 7:

runtime: php72 # Replace with php73 to use the PHP 7.3 runtime

handlers:
# Serve a directory as a static resource.
- url: /stylesheets
  static_dir: stylesheets

# Serve images as static resources.
- url: /(.+\.(gif|png|jpg))$
  static_files: \1
  upload: .+\.(gif|png|jpg)$

# Serve your app through a front controller at index.php or public/index.php.
- url: .*
  script: auto

Neste exemplo, o App Engine exibe arquivos com extensão gif, png ou jpg como recursos estáticos. O código do aplicativo lê os arquivos configurados no ambiente de execução.

Sintaxe

A sintaxe de app.yaml é o formato YAML (em inglês).

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.

Elementos do ambiente de execução e do aplicativo

Elemento Descrição
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 para quatro dias e cinco 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: php72 # Replace with php73 to use the PHP 7.3 runtime

default_expiration: "4d 5h"

handlers:
  # ...

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

entrypoint

Opcional. Substitui o comportamento de inicialização padrão executando o comando entrypoint quando o aplicativo é iniciado. Para que o aplicativo receba solicitações HTTP, o elemento entrypoint precisa conter um comando que inicie um servidor da Web que escute na porta 8080. Se você não especificar um entrypoint, o App Engine disponibilizará seu aplicativo por meio de um controlador frontal em um arquivo public/index.php ou index.php.

env_variables

Opcional. Defina variáveis de ambiente no arquivo app.yaml para disponibilizá-las no seu 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.

Exemplo:

env_variables:
  MY_VAR: "my value"
em que MY_VAR e my value são o nome e o valor da variável de ambiente que você quer definir e cada entrada de variável de ambiente é recuada com dois espaços no elemento env_variables.

Em seguida, você pode recuperar o valor dessas variáveis usando getenv() ou $_SERVER, mas não $_ENV. Os comandos a seguir ecoam o valor da variável de ambiente MY_VAR:


echo getenv('MY_VAR');
,

echo $_SERVER['MY_VAR'];

Veja também uma lista de variáveis de ambiente de execução que não podem ser modificadas.

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 um dos valores a seguir:
over_quota
Indica que o aplicativo excedeu uma cota de recursos
timeout
Exibido 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 exibido 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

Opcional. 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 exibindo arquivos estáticos enviados com o código, como imagens, CSS ou JavaScript.

Se você tiver definido qualquer handlers estático, também precisará definir um gerenciador para que todo o tráfego de outro aplicativo seja roteado para um entrypoint. Para rotear para um entrypoint, especifique o caminho para o controlador frontal com o elemento entrypoint ou use o elemento script se o app contiver um arquivo public/index.php ou index.php.

Exemplo:


url: .*
script: auto
        

Consultar a sintaxe de gerenciadores e subelementos

inbound_services

Opcional. Os aplicativos precisam ativar esses serviços antes de poder receber solicitações de entrada. É possível ativar o serviço para um aplicativo PHP 7 incluindo uma seção inbound_services no arquivo app.yaml.

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

Como opção, use o elemento automatic_scaling para alterar as configurações padrão de escalonamento automático, como número mínimo e máximo de instâncias, latência e conexões simultâneas.

Observação: se instance_class está definido como F2 ou superior, você pode otimizar suas instâncias definindo max_concurrent_requests como um valor maior do que o valor padrão de 10. Para determinar o valor ideal, aumente-o gradualmente e monitore o desempenho do seu aplicativo.

Escalonamento básico e manual
B1, B2, B4, B4_1G, B8
Padrão: B2

As classes de instância básica e manual exigem que você especifique o elemento basic_scaling ou o elemento manual_scaling.

runtime

Obrigatório. O nome do ambiente de execução usado pelo aplicativo. Para especificar o PHP 7.3, use:


runtime: php73
Outros valores de tempo de execução disponíveis incluem: php73, php72
service

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. O nome do serviço combinado com a versão não pode ter mais do que 63 caracteres nem iniciar ou terminar com 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
vpc_access_connector

Opcional. Configura o aplicativo para usar um conector de acesso VPC sem servidor, permitindo o envio de solicitações para recursos internos na rede VPC. Especifique o nome totalmente qualificado de um conector no campo name:


vpc_access_connector:
  name: "projects/[PROJECT_ID]/locations/[REGION]/connectors/[CONNECTOR_NAME]"

Para mais informações, consulte Como se conectar a recursos internos em uma rede VPC.

Elemento handlers

O elemento handlers contém uma lista de padrões de URL e descrições de como eles serão processados. O App Engine pode processar URLs executando o código do aplicativo ou exibindo 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.

Element Descrição
expiration Opcional. É recomendável que a duração de um arquivo estático exibido por este gerenciador seja armazenada em cache por proxies e navegadores da Web. O valor é uma sequência 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 quatro dias e cinco horas após o arquivo ser solicitado pela primeira vez. Se omitido, o default_expiration do aplicativo é usado. Consulte Expiração do cache estático para mais detalhes.
http_headers

Opcional. Defina 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

Este recurso é importante para permitir o 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.uc.r.appspot.com que acesse os recursos hospedados por myassets.uc.r.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.uc.r.appspot.com.

Para que o gerenciador de arquivo estático retorne esse valor de cabeçalho de resposta solicitado, realize as ações a seguir:


handlers:
- url: /images
  static_dir: static/images
  http_headers:
    Access-Control-Allow-Origin: https://mygame.uc.r.appspot.com
  # ...

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

mime_type

Opcional. Se especificado, todos os arquivos exibidos por este gerenciador serão exibidos usando o tipo MIME especificado. Se não especificado, o tipo MIME de um arquivo será derivado da extensão do nome do arquivo. Se for feito upload do mesmo arquivo com várias extensões, a extensão resultante poderá depender da ordem em que os uploads ocorreram.

Para mais informações sobre os possíveis tipos de mídia MIME, consulte o site sobre os tipos de mídia IANA MIME (em inglês)

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 os seguintes valores possíveis:

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

handlers:
- url: /youraccount/.*
  script: auto
  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 como o valor do parâmetro redirect_http_response_code. Se o parâmetro não estiver presente, será retornado 302.

script

Opcional. Especifica que as solicitações para o gerenciador específico precisam segmentar seu aplicativo. O único valor aceito para o elemento script é auto porque todo o tráfego é exibido usando o comando entrypoint. Para usar gerenciadores estáticos, pelo menos um deles precisa conter a linha script: auto ou definir um elemento entrypoint para ser implantado com sucesso.


handlers:
- url: /images
  static_dir: static/images

- url: /.*
  script: auto

secure Opcional. Qualquer gerenciador de URL pode usar a configuração secure, incluindo gerenciadores de script 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. 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 destinados a uma conexão segura por meio de uma conexão não segura.
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: auto
  secure: always

Para direcionar uma versão específica do aplicativo usando o domínio REGION_ID.r.appspot.com, substitua os pontos que geralmente separam os componentes do subdomínio do URL com a string "-dot-", por exemplo:
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

Para usar domínios personalizados com HTTPS, primeiro é preciso ativar e configurar certificados SSL para esse domínio.

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.

static_dir

Opcional. O caminho para o diretório que contém os arquivos estáticos, do diretório raiz do aplicativo. Tudo depois do fim 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 é exibido pelo MIME que corresponde à própria extensão de nome de arquivo, a menos que seja modificado 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.

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. Use isso em vez de static_dir para mapear para arquivos específicos em uma estrutura de diretório sem mapear todo o diretório.

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)$
  # ...

Os arquivos estáticos não podem ser iguais aos arquivos do código do aplicativo.

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. No exemplo acima, é possível 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 primeiro e 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. É possível usar isso em vez de static_dir para mapear para arquivos específicos em uma estrutura de diretório sem mapear todo o diretório.

Como escalonar elementos

Os elementos da tabela a seguir configuram o dimensionamento do seu aplicativo. Para mais informações sobre como os aplicativos do App Engine são escalonados, consulte Tipos de escalonamento.

Element Descrição
automatic_scaling

Opcional. Aplicável somente a aplicativos que usam uma classe de instância de F1 ou superior.

Especifique esse elemento para alterar as configurações padrão do escalonamento automático, como a definição de 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_instances
Opcional. Especifique um valor entre 0 e 2147483647, em que 0 desativa a configuração.

Este parâmetro especifica o número máximo de instâncias a serem criadas pelo App Engine para esta versão do módulo, Isso é útil para limitar os custos de um módulo.

min_instances
Opcional. O número mínimo de instâncias a serem criadas pelo App Engine para esta versão do módulo. Essas instâncias exibem o tráfego quando as solicitações chegam e continuam a exibir mesmo quando outras instâncias são iniciadas, conforme necessário, para processar o tráfego.

Especifique um valor de 0 a 1000. Defina o parâmetro com o valor 0 para que nenhuma instância seja usada quando não houver solicitações. Isso causará uma diminuição nos custos. Você é cobrado pelo número de instâncias especificadas, independentemente de elas receberem tráfego ou não.

max_idle_instances

Opcional. O número máximo de instâncias ociosas que o App Engine precisa manter para esta versão. Especifique um valor de 1 a 1000 ou automatic. O valor padrão é automatic. Lembre-se:

  • Com um valor máximo elevado, o número de instâncias ociosas é reduzido 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.

min_idle_instances

O número de instâncias a serem mantidas em execução e prontas para atender ao tráfego. Você é cobrado pelo número de instâncias especificadas, independentemente de elas receberem tráfego ou não. Essa configuração é aplicável somente à versão que recebe a maior parte do tráfego. Lembre-se:

  • 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 em execução para atender às solicitações recebidas. Você é cobrado pelo número de instâncias especificado, estejam elas processando solicitações ou não.

    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. Para determinar o número ideal de instâncias a serem mantidas em reserva, será preciso testar o aplicativo e o volume de tráfego esperado.

target_cpu_utilization
Opcional. Especifique um valor entre 0,5 e 0,95. O padrão é 0.6.

Este parâmetro especifica o limite de uso da CPU em que novas instâncias serão iniciadas para processar o tráfego. Isso oferece um equilíbrio entre desempenho e custo. Valores menores aumentam o desempenho e o custo, e valores maiores os diminuem. Por exemplo, um valor de 0.7 significa que novas instâncias serão iniciadas quando o uso da CPU atingir 70%.

target_throughput_utilization
Opcional. Especifique um valor de 0,5 a 0,95. O padrão é 0.6.

Usado com max_concurrent_requests para especificar quando uma nova instância é iniciada devido a solicitações simultâneas. Quando o número de solicitações simultâneas atinge um valor igual a max_concurrent_requests vezes target_throughput_utilization, o programador tenta iniciar uma nova instância.

max_concurrent_requests

Opcional. O número de solicitações simultâneas que uma instância de escalonamento automático pode aceitar antes que o programador gere uma nova instância (padrão: 10, máximo: 80).

Usado com target_throughput_utilization para especificar quando uma nova instância é iniciada devido a solicitações simultâneas. Quando o número de solicitações simultâneas atinge um valor igual a max_concurrent_requests vezes target_throughput_utilization, o programador tenta iniciar uma nova instância.

Recomendamos que você não defina max_concurrent_requests para menos de 10, a menos que precise de uma única linha de execução. Um valor menor que 10 provavelmente resultará na criação de mais instâncias do que o necessário para um app threadsafe, o que pode levar a custos desnecessários.

Se essa configuração for muito alta, você poderá notar um aumento na latência da API. O programador pode gerar uma nova instância antes que o número máximo real de solicitações seja atingido.

max_pending_latency

O máximo de tempo que o App Engine permite que uma solicitação aguarde na fila pendente antes que outras instâncias sejam iniciadas para processar solicitações a fim de reduzir a latência pendente. Quando esse limite é atingido, o serviço aumenta o número de instâncias. O valor padrão é 30ms.

Com um valor máximo baixo, o App Engine inicia novas instâncias mais cedo para solicitações pendentes. Isso 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 exibi-las). No entanto, será mais barato executar o aplicativo.

Esse elemento funciona em conjunto com o elemento min_pending_latency para determinar quando o App Engine cria novas instâncias. Se as solicitações pendentes estiverem na fila:

  • Menos que min_pending_latency, o App Engine não criará novas instâncias.
  • Mais que max_pending_latency, o App Engine tentará criar uma nova instância.
  • Entre o tempo especificado por min_pending_latency e max_pending_latency, o App Engine tentará reutilizar uma instância existente. Se nenhuma instância conseguir processar a solicitação antes de max_pending_latency, o App Engine criará uma nova instância.
min_pending_latency

O mínimo de tempo que o App Engine permite que uma solicitação aguarde na fila pendente antes de iniciar uma nova instância para processá-la. Quando esse limite é atingido, o serviço diminui o número de instâncias. O valor padrão é 30ms.

  • 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 execução, mas aumenta o tempo de espera dos usuários para que as solicitações sejam exibidas.
Exemplo

service: my_service
runtime: php72 # Replace with php73 to use the PHP 7.3 runtime
instance_class: F2
automatic_scaling:
  target_cpu_utilization: 0.65
  min_instances: 5
  max_instances: 100
  min_pending_latency: 30ms  # default value
  max_pending_latency: automatic
basic_scaling

Os aplicativos que usam uma classe de instância de B1 ou superior precisam especificar esse elemento ou manual_scaling.

Esse elemento ativa o escalonamento básico das classes de instância B1 e superior e pode conter os seguintes elementos:

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, que é útil para limitar os custos de um serviço.
idle_timeout
Opcional. A instância será encerrada nesse período depois de receber sua última solicitação. O padrão é 5 minutos (5m).
Exemplo

service: my_service
runtime: php72 # Replace with php73 to use the PHP 7.3 runtime
instance_class: B8
basic_scaling:
  max_instances: 11
  idle_timeout: 10m
manual_scaling

Os aplicativos que usam uma classe de instância de B1 ou superior precisam especificar esse elemento ou basic_scaling.

Esse elemento permite o escalonamento manual de classes de instância B1 e superior e pode conter o seguinte elemento:

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

service: my_service
runtime: php72 # Replace with php73 to use the PHP 7.3 runtime
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 limitado.

Para definir um período de armazenamento em cache padrão global para todos os gerenciadores de arquivos estáticos de um aplicativo, inclua o elemento de nível superior default_expiration. Também é possível configurar uma duração de cache para gerenciadores de arquivos estáticos específicos.

O prazo de validade será enviado nos cabeçalhos de resposta HTTP Cache-Control e Expires. Portanto, os arquivos provavelmente serão armazenados em cache pelo navegador do usuário, bem como por servidores proxy de cache intermediários, como os provedores de serviços de Internet. Depois que um arquivo é transmitido com um prazo de validade 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 prazo de validade padrão de 10 minutos é apropriado.