O Python 2 não é mais compatível com a comunidade. Recomendamos que você migre aplicativos do Python 2 para o Python 3.

Como as solicitações são roteadas

ID da região

O REGION_ID é um código abreviado que o Google atribui com base na região que você selecionou ao criar o aplicativo. O código não corresponde a um país ou estado, embora alguns IDs de região sejam semelhantes aos códigos de país e estado mais usados. A inclusão de REGION_ID.r em URLs do App Engine é opcional para aplicativos que já existem e, em breve, será obrigatória para todos os aplicativos novos.

Para garantir uma transição tranquila, estamos atualizando gradativamente o App Engine para usar IDs de 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 que já existem, não é necessário atualizar os URLs ou fazer outras alterações quando o ID da região estiver disponível para eles.

Saiba mais sobre IDs de 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 roteadas das seguintes maneiras:

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 Roteamento no servidor de desenvolvimento para saber mais.

Roteamento com URLs

Quando seu app estiver em execução no App Engine, será possível usar o seguinte URL para enviar solicitações HTTP ao app:
https://PROJECT_ID.REGION_ID.r.appspot.com

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

Esse URL envia solicitações para o serviço padrão do aplicativo na versão configurada para receber tráfego.

URLs para serviços e versões

Se você criar mais de um serviço no aplicativo, cada serviço terá seu próprio URL. Cada versão de um serviço também tem um URL próprio para que seja possível implantar e testar uma versão nova antes de configurá-la para receber o tráfego.

Os URLs de serviços e versões específicos estão no seguinte formato:

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

É possível omitir VERSION-dot- se não for necessário segmentar uma versão específica.

Para recuperar os IDs dos serviços e versões do aplicativo, é possível usar qualquer uma das seguintes ferramentas:

Console

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

gcloud

Execute o comando gcloud app instances list para listar os IDs de recursos em um projeto específico do Cloud.

API

Para recuperar programaticamente IDs de recursos, consulte os métodos de list na API Admin.

Exemplos de URL

Veja alguns exemplos de URLs do App Engine que mostram o domínio appspot.com que o App Engine atribui ao seu aplicativo e um domínio personalizado, que você pode configurar para o aplicativo.

  • 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 a eles 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

Roteamento com um arquivo de expedição

É possível criar um arquivo de expedição para modificar as regras de roteamento baseadas em URL do App Engine e definir suas próprias regras de roteamento 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.

Criar um arquivo de expedição

Para criar um arquivo de expedição:

  1. Crie um arquivo chamado dispatch.yaml na raiz do diretório do projeto ou no diretório raiz do serviço default.

  2. Defina regras de roteamento no arquivo conforme descrito na referência dispatch.yaml.

Observe o seguinte sobre as regras de roteamento:

  • É possível definir até 20 regras de roteamento. Cada regra precisa conter os elementos url e service.
  • As regras precisam usar padrões do URL de HTTP que incluam a notação "." para separar subdomínios. URLs definidos com a notação "-dot-" do HTTPS não são compatíveis.
  • As regras também se aplicam aos URLs definidos no arquivo cron.

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

Como implantar o arquivo de despacho

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

    gcloud app deploy dispatch.yaml

Roteamento com o Cloud Load Balancing

O Cloud Load Balancing é um produto separado que permite configurações avançadas de rede para todos os seus aplicativos em execução no Google Cloud.

Quando o balanceamento de carga HTTP(S) está ativado para aplicativos sem servidor, é possível:

  • Configurar seu aplicativo sem servidor para ser veiculado a partir de um endereço IPv4 e/ou IPv6 dedicado que não seja compartilhado com outros serviços.

  • Reutilizar os mesmos certificados SSL e chaves privadas usadas no Compute Engine, no Google Kubernetes Engine e no Cloud Storage. Isso elimina a necessidade de gerenciar certificados separados para aplicativos sem servidor.

O balanceador de carga não interfere nem interage com as regras de roteamento no arquivo 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.

Observe a seguinte limitação:

  • Não é possível desativar os URLs que o Google Cloud atribui automaticamente aos serviços do App Engine. Os usuários que já têm o URL padrão do serviço do App Engine podem ignorar o balanceador de carga e acessar diretamente o URL do serviço. Isso significa que mesmo que seja possível configurar políticas de segurança, certificados SSL e chaves privadas do Google Cloud Armor com o balanceador de carga, os usuários com o URL padrão podem burlar essas políticas.

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.

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.

Detalhes adicionais sobre URLs do App Engine

Noções básicas sobre o ID da região em URLs

REGION_ID é um código abreviado que o Google atribui com base na região que você seleciona ao criar seu app. O código não corresponde a um país ou uma província, mesmo que alguns IDs de região possam parecer semelhantes aos códigos de país e província mais usados. A inclusão de REGION_ID.r em URLs do App Engine é opcional para aplicativos que já existem e, em breve, será obrigatória para todos os aplicativos novos.

Para garantir uma transição tranquila, estamos atualizando gradativamente o App Engine para usar IDs de 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 aplicativos que já existem, não será necessário atualizar os URLs nem fazer outras alterações quando o ID da região estiver disponível para os aplicativos já existentes.

Use as seguintes ferramentas para ver o ID de região do seu aplicativo:

Console

No Console do Cloud, é possível ver os URLs das Instâncias, dos Serviços e das Versões dos aplicativos.

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

Para ver 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 ID 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

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

O nome de domínio usado para a solicitação está 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 app para verificar o cabeçalho da solicitação Host e responder de acordo com o nome de domínio.