Como os pedidos são encaminhados

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:

Se testar a sua app através do servidor de desenvolvimento local, as funcionalidades de encaminhamento e envio disponíveis são ligeiramente diferentes. Para criar programaticamente URLs que funcionem com servidores de produção e desenvolvimento, use o método get_hostname.

Consulte o encaminhamento no servidor de desenvolvimento para saber mais.

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 têm a garantia de alcançar o respetivo destino, se existirem. Estes pedidos nunca são intercetados nem reencaminhados pelos padrões que definiu no ficheiro de envio:

  • 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

  • Se estiver a usar serviços com escalabilidade manual, pode segmentar e enviar um pedido a uma instância incluindo o ID da instância. O ID da instância é um número inteiro no intervalo de 0 até ao número total de instâncias em execução e pode ser especificado da seguinte forma:

    Envia um pedido a um serviço e uma versão específicos numa instância específica: 

    https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://INSTANCE_ID.VERSION_ID.SERVICE_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 seu serviço default.

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

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 define no seu ficheiro cron.

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, 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 e/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.

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.

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.

Encaminhamento no servidor de programação

Descobrir endereços de instâncias

O servidor de desenvolvimento local cria todas as instâncias de escalonamento manual no arranque. As instâncias dos serviços de escalabilidade automática e básica são geridas dinamicamente. O servidor atribui uma porta a cada serviço e os clientes podem depender do servidor para equilibrar a carga e selecionar uma instância automaticamente. As atribuições de portas para endereçar cada serviço aparecem no fluxo de mensagens de registo do servidor. Seguem-se as portas de uma app que define três serviços (o tipo de escalamento de cada serviço não é relevante):

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

Quando usa o endereço de um serviço (por exemplo, http://localhost:8082/), o servidor seleciona (ou cria) uma instância do serviço e envia o pedido para essa instância.

O servidor atribui portas únicas a cada instância de um serviço. Para descobrir estas portas, tem de usar o servidor de administração. Existe uma porta única para o servidor de administração, que aparece no registo de mensagens:

INFO Starting admin server at: http://localhost:8000

Este endereço direciona para a consola do servidor de administração. A partir daí, pode clicar em Instâncias para ver o estado dinâmico das instâncias da sua app:

Captura de ecrã da consola do administrador do dev_appserver

É apresentada uma entrada separada para cada instância manual e básica. Os números das instâncias são links com endereços de portas exclusivos para cada instância. Pode passar o cursor do rato sobre um link para ver a porta atribuída a essa instância ou clicar no link para enviar um pedido diretamente a essa instância.

Ficheiros de envio

Se a sua app incluir um ficheiro dispatch.yaml, o fluxo de mensagens de registo inclui uma porta de expedição:

INFO Starting dispatcher running at: http://localhost:8080

Os pedidos para esta porta são encaminhados de acordo com as regras no ficheiro de envio. O servidor não suporta regras de ficheiros dispatch.yaml que incluam nomes de anfitriões (por exemplo, url: "customer1.myapp.com/*"). As regras com padrões de caminhos relativos (url: "*/fun") funcionam, pelo que pode usar URLs como http://localhost/fun/mobile para alcançar instâncias. O servidor vai comunicar um erro no fluxo de registo se tentar iniciar uma aplicação com um ficheiro dispatch.yaml que contenha regras baseadas no anfitrião.

Restringir o acesso a um serviço

Por predefinição, todos os serviços são públicos. Se quiser restringir o acesso a um serviço, adicione o elemento login: admin aos respetivos controladores .

Detalhes adicionais sobre URLs do App Engine

Compreender 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.