Como as solicitações são roteadas

ID da região

O REGION_ID é um código que o Google atribui com base na região selecionada ao criar o aplicativo. A inclusão de REGION_ID.r nos URLs do App Engine é opcional para aplicativos atuais e em breve será obrigatória para todos os aplicativos novos.

Para garantir uma transição tranquila, estamos atualizando lentamente o App Engine para usar IDs da região. Se ainda não tivermos atualizado seu projeto do Google Cloud, você não verá um ID da região para o aplicativo. Como o ID é opcional para os aplicativos atuais, não é necessário atualizar os URLs ou fazer outras alterações quando o ID da região está disponível para os aplicativos já existentes.

Saiba mais sobre IDs da região.

Nesta página, descrevemos como as solicitações HTTP dos usuários chegam à versão apropriada de um serviço. As solicitações podem ser encaminhadas 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 roteia os padrões de URL específicos de acordo com as regras que você estabelece.

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.

Solicitações e domínios

Quando seu aplicativo estiver em execução no App Engine, você poderá usar o seguinte URL para enviar solicitações HTTP ao aplicativo:
https://PROJECT_ID.REGION_ID.r.appspot.com

em que PROJECT_ID é o código do projeto do Google Cloud que contém o aplicativo.

Esse URL envia solicitações para a versão do seu aplicativo que você configurou para receber tráfego.

Cada versão do aplicativo também tem um URL próprio para que você implante e teste 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 versão específica, além do código do projeto, da região e do nome de domínio appspot.com. Por exemplo: https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com.

Subdomínios

Os domínios appspot.com também são compatíveis com subdomínios do formato SUBDOMAIN-dot-PROJECT_ID.REGION_ID.r.appspot.com, em que SUBDOMAIN pode ser qualquer string permitida em uma parte de um nome de domínio, excluindo o caractere .. As solicitações enviadas a qualquer subdomínio dessa maneira são encaminhadas ao aplicativo.

Também é possível usar subdomínios com um URL específico da versão:
https://SUBDOMAIN-dot-VERSION_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com.

Para mais informações e exemplos, consulte Roteamento por URL.

Domínios personalizados

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

O nome de domínio está incluído nos dados da solicitação

O nome de domínio usado para a solicitação é 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, é possível codificar seu aplicativo para verificar o cabeçalho da solicitação Host e responder de acordo com o nome de domínio.

ID da região

O REGION_ID é um código que o Google atribui com base na região selecionada ao criar o aplicativo. A inclusão de REGION_ID.r nos URLs do App Engine é opcional para aplicativos atuais e em breve será obrigatória para todos os aplicativos novos.

Para garantir uma transição tranquila, estamos atualizando lentamente o App Engine para usar IDs da região. Se ainda não tivermos atualizado seu projeto do Google Cloud, você não verá um ID da região para o aplicativo. Como o ID é opcional para os aplicativos atuais, não é necessário atualizar os URLs ou fazer outras alterações quando o ID da região está disponível para os aplicativos já existentes.

Você pode usar as seguintes ferramentas para ver o código de região do seu aplicativo:

Console

No Console do Cloud, você pode ver os URLs dos aplicativos Instâncias, Serviços e Versões.

Todos esses URLs incluem o código 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 código da região.

Para visualizar o URL de um serviço que já foi implantado:

  1. 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, digite gcloud app versions list --service=default.

  2. Digite o comando gcloud app versions describe. A saída desse comando inclui o URL da versão com o código da região do aplicativo. Por exemplo, para descrever a versão 20191023t101741 para o serviço padrão, insira gcloud app versions describe 20191023t101741 --service=default

Roteamento por URL

É possível direcionar uma solicitação HTTP com vários graus de especificidade. Nos exemplos a seguir, REGION_ID.r.appspot.com pode ser substituído pelo domínio personalizado do seu aplicativo , se você tiver um. As substrings VERSION_ID, SERVICE_ID e PROJECT_ID do URL representam os códigos dos recursos do app.

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

Console

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

gcloud

Execute o comando gcloud app instances list para listar os IDs dos 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.

Roteamento padrão

Os padrões de URL a seguir têm um comportamento de roteamento padrão. Observe que o roteamento padrão será 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://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 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 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 eles existirem. 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-PROJECT_ID.REGION_ID.r.appspot.com
    https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN

Serviço padrão

O serviço default é criado quando você implanta a versão inicial do aplicativo no App Engine. Solicitações que em que nenhum serviço ou um serviço inválido é especificado são roteadas para o serviço default. Essas solicitações são processadas pelas versões que você configurou para receber tráfego no serviço default. Veja quais versões estão configuradas para o tráfego na página Versões do Console do Cloud.

Exemplo

Para ajudar a demonstrar os padrões de URL, suponha que exista um exemplo de projeto do Google Cloud com o ID requestsProject e inclua um aplicativo que esteja executando dois serviços e versões. O serviço default do aplicativo de exemplo inclui a versão vFrontend e o segundo serviço service2 inclui a versão vBackend. O Google atribuiu uc como código de região para os dois aplicativos.

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 direcionar a versão no serviço default usando HTTPS, é possível usar:

        https://vFrontend-dot-default-dot-requestsProject.uc.r.appspot.com
        https://vFrontend-dot-requestsProject.uc.r.appspot.com
    

  2. Para segmentar a versão vBackend usando um domínio personalizado, use:

    https://vBackend.service2.example.net
    https://vBackend.example.net
    

    em que requestsProject.uc.r.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, é 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.

Para 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 roteamento no arquivo de expedição, e cada regra consiste nos elementos service e url.

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

Para detalhes sobre como definir esse arquivo, consulte a documentação de referência do dispatch.yaml.

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