Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
ID da região
O REGION_ID é um código abreviado que o Google atribui
com base na região que você selecionou ao criar o aplicativo. O código não
corresponde a um país ou estado, ainda que alguns IDs de região sejam semelhantes
aos códigos de país e estado geralmente usados. Para apps criados após
fevereiro de 2020, o REGION_ID.r está incluído nos
URLs do App Engine. Para apps existentes criados antes dessa data, o
ID da região é opcional no URL.
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, como o ambiente de execução e o identificador da versão
mais recente.
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.
A pasta de cada serviço precisa conter um arquivo app.yaml e um ou mais
arquivos de origem Go que incluam a instrução package main no início.
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 arquivo app.yaml para um aplicativo Go
1.11:
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
build_env_variables
Opcional. Se você está usando um ambiente de execução compatível com
buildpacks, é
possível definir variáveis de ambiente de build no
arquivo app.yaml.
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.
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.
env_variables
Opcional.
Você pode definir variáveis de ambiente no arquivo app.yaml
para disponibilizá-las ao app. Verifique se a chave nas variáveis de ambiente corresponde à expressão "[a-zA-Z_][a-zA-Z0-9_]*" (começa com alfabeto ou "_" seguido por qualquer alfanumérico ou "_").
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:"myvalue"
em queMY_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 em dois
espaços no elemento
env_variables. Para variáveis de ambiente, não foi atribuído
um valor padrão a "None".
É possível conseguir esses valores usando os.Getenv:
Exibido se um prazo for alcançado antes que haja uma resposta do aplicativo.
O error_code é 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.
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 disponibilizando arquivos estáticos enviados com o código, como imagens, CSS ou JavaScript.
Opcional.
É necessário que os aplicativos ativem esses serviços para que o elemento receba solicitações de entrada. É possível ativar o serviço para um aplicativo Go 1.11
incluindo uma seção inbound_services no
arquivo app.yaml.
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 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.
Opcional.
Caminho ou nome totalmente qualificado do pacote principal. Essa
configuração se aplica somente se o app usa o modo de módulo do Go.
Você precisa declarar o caminho para o pacote
principal se o package main não estiver no mesmo
diretório que o app.yaml. O elemento main é compatível com
caminhos de arquivos relativos a app.yaml ou nomes completos de pacotes. Por exemplo, se o aplicativo tiver esta estrutura de diretórios:
Obrigatório. O nome do ambiente de execução usado pelo
app. Por exemplo, para especificar o Go 1.11, use:
runtime:go111
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 comprimento combinado de
VERSION-dot-SERVICE-dot-PROJECT_ID, em que VERSION é o nome da
versão, SERVICE é o nome do serviço e PROJECT_ID
é o ID do projeto, não pode ter mais de 63 caracteres nem
começar 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
service_account
Opcional. O elemento service_account permite especificar uma
conta de serviço gerenciada pelo usuário como a identidade da versão. A conta de serviço especificada é usada ao acessar outros serviços do Google Cloud e executar tarefas.
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. Para mais informações, consulte
Como se conectar a uma rede VPC.
name
Literal de string
. Especifique o nome totalmente qualificado do
conector de acesso VPC sem servidor entre aspas:
Opcional. O padrão é private-ranges-only. O
egress_setting será um destes valores:
private-ranges-only
Padrão. As solicitações para endereços IP internos são enviadas pelo
conector de acesso VPC sem servidor para a
rede VPC conectada. As solicitações para endereços IP
externos são enviadas para a Internet pública.
all-traffic
Todas as solicitações são enviadas pelo
conector de acesso VPC sem servidor para a
rede VPC conectada.
O elemento handlers contém uma lista de padrões de URL e descrições de como eles serão processados. O App Engine processa 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 estáticos, diretórios estáticos e outras configurações.
Elemento
Descrição
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 mais informações.
O exemplo a seguir requer um login no diretório /profile/ e um login de administrador no /admin/:
É possível 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 à
configuração do gerenciador:
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 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. Para informações sobre quais cabeçalhos de resposta influenciam o armazenamento em cache,
consulte Como armazenar
conteúdo estático em cache.
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:
Observação: para permitir que todos acessem os recursos, use o caractere curinga '*' em vez de https://mygame.uc.r.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á executada.
admin
Assim como em required, auth_fail_action
será executado se o usuário não tiver feito login. Além disso, se o usuário não for administrador do aplicativo, ele receberá uma mensagem de erro, seja qual for a 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 inicialmente 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. Também é possível usar auth_fail_action a fim de configurar o app para recusar as solicitações de um gerenciador de usuários que não estejam devidamente autenticados, em vez de redirecioná-los à 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 cumprem a restrição de
login required porque as tarefas cron programadas
não são executadas para um usuário qualquer.
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.
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.
É possível que o elemento redirect_http_response_code tenha os seguintes valores:
Quando a solicitação de um usuário for redirecionada, o código de status HTTP será definido com 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.
Opcional. Qualquer gerenciador de URL pode usar a configuração secure, incluindo gerenciadores de script e de arquivos estáticos. É possível que o elemento secure tenha os seguintes valores:
optional
Tanto solicitações HTTP como HTTPS com URLs que correspondem ao handler serã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 será o padrão quando secure não for fornecido para um handler.
never
As solicitações para um URL que corresponderem a este gerenciador que usa HTTPS serã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 corresponderem a esse handler que não usa HTTPS serão redirecionadas automaticamente para o URL HTTPS com o mesmo caminho. Os parâmetros de consulta são preservados para o redirecionamento.
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
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 não é possível executá-los como scripts.
Exemplo:
handlers:# All URLs beginning with /stylesheets are treated as paths to# static files in the stylesheets/ directory.-url:/stylesheetsstatic_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/\1upload: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 do URL tem algumas diferenças de comportamento quando usado com os seguintes elementos:
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 gerenciados por este handler, usando a porção do URL após o prefixo como parte do caminho do arquivo.
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 escalonamento do seu aplicativo. Para saber mais
sobre como os aplicativos do App Engine são escalonados, consulte
Tipos de escalonamento.
Elemento
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.
É possível que este elemento contenha:
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 entre 1 e 1000. Se não for especificado, o valor padrão será automatic,
o que significa que o App Engine gerenciará
o número de instâncias ociosas.
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
Opcional: o número de instâncias extras a serem mantidas em execução
e prontas para exibir o tráfego para a versão.
O App Engine calcula o número de instâncias necessárias para
exibir o tráfego atual do aplicativo com base nas configurações de
escalonamento, como target_cpu_utilization e
target_throughput_utilization. A configuração de min_idle_instances
especifica o número de instâncias a serem
executadas além do número calculado. Por exemplo,
se o App Engine calcular que são necessárias
cinco instâncias para exibir tráfego, e min_idle_instances
estiver definido como dois, o App Engine executará sete instâncias (cinco calculadas
com base no tráfego e mais duas por min_idle_instances).
Você é cobrado pelo número de instâncias especificadas, independentemente de elas receberem tráfego ou não. 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ê será cobrado pelo número de instâncias especificado, estejam elas gerenciando solicitações ou não.
Se você definir um número mínimo de instâncias ociosas, a latência pendente
terá menos efeito sobre o desempenho do aplicativo.
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 gerenciador 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: 1000).
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 aplicativo threadsafe, o que talvez gere custos desnecessários.
Se essa configuração for muito alta, é possível que ocorra um aumento na latência da API. Talvez o programador gere 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.
Se não for especificado, o valor padrão será automatic. Isso significa
que as solicitações podem permanecer na fila pendente por até 10 segundos, o
limite de tempo de solicitação pendente máximo, antes que novas instâncias sejam iniciadas.
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.
min_pending_latency
Um elemento opcional que pode ser definido para especificar o tempo mínimo
que o App Engine deve permitir que uma solicitação aguarde na fila
pendente antes de iniciar uma nova instância para processá-la.
Especificar um valor pode reduzir os custos de execução, mas aumentar o tempo
que os usuários precisam aguardar para que suas solicitações sejam atendidas.
Para aplicativos gratuitos, o valor padrão é 500ms. Para apps pagos, o valor padrão é 0.
Esse elemento funciona em conjunto com o elemento max_pending_latency
para determinar quando o App Engine cria novas instâncias.
Se as solicitações pendentes estiverem na fila há:
Menos do que o min_pending_latency especificado,
o App Engine não criará novas instâncias.
Mais de 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.
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, 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 a última solicitação. O padrão é 5 minutos (5m).
Exemplo
basic_scaling:max_instances:11idle_timeout:10m
manual_scaling
É necessário que os aplicativos que usarem uma classe de instância de B1 ou superior especifiquem 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.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-11-21 UTC."],[],[]]
