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.
Saiba mais sobre IDs de região.
Esta página descreve como as solicitações HTTP dos usuários chegam à versão apropriada de um serviço. As solicitações podem ser roteadas das seguintes maneiras:
Essas opções se aplicam apenas a aplicativos implantados. Ao testar o aplicativo localmente, o comportamento do roteamento depende dos ambientes de execução e de desenvolvimento específicos que você está usando.
Roteamento com URLs
Quando seu aplicativo estiver em execução no App Engine, use o seguinte URL para enviar solicitações HTTP ao aplicativo:
https://PROJECT_ID.REGION_ID.r.appspot.com
em que PROJECT_ID
é o ID do projeto do Google Cloud que contém o aplicativo.
Esse URL envia solicitações para o serviço padrão do aplicativo na versão configurada para receber tráfego.
URLs para serviços e versões
Se você criar mais de um serviço no aplicativo, cada serviço terá seu próprio URL. Cada versão de um serviço também tem um URL próprio para que seja possível implantar e testar uma versão nova antes de configurá-la para receber o tráfego.
Os URLs de serviços e versões específicos estão no seguinte formato:
VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
É possível omitir VERSION-dot-
se não for necessário visar uma
versão específica.
Para recuperar os IDs dos serviços e versões do app, é possível usar qualquer uma das seguintes ferramentas:
Console
No console do Google Cloud, é possível ver as Instâncias, os Serviços e as Versões correspondentes. páginas.
gcloud
Execute o comando gcloud app instances list
para listar os IDs de recursos em um projeto específico do Google Cloud.
API
Para recuperar programaticamente IDs de recursos, consulte os métodos de list
na
API Admin.
Exemplos de URL
Veja alguns exemplos de URLs do App Engine que mostram o
domínio appspot.com
que o App Engine atribui ao app e
um domínio personalizado, que é possível configurar para o app.
- Envia a solicitação para uma instância disponível do serviço
default
: https://PROJECT_ID.REGION_ID.r.appspot.com
https://CUSTOM_DOMAIN
As solicitações são recebidas por qualquer versão configurada para tráfego no serviço
default
.- Envia a solicitação para uma instância disponível do serviço
- Envia uma solicitação para uma instância disponível de um serviço específico:
https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://SERVICE_ID.CUSTOM_DOMAIN
As solicitações são recebidas por qualquer versão configurada para o recebimento do tráfego no serviço de destino. Se o serviço de destino não existir, a solicitação será encaminhada probabilisticamente.
- Envia uma solicitação para uma instância disponível de uma versão específica no
- serviço
default
: https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.CUSTOM_DOMAIN
Quando um serviço não é direcionado, as solicitações são enviadas para o serviço
default
.
Roteamento probabilístico
Se uma solicitação corresponder à parte PROJECT_ID.REGION_ID.r.appspot.com
do nome do host, mas incluir um serviço, uma versão ou um nome de instância que não existe, a solicitação será roteada para o serviço default
. O roteamento probabilístico não se aplica a domínios personalizados. As solicitações feitas a eles retornarão um código de status HTTP 404
se o nome do host for inválido.
Roteamento direcionado
Os padrões de URL a seguir têm a garantia de que chegarão ao destino, se ele existir. Essas solicitações nunca são interceptadas e reencaminhadas pelos padrões definidos no arquivo de expedição:
- Envia a solicitação para uma instância disponível de um serviço e
versão específicos:
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN
Roteamento com um arquivo de expedição
É possível criar um arquivo de expedição para modificar as regras de roteamento baseadas em URL do App Engine e definir suas próprias regras de roteamento personalizadas. Com um arquivo de expedição, é possível enviar solicitações a serem recebidas por um serviço específico com base no caminho ou nome do host no URL da solicitação.
Como criar um arquivo de expedição
Para criar um arquivo de expedição:
Crie um arquivo chamado
dispatch.yaml
na raiz do diretório do projeto ou no diretório raiz do serviçodefault
.Defina regras de roteamento no arquivo conforme descrito na referência
dispatch.yaml
.
Observe o seguinte sobre as regras de roteamento:
- É possível definir até 20 regras de roteamento. Cada regra precisa conter os
elementos
url
eservice
. - As regras precisam usar padrões do URL de HTTP que incluam a notação "
.
" para separar subdomínios. URLs definidos com a notação "-dot-
" do HTTPS não são compatíveis. - As regras também se aplicam aos URLs definidos no
arquivo
cron.yaml
.
Por exemplo, é possível criar um arquivo de expedição para rotear solicitações de
dispositivos móveis como https://simple-sample.uc.r.appspot.com/mobile/
para um front-end móvel e rotear solicitações de worker
como https://simple-sample.uc.r.appspot.com/work/
para um back-end estático:
dispatch:
# Send all mobile traffic to the mobile frontend.
- url: "*/mobile/*"
service: mobile-frontend
# Send all work to the one static backend.
- url: "*/work/*"
service: static-backend
Como implantar o arquivo de expedição
Para implantar o arquivo de envio usando a gcloud
, execute o seguinte comando:
gcloud app deploy dispatch.yaml
Como fazer roteamento com o Cloud Load Balancing
O Cloud Load Balancing é um produto separado que permite configurações avançadas de rede para todos os seus aplicativos em execução no Google Cloud.
Quando o balanceamento de carga HTTP(S) está ativado para aplicativos sem servidor, é possível:
Configurar seu aplicativo sem servidor para ser exibido a partir de um endereço IP IPv4 e/ou IPv dedicado que não seja compartilhado com outros serviços.
Reutilizar os mesmos certificados SSL e as chaves privadas que você usa para o Compute Engine, o Google Kubernetes Engine e o Cloud Storage. Isso elimina a necessidade de gerenciar certificados separados para aplicativos sem servidor.
O balanceador de carga não interfere nem interage com as regras de roteamento no
arquivo dispatch.yaml
. As regras dispatch.yaml
não são avaliadas até que um
NEG sem servidor direcione o tráfego para o App Engine.
Observe o seguinte:
- Recomendamos usar controles de entrada para que o aplicativo receba apenas solicitações enviadas do balanceador de carga (e da VPC, se você usá-la). Caso contrário, os usuários poderão usar o URL do App Engine do aplicativo para ignorar o balanceador de carga, as políticas de segurança do Google Cloud Armor, os certificados SSL e as chaves privadas transmitidas pelo balanceador de carga.
Métricas inconsistentes quando o ambiente flexível do App Engine usa o Cloud Load Balancing
O painel do ambiente flexível do App Engine exibe todas as métricas apenas para solicitações roteadas
por um back-end gerenciado de ambiente flexível. Se você usar o ambiente flexível do App Engine com o Cloud Load Balancing, algumas métricas na tabela de métricas do App Engine serão informadas como métricas da tabela loadbalancing
.
em vez disso. Para mais informações, consulte
Geração de registros e monitoramento de balanceamento de carga HTTP(S).
Detalhes adicionais sobre URLs do App Engine
Noções básicas sobre o ID da região em URLs
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.
Use as seguintes ferramentas para ver o ID de região do seu aplicativo:
Console
No console do Google Cloud, é possível ver os URLs das instâncias, dos serviços e das versões do app de dados.
Todos esses URLs incluem o ID de região.
gcloud
Quando você implanta um aplicativo ou serviço, o comando gcloud app deploy
exibe o URL após o êxito da implantação. Esse URL inclui o
ID de região.
Para ver o URL de um serviço que já foi implantado:
Digite o comando
gcloud app versions list
para listar as versões de um serviço específico. Por exemplo, para listar as versões do serviço padrão, digitegcloud app versions list --service=default
.Digite o comando
gcloud app versions describe
. A saída desse comando inclui o URL da versão com o ID de região do aplicativo. Por exemplo, para descrever a versão 20191023t101741 para o serviço padrão, insiragcloud app versions describe 20191023t101741 --service=default
.
O nome de domínio está incluído nos dados da solicitação
O nome de domínio usado para a solicitação está incluído nos dados da solicitação que são passados para seu aplicativo. Portanto, é possível usar os dados da solicitação para controlar como o aplicativo responde com base no nome de domínio na solicitação. Por exemplo, se você quiser redirecionar para um domínio oficial, codifique o aplicativo para que verifique o cabeçalho da solicitação Host
e responda de acordo com o nome de domínio.