Como as solicitações são encaminhadas

Nesta página, você aprenderá como as solicitações HTTP dos usuários chegam à versão apropriada de um serviço. As solicitações podem ser roteadas de duas maneiras:

  • As regras de roteamento padrão do App Engine se aplicam às solicitações com um URL que termina no nível do domínio.

  • Também é possível usar um arquivo de expedição que encaminha padrões de URL específicos de acordo com as regras que você estabelece.

Se você testar o aplicativo no servidor de desenvolvimento local, os recursos disponíveis de roteamento e expedição serão ligeiramente diferentes. Para criar de modo programático URLs que funcionem com servidores de produção e desenvolvimento, use o método get_hostname.

Consulte o roteamento no servidor de desenvolvimento para saber mais.

Solicitações e domínios

No App Engine, o nome de domínio da solicitação de entrada é usado para determinar se ela é destinada ao aplicativo. Uma solicitação com o nome de domínio http://[YOUR_PROJECT_ID].appspot.com é encaminhada ao app que tem o ID [YOUR_PROJECT_ID]. Todos os aplicativos recebem um nome de domínio appspot.com gratuitamente.

Os domínios appspot.com também são compatíveis com subdomínios no formato [SUBDOMAIN]-dot-[YOUR_PROJECT_ID].appspot.com, em que [SUBDOMAIN]pode ser qualquer string permitida em uma parte de um nome de domínio, exceto o caractere de ponto (.). As solicitações enviadas a qualquer subdomínio dessa maneira são encaminhadas ao aplicativo.

Configure um domínio de nível mais alto personalizado usando o G Suite e atribuir subdomínios a vários aplicativos como o Google Mail ou Sites. Também é possível associar um aplicativo do App Engine a um subdomínio. Para ver mais informações sobre como associar um domínio personalizado ao aplicativo, consulte Como proteger domínios personalizados com SSL.

As solicitações para esses URLs são todas encaminhadas para a versão do aplicativo configurada para receber o tráfego. Cada versão do aplicativo também tem um URL próprio para que você possa implantar e testar uma versão nova antes de configurá-la para receber o tráfego. O URL específico da versão usa o código de uma determinada versão, além do nome de domínio appspot.com. Por exemplo: http://[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com. Você também pode usar subdomínios com o URL específico da versão: http://[SUBDOMAIN]-dot-[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com. Consulte Como encaminhar por URL para mais informações e exemplos.

O nome de domínio usado para a solicitação está incluído nos dados da solicitação que são passados ao aplicativo. Portanto, é possível usar os dados da solicitação para controlar como o aplicativo responde, de acordo com o nome de domínio na solicitação. Por exemplo, para redirecionar para um domínio oficial, codifique o aplicativo para verificar o cabeçalho da solicitação Host e responder de acordo com o nome de domínio.

Roteamento por URL

É possível direcionar uma solicitação HTTP com vários graus de especificidade. Nos exemplos a seguir, appspot.com pode ser substituído pelo domínio personalizado do app, caso haja um. As substrings de URL [VERSION_ID], [SERVICE_ID] e [MY_PROJECT_ID] representam individualmente os IDs de recursos do aplicativo.

Dica: use as ferramentas a seguir para recuperar os IDs dos recursos do aplicativo:

Console

No Console do GCP, é possível ver as páginas correspondentes de Instâncias, Serviços e Versões.

gcloud

Execute o comando gcloud app instances list para gerar uma lista dos IDs de recursos específicos em um determinado projeto do GCP.

API

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

Roteamento padrão

Os padrões de URL a seguir têm um comportamento de roteamento padrão. Observe que o roteamento padrão é modificado se houver um padrão correspondente definido por você no arquivo de expedição:

  • Envia a solicitação para uma instância disponível do serviço default:
    https://[MY_PROJECT_ID].appspot.com
    http://[MY_CUSTOM_DOMAIN]

    As solicitações são recebidas por qualquer versão configurada para o recebimento do tráfego no serviço default.

  • Envia uma solicitação para uma instância disponível de um serviço específico:
    https://[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[SERVICE_ID].[MY_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-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[MY_CUSTOM_DOMAIN]

    Quando não há um serviço de destino, as solicitações são enviadas para o default.

Roteamento probabilístico

Quando uma solicitação corresponde à parte [YOUR_PROJECT_ID].appspot.com do nome do host, mas inclui um nome de serviço, versão ou instância que não existe, ela é encaminhada para o serviço default. O roteamento probabilístico não se aplica a domínios personalizados. As solicitações feitas para esse tipo de domínio 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_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[SERVICE_ID].[MY_PROJECT_ID].[MY_CUSTOM_DOMAIN]
  • Se você usa serviços escalonados manualmente, é possível direcionar e enviar uma solicitação a uma instância, basta incluir o ID da instância. Esse ID é um número inteiro no intervalo de 0 até o número total de instâncias em execução e pode ser especificado da seguinte maneira:

    Envia uma solicitação para um serviço e versão específicos em uma instância determinada:

    https://[INSTANCE_ID]-dot-[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[INSTANCE_ID].[VERSION_ID].[SERVICE_ID].[MY_CUSTOM_DOMAIN]

Serviço padrão

O serviço default é criado durante a implantação da versão inicial do aplicativo no App Engine. As solicitações que especificam o serviço como inexistente ou inválido são encaminhadas para o serviço default. Essas solicitações são processadas pelas versões configuradas para receber o tráfego no serviço default. Você pode ver quais versões estão configuradas para tráfego na página Versões do Console do GCP.

Restringir o acesso a um serviço

Todos os serviços são públicos por padrão. Se você quiser restringir o acesso a um serviço, adicione o elemento login: admin aos gerenciadores dele.

Exemplo

Para entender os padrões de URL, imagine um projeto do GCP com o código requestsProject, que inclui um aplicativo que executa dois serviços e versões. O serviço default do aplicativo de exemplo inclui a versão vFrontend. Já o segundo serviço (service2) inclui a versão vBackend.

Para fazer com que serviços e versões específicos sejam o destino das solicitações, use os padrões de URL a seguir:

  1. Para definir como destino a versão no serviço default por meio de HTTPS, use:

    https://vFrontend-dot-default-dot-requestsProject.appspot.com
    https://vFrontend-dot-requestsProject.appspot.com
    
  2. Para definir como destino a versão vBackend por meio de um domínio personalizado sem HTTPS, é possível usar:

    http://vBackend.service2.example.net
    http://vBackend.example.net
    

    em que requestsProject.appspot.com é mapeado para o domínio example.net.

Roteamento com um arquivo de expedição

Para URLs que usam os padrões descritos anteriormente, crie um arquivo de expedição para modificar as regras de roteamento do App Engine e definir suas próprias regras personalizadas. Com um arquivo de expedição, você pode enviar solicitações de entrada para um serviço específico com base no caminho ou nome do host no URL da solicitação.

Para mais detalhes sobre como criar um arquivo de expedição, consulte a referência do dispatch.yaml.

Como criar um arquivo de expedição

O arquivo de expedição precisa ser colocado na raiz do diretório do projeto ou no diretório raiz do serviço default. É possível definir até 20 regras de encaminhamento no arquivo de expedição. Cada regra é composta dos elementos service e url.

Por exemplo, você pode criar um arquivo de expedição para encaminhar solicitações de dispositivos móveis como http://simple-sample.appspot.com/mobile/ para um front-end móvel e encaminhar solicitações de trabalho como http://simple-sample.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

Consulte a documentação de referência do dispatch.yaml para mais detalhes sobre como defini-lo.

Como implantar o arquivo de expedição

Para implantar o arquivo de configuração de expedição, execute o seguinte comando:

gcloud

gcloud app deploy dispatch.yaml

appcfg

appcfg.py update_dispatch [YOUR_APP_DIR]

Como fazer roteamento no servidor de desenvolvimento

Como descobrir endereços de instâncias

O servidor de desenvolvimento local cria todas as instâncias de escalonamento manuais na inicialização. As instâncias para serviços de escalonamento automáticos e básicos são gerenciadas dinamicamente. O servidor atribui uma porta a cada serviço, e os clientes podem depender do servidor para balancear a carga e selecionar automaticamente uma instância. As atribuições de porta para endereçar cada serviço são exibidas no streaming de mensagens de registro do servidor. Aqui estão as portas de um app que define três serviços (o tipo de escalonamento 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 você usa o endereço de um serviço (por exemplo, http://localhost:8082/), o servidor selecionará (ou criará) uma instância do serviço e enviará a solicitação para essa instância.

O servidor atribui portas exclusivas a cada instância de um serviço. Para descobrir essas portas, você precisa usar o servidor de administrador. Há uma porta exclusiva para o servidor de administrador, exibida no registro da mensagem:

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

Esse endereço leva você ao console do servidor de administrador. Depois, clique em Instâncias para ver o estado dinâmico das instâncias do app:

Captura de tela do Admin Console do dev_appserver

Uma entrada separada será exibida para cada instância manual e básica. Os números da instância são links com endereços de porta exclusivos para cada instância. Passe o cursor do mouse sobre um link para ver a porta atribuída a essa instância ou clique no link a fim de enviar uma solicitação diretamente para essa instância.

Arquivos de despacho

Se o app incluir um arquivo dispatch.yaml, o streaming de mensagens de registro incluirá uma porta do agente:

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

As solicitações para essa porta são roteadas de acordo com as regras no arquivo de despacho. O servidor não aceita regras de arquivo dispatch.yaml que incluam nomes do host (por exemplo, url: "customer1.myapp.com/*"). As regras com padrões de caminho relativos (url: "*/fun") funcionarão. Dessa maneira, você usa URLs como http://localhost/fun/mobile para alcançar instâncias. O servidor relatará um erro no fluxo de registros se você tentar iniciar um aplicativo com um arquivo dispatch.yaml que contiver regras baseadas no host.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Ambiente padrão do App Engine para Python 2