Como são encaminhados os pedidos

ID da região

O REGION_ID é um código abreviado que a Google atribui com base na região que seleciona quando cria a sua app. O código não corresponde a um país ou uma província, embora alguns IDs de regiões possam parecer semelhantes aos códigos de países e províncias usados frequentemente. Para apps criadas após fevereiro de 2020, REGION_ID.r está incluído nos URLs do App Engine. Para apps existentes criadas antes desta data, o ID da região é opcional no URL.

Saiba mais acerca dos IDs de regiões.

Esta página descreve como os pedidos HTTP dos utilizadores chegam à versão adequada de um serviço. As solicitações podem ser encaminhadas das seguintes formas:

Estas opções aplicam-se apenas a apps implementadas. Quando está a testar localmente, o comportamento de encaminhamento depende do tempo de execução específico e do ambiente de desenvolvimento que está a usar.

Encaminhamento com URLs

Assim que a sua app estiver em execução no App Engine, pode usar o seguinte URL para enviar pedidos HTTP para a app:

https://PROJECT_ID.REGION_ID.r.appspot.com

onde PROJECT_ID é o ID do Google Cloud projeto que contém a app.

Este URL envia pedidos para o serviço predefinido da sua app na versão que configurou para receber tráfego.

URLs para serviços e versões

Se criar mais do que um serviço na sua app, cada serviço tem o seu próprio URL. Cada versão de um serviço também tem o seu próprio URL, pelo que pode implementar e testar uma nova versão antes de configurar essa versão para receber tráfego.

Os URLs de serviços e versões específicos têm o seguinte formato:

VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

Pode omitir VERSION-dot- se não precisar de segmentar uma versão específica.

Para obter os IDs dos serviços e das versões da sua app, pode usar qualquer uma das seguintes ferramentas:

Consola

Na Google Cloud consola, pode ver as páginas correspondentes de Instâncias, Serviços> e Versões.

gcloud

Execute o comando gcloud app instances list para apresentar os IDs dos recursos num Google Cloud projeto específico.

API

Para obter IDs de recursos de forma programática, consulte os métodos list na API Admin.

Exemplos de URLs

Seguem-se alguns exemplos de URLs do App Engine, que mostram o domínio appspot.comque o App Engine atribui à sua app e um domínio personalizado, que pode configurar para a sua app.

  • Envia o pedido para uma instância disponível do serviço default:
    
https://PROJECT_ID.REGION_ID.r.appspot.com
https://CUSTOM_DOMAIN

    Os pedidos são recebidos por qualquer versão configurada para tráfego no serviço default.

  • Envia um pedido a 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

    Os pedidos são recebidos por qualquer versão configurada para tráfego no serviço segmentado. Se o serviço que está a segmentar não existir, o pedido é encaminhado de forma flexível.

  • Envia um pedido a uma instância disponível de uma versão específica no
    default serviço:
    
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.CUSTOM_DOMAIN

    Quando um serviço não é segmentado, os pedidos são enviados para o serviço default.

Encaminhamento suave

Se um pedido corresponder à parte PROJECT_ID.REGION_ID.r.appspot.com do nome de anfitrião, mas incluir um nome de serviço, versão ou instância que não exista, o pedido é encaminhado para o serviço default. O encaminhamento flexível não se aplica a domínios personalizados. Os pedidos para estes devolvem um código de estado HTTP 404 se o nome do anfitrião for inválido.

Encaminhamento segmentado

Os seguintes padrões de URL atingem o respetivo destino, se existirem. Os pedidos que não passam pelo Cloud Load Balancing nunca são intercetados nem reencaminhados pelos padrões que definiu no ficheiro de expedição:

  • Envia o pedido para uma instância disponível de um serviço e uma 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

Encaminhamento com um ficheiro de expedição

Pode criar um ficheiro de expedição para substituir as regras de encaminhamento baseadas em URLs do App Engine e definir as suas próprias regras de encaminhamento personalizadas. Com um ficheiro de expedição, pode enviar pedidos recebidos para um serviço específico com base no caminho ou no nome do anfitrião no URL do pedido.

Criar um ficheiro de expedição

Para criar um ficheiro de expedição:

  1. Crie um ficheiro com o nome dispatch.yaml no diretório raiz do seu projeto ou no diretório raiz do serviço default.

  2. Defina regras de encaminhamento no ficheiro, conforme descrito na referência dispatch.yaml.

Tenha em atenção o seguinte acerca das regras de encaminhamento:

  • Pode definir até 20 regras de encaminhamento. Cada regra tem de conter os elementos url e service.
  • As regras têm de usar padrões de URL HTTP que incluam a notação "." para separar subdomínios. Os URLs definidos com a notação "-dot-" HTTPS não são suportados.
  • As regras também se aplicam aos URLs que definir no seu ficheiro cron.yaml.

Por exemplo, pode criar um ficheiro de expedição para encaminhar pedidos de dispositivos móveis, como https://simple-sample.uc.r.appspot.com/mobile/, para um front-end para dispositivos móveis e encaminhar pedidos de trabalhadores, 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

Implementar o ficheiro de envio

Para implementar o ficheiro de expedição através do gcloud, execute o seguinte comando:

gcloud app deploy dispatch.yaml

Encaminhamento com o Cloud Load Balancing

O Cloud Load Balancing é um produto separado que permite configurações de rede avançadas para todas as suas aplicações em execução no Google Cloud.

Quando o balanceamento de carga de HTTP(S) está ativado para apps sem servidor, pode:

  • Configure a sua app sem servidor para ser servida a partir de um endereço IP IPv4 ou IPv6 dedicado que não seja partilhado com outros serviços.

  • Reutilize os mesmos certificados SSL e chaves privadas que usa para o Compute Engine, o Google Kubernetes Engine e o Cloud Storage. Isto elimina a necessidade de gerir certificados separados para apps sem servidor.

Se o NEG sem servidor especificar um serviço, uma versão ou uma etiqueta, o balanceador de carga não interfere nem interage com as regras de encaminhamento no seu ficheiro 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. O encaminhamento segmentado falha quando o NEG sem servidor não especifica o serviço, a versão ou uma etiqueta, e o encaminhamento depende das regras que especifica no ficheiro dispatch.yaml.

Tenha em conta o seguinte:

  • Recomendamos que use controlos de entrada para que a sua app apenas receba pedidos enviados a partir do equilibrador de carga (e da VPC, se a usar). Caso contrário, os utilizadores podem usar o URL do App Engine da sua app para contornar o balanceador de carga, as políticas de segurança do Cloud Armor, os certificados SSL e as chaves privadas que são transmitidas através do balanceador de carga.

Métricas inconsistentes quando o ambiente flexível do App Engine usa o Cloud Load Balancing

O painel de controlo do ambiente flexível do App Engine apresenta todas as métricas apenas para pedidos encaminhados através de um back-end gerido do ambiente flexível. Se usar o ambiente flexível do App Engine com o Cloud Load Balancing, determinadas métricas na tabela de métricas do App Engine são comunicadas como métricas da tabela loadbalancing. Para mais informações, consulte o artigo Registo e monitorização do balanceamento de carga HTTP(S).

Compreenda o ID da região nos URLs

O REGION_ID é um código abreviado que a Google atribui com base na região que seleciona quando cria a sua app. O código não corresponde a um país ou uma província, embora alguns IDs de regiões possam parecer semelhantes aos códigos de países e províncias usados frequentemente. Para apps criadas após fevereiro de 2020, REGION_ID.r está incluído nos URLs do App Engine. Para apps existentes criadas antes desta data, o ID da região é opcional no URL.

Pode usar as seguintes ferramentas para ver o ID da região da sua app:

Consola

Na Google Cloud consola, pode ver os URLs das instâncias, dos serviços e das versões da sua app.

Todos estes URLs incluem o ID da região.

gcloud

Quando implementa uma app ou um serviço, o comando gcloud app deploy apresenta o URL após a implementação ser bem-sucedida. Este URL inclui o ID da região.

Para ver o URL de um serviço que já está implementado:

  1. Introduza o comando gcloud app versions list para apresentar as versões de um serviço específico. Por exemplo, para listar as versões do serviço predefinido, introduza gcloud app versions list --service=default.

  2. Introduza o comando gcloud app versions describe. O resultado desse comando inclui o URL da versão com o ID da região da app. Por exemplo, para descrever a versão 20191023t101741 do serviço predefinido, introduza gcloud app versions describe 20191023t101741 --service=default

O nome do domínio está incluído nos dados do pedido

O nome do domínio usado para o pedido está incluído nos dados do pedido que são transmitidos à sua app. Por conseguinte, pode usar os dados do pedido para controlar a forma como a sua app responde com base no nome do domínio no pedido. Por exemplo, se quiser fazer o redirecionamento para um domínio oficial, pode programar a sua app para verificar o cabeçalho do pedido Host e, em seguida, responder em conformidade com base no nome do domínio.