Como a versão 5.5 do PHP não é mais compatível com a comunidade, recomendamos que novos aplicativos usem o ambiente de execução do PHP 7.

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.

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

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 maneira programática URLs que funcionem com servidores de produção e desenvolvimento, use a variável $_SERVER['HTTP_HOST'].

Consulte Roteamento no servidor de desenvolvimento para saber mais.

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
  • Se você usa serviços dimensionados manualmente, será possível direcionar e enviar uma solicitação a uma instância ao incluir a ID da instância. Essa 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 maneira a seguir:

    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-PROJECT_ID.REGION_ID.r.appspot.com
    https://INSTANCE_ID.VERSION_ID.SERVICE_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.

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 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 recebidas para 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 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 o dispatch.yaml, 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

appcfg

appcfg.py update_dispatch [YOUR_APP_DIR]

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 cria ou seleciona uma instância do serviço e envia 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 console de administração 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 seu aplicativo 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 dispatch.yaml regras de arquivo que incluam nomes do host (por exemplo, url: "customer1.myapp.com/*"). Regras com padrões de caminho relativo (url: "*/fun") funcionarão, então é possível usar URLs como http://localhost/fun/mobile para alcançar as 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.