Configurar um balanceador de carga de aplicativo externo global com o Cloud Run, App Engine ou Funções do Cloud Run

Nesta página, mostramos como criar um balanceador de carga de aplicativo externo para encaminhar solicitações para back-ends sem servidor. Aqui, o termo sem servidor refere-se aos seguintes produtos de computação sem servidor:

  • App Engine
  • Funções do Cloud Run
  • Cloud Run

A integração de balanceadores de carga aplicativo externos com o gateway de API permite que os back-ends sem servidor aproveitem todos os recursos fornecidos pelo Cloud Load Balancing. Para configurar um balanceador de carga de aplicativo externo para rotear o tráfego para um gateway de API, consulte Noções básicas sobre balanceador de carga de aplicativo externo para gateway de API. O suporte do balanceador de carga de aplicativo externo para o gateway de API está em visualização.

Os NEGs sem servidor permitem usar aplicativos sem servidor do Google Cloud com balanceadores de carga de aplicativo externos. Depois de configurar um balanceador de carga com o back-end NEG sem servidor, as solicitações para o balanceador de carga são roteadas para o back-end do aplicativo sem servidor.

Para saber mais sobre NEGs sem servidor, consulte a visão geral de NEGs sem servidor.

Se você já é usuário do balanceador de carga de aplicativo clássico, consulte a Visão geral da migração ao planejar uma nova implantação com o balanceador de carga de aplicativo externo global.

Antes de começar

  1. Implantar um serviço do App Engine, das Funções do Cloud Run ou do Cloud Run.
  2. Instale a CLI do Google Cloud, caso ainda não tenha feito isso.
  3. Configurar permissões.
  4. Adicione um recurso de certificado SSL.

Implantar um serviço do App Engine, das Funções do Cloud Run ou do Cloud Run

As instruções nesta página pressupõem que você já tenha um serviço do Cloud Run (totalmente gerenciado), das funções do Cloud Run ou do App Engine em execução.

No exemplo desta página, usamos o guia de início rápido do Cloud Run em Python para implantar um serviço do Cloud Run na região us-central1. O restante desta página mostra como configurar um balanceador de carga de aplicativo externo que usa um back-end NEG sem servidor para encaminhar solicitações para este serviço.

Se você ainda não implantou um aplicativo sem servidor ou se quiser testar um NEG sem servidor com um aplicativo de amostra, use um dos guias de início rápido a seguir. É possível criar um aplicativo sem servidor em qualquer região, mas você precisa usar a mesma região posteriormente para criar o NEG e o balanceador de carga sem servidor.

Cloud Run

Para criar um aplicativo Hello World simples, empacotá-lo em uma imagem de contêiner e implantá-la no Cloud Run, consulte o Guia de início rápido: criar e implantar.

Se você já tiver feito upload de um contêiner de amostra para o Container Registry, consulte Guia de início rápido: implantar um contêiner de amostra predefinido.

Funções do Cloud Run

Consulte Funções do Cloud Run: guia de início rápido do Python.

App Engine

Consulte os seguintes guias de início rápido do App Engine para Python 3:

Instale a CLI do Google Cloud

Instale a CLI do Google Cloud. Consulte Visão geral do gcloud para ver informações conceituais e de instalação sobre a ferramenta.

Caso ainda não tenha usado a CLI , primeiro execute gcloud init para inicializar o diretório do gcloud.

Configurar permissões

Para seguir este guia, você precisa criar um NEG sem servidor e um balanceador de carga HTTP(S) externo em um projeto. É necessário ser proprietário ou editor de um projeto ou ter os seguintes papéis de IAM do Compute Engine:

Tarefa Papel necessário
Criar balanceador de carga e componentes de rede Administrador de rede
Criar e modificar NEGs Administrador da instância do Compute
Criar e modificar certificados SSL Administrador de segurança

Reservar um endereço IP externo

Agora que seus serviços estão funcionando, configure um endereço IP externo, estático e global que seus clientes possam usar para alcançar seu balanceador de carga.

Console

  1. No console do Google Cloud, acesse a página Endereços IP externos.

    Acessar Endereços IP externos

  2. Clique em Reservar endereço IP estático externo.

  3. Em Nome, insira example-ip.

  4. Em Nível de serviço de rede, selecione Premium.

  5. Em Versão IP, selecione IPv4.

  6. Em Tipo, selecione Global.

  7. Clique em Reservar.

gcloud

gcloud compute addresses create example-ip \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

Anote o endereço IPv4 que foi reservado:

gcloud compute addresses describe example-ip \
    --format="get(address)" \
    --global

É possível criar um recurso de certificado SSL

Para criar um balanceador de carga HTTPS, é necessário adicionar um recurso de certificado SSL ao front-end do balanceador de carga. Crie um recurso de certificado SSL usando um certificado SSL gerenciado pelo Google ou um certificado SSL autogerenciado.

  • Certificados gerenciados pelo Google. O uso de certificados gerenciados pelo Google é recomendado porque o Google Cloud recebe, gerencia e renova esses certificados automaticamente. Para criar um certificado gerenciado pelo Google, você precisa ter um domínio e os registros DNS desse domínio para que o certificado seja provisionado. Além disso, você precisa atualizar o registro DNS A do domínio para apontar para o endereço IP do balanceador de carga criado na etapa anterior (example-ip). Para instruções detalhadas, consulte Como usar certificados gerenciados pelo Google.

  • Certificados autoassinados. Se você não quiser configurar um domínio agora, use um certificado SSL autoassinado para o teste.

Este exemplo pressupõe que você já criou um recurso de certificado SSL.

Se você quiser testar esse processo sem criar um recurso de certificado SSL (ou um domínio conforme exigido pelos certificados gerenciados pelo Google), ainda será possível usar as instruções nesta página para configurar uma carga HTTP.

Criar o balanceador de carga

No diagrama a seguir, o balanceador de carga usa um back-end NEG sem servidor para direcionar solicitações para um serviço do Cloud Run sem servidor. Neste exemplo, usamos o guia de início rápido do Cloud Run Python para implantar um serviço do Cloud Run.

Arquitetura do balanceador de carga de aplicativo externo para um aplicativo do Cloud Run.
Arquitetura do balanceador de carga de aplicativo externo para um aplicativo do Cloud Run (clique para ampliar).

Como as verificações de integridade não são compatíveis com serviços de back-end com back-ends de NEG sem servidor, você não precisa criar uma regra de firewall que permita verificações de integridade se o balanceador de carga tiver apenas back-ends de NEG sem servidor.

Console

Iniciar a configuração

  1. No console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique em Criar balanceador de carga.
  3. Em Tipo de balanceador de carga, selecione Balanceador de carga de aplicativo (HTTP/HTTPS) e clique em Próxima.
  4. Em Voltado ao público ou interno, selecione Voltado ao público (externo) e clique em Próxima.
  5. Em Implantação global ou de região única, selecione Melhor para cargas de trabalho globais e clique em Próxima.
  6. Em Geração do balanceador de carga, selecione Balanceador de carga de aplicativo externo global e clique em Próxima.
  7. Clique em Configurar.

Configuração básica

  1. Digite serverless-lb como o nome do balanceador de carga.
  2. Mantenha a janela aberta para continuar.

Configuração de front-end

  1. Clique em Configuração de front-end.
  2. Em Nome, digite um nome.
  3. Para criar um balanceador de carga HTTPS, é necessário ter um certificado SSL (gcloud compute ssl-certificates list).

    Recomendamos o uso de um certificado gerenciado pelo Google, conforme descrito anteriormente.

    4. Para configurar um balanceador de carga de aplicativo externo, preencha os campos da seguinte maneira.

    Verifique se as seguintes opções estão configuradas com estes valores:

    Propriedade Valor: digite um valor ou selecione uma opção conforme especificado
    Protocolo HTTPS
    Nível de serviço da rede Premium
    Versão IP IPv4
    Endereço IP example-ip
    Porta 443
    Opcional: tempo limite do sinal de atividade HTTP Insira um valor de tempo limite de 5 a 1.200 segundos. O valor padrão é de 610 segundos.
    Certificado Selecione um certificado SSL existente ou crie um novo.

    Para criar um balanceador de carga HTTPS, você precisa ter um recurso de certificado SSL para usar no proxy HTTPS. É possível criar um recurso de certificado SSL usando um certificado SSL gerenciado pelo Google ou um certificado SSL autogerenciado.
    Para criar um certificado gerenciado pelo Google, você precisa ter um domínio. O registro A do domínio precisa ser resolvido para o endereço IP do balanceador de carga (neste exemplo, example-ip). É recomendável usar certificados gerenciados pelo Google porque o Google Cloud recebe, gerencia e renova esses certificados automaticamente. Se você não tiver um domínio, será possível usar um certificado SSL autoassinado para testes.
    Opcional: ativar o redirecionamento de HTTP para HTTPS Use essa caixa de seleção para ativar os redirecionamentos de HTTP para HTTPS.

    Ativar esta caixa de seleção cria um balanceador de carga HTTP parcial que utiliza o mesmo endereço IP que o balanceador de carga HTTPS e redireciona solicitações HTTP para o front-end HTTPS do balanceador de carga.

    Essa caixa de seleção só poderá ser marcada quando o protocolo HTTPS estiver selecionado e um endereço IP reservado for utilizado.

    Se você quiser testar esse processo sem configurar um recurso de certificado SSL (ou um domínio conforme exigido pelos certificados gerenciados pelo Google), configure um balanceador de carga HTTP.

    Para criar um balanceador de carga HTTP, verifique se as seguintes opções estão configuradas com estes valores:

    Propriedade Valor: digite um valor ou selecione uma opção conforme especificado
    Protocolo HTTP
    Nível de serviço da rede Premium
    Versão IP IPv4
    Endereço IP example-ip
    Porta 80
    Opcional: tempo limite do sinal de atividade HTTP Insira um valor de tempo limite de 5 a 1.200 segundos. O valor padrão é de 610 segundos.
  4. Clique em Concluído.

Configuração de back-end

  1. Clique em Configuração de back-end.
  2. Na lista Serviços e buckets de back-end, clique em Criar um serviço de back-end.
  3. Em Nome, digite um nome.
  4. Em Tipo de back-end, selecione Grupo de endpoints de rede sem servidor.
  5. Deixe o Protocolo inalterado. Este parâmetro é ignorado.
  6. Na seção Back-ends, em Novo back-end, selecione Criar grupo de endpoints de rede sem servidor.
  7. Em Nome, digite um nome.
  8. Em Região, selecione us-central1 e depois Cloud Run.
  9. Selecione Selecionar nome do serviço.
  10. Na lista Serviço, selecione o serviço do Cloud Run para o qual você quer criar um balanceador de carga.
  11. Clique em Criar.
  12. Na seção Novo back-end, clique em Concluído.
  13. Clique em Criar.

Regras de roteamento

As regras de roteamento determinam como o tráfego é direcionado. Para configurar o roteamento, configure regras de host e correspondências de caminho, que são componentes de configuração do mapa de URLs de um balanceador de carga de aplicativo externo.

  1. Clique em Regras de roteamento.

  2. Mantenha os hosts e caminhos padrão. Neste exemplo, todas as solicitações vão para o serviço de back-end criado na etapa anterior.

Como verificar a configuração

  1. Clique em Analisar e finalizar.
  2. Revise todas as configurações.
  3. Opcional: clique em Código equivalente para conferir a solicitação de API REST que será usada para criar o balanceador de carga.
  4. Clique em Criar.
  5. Aguarde o balanceador de carga ser criado.
  6. Clique no nome do balanceador de carga (serverless-lb).
  7. Anote o endereço IP do balanceador de carga para a próxima tarefa. Ele é referenciado como IP_ADDRESS.

gcloud

  1. Crie um NEG sem servidor para o app sem servidor.

    Para criar um NEG sem servidor com um serviço do Cloud Run: 

       gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \
       --region=us-central1 \
       --network-endpoint-type=serverless  \
       --cloud-run-service=CLOUD_RUN_SERVICE_NAME
    Para mais opções, consulte o guia de referência do gcloud para gcloud compute network-endpoint-groups create.
  2. Crie um serviço de back-end. 
       gcloud compute backend-services create BACKEND_SERVICE_NAME \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --global
  3. Adicione o NEG sem servidor como um back-end ao serviço de back-end: 
       gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --global \
       --network-endpoint-group=SERVERLESS_NEG_NAME \
       --network-endpoint-group-region=us-central1
  4. Crie um mapa de URL para encaminhar solicitações recebidas para o serviço de back-end : 
       gcloud compute url-maps create URL_MAP_NAME \
       --default-service BACKEND_SERVICE_NAME

    Este mapa de URL de exemplo segmenta apenas um serviço de back-end que representa um único app sem servidor. Portanto, não é necessário configurar regras de host ou correspondências de caminho. Se você tiver mais de um serviço de back-end, poderá usar regras de host para direcionar solicitações para serviços diferentes com base no nome do host e configurar correspondências de caminho para direcionar solicitações para serviços diferentes com base no caminho da solicitação.

  5. Para criar um balanceador de carga HTTPS, você precisa ter um recurso de certificado SSL para usar no proxy HTTPS. É possível criar um recurso de certificado SSL usando um certificado SSL gerenciado pelo Google ou um certificado SSL autogerenciado. O uso de certificados gerenciados pelo Google é recomendado porque o Google Cloud recebe, gerencia e renova esses certificados automaticamente.

    Para criar um certificado gerenciado pelo Google, você precisa ter um domínio. Se você não tiver um domínio, será possível usar um certificado SSL autoassinado para testes.

    Para criar um recurso de certificado SSL gerenciado pelo Google: 
       gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
       --domains DOMAIN
    Para criar um recurso de certificado SSL autogerenciado: 
       gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
       --certificate CRT_FILE_PATH \
       --private-key KEY_FILE_PATH

  6. Crie um proxy de destino HTTP(S) para encaminhar solicitações ao mapa de URLs.

    Para um balanceador de carga HTTP, crie um proxy de destino HTTP:

       gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
      --url-map=URL_MAP_NAME

    Para um balanceador de carga HTTPS, crie um proxy de destino HTTPS. O proxy é a parte do balanceador de carga onde é armazenado o certificado SSL para balanceamento de carga HTTPS, portanto, nesta etapa carregue também o certificado.

       gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
       --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
       --ssl-certificates=SSL_CERTIFICATE_NAME \
       --url-map=URL_MAP_NAME

    Substitua:

    • TARGET_HTTP_PROXY_NAME: o nome do proxy HTTP de destino.
    • TARGET_HTTPS_PROXY_NAME: o nome do proxy HTTPS de destino.
    • HTTP_KEEP_ALIVE_TIMEOUT_SEC: um campo opcional usado para especificar o tempo limite do sinal de atividade HTTP do cliente. O valor de tempo limite precisa ser de 5 a 1.200 segundos. O valor padrão é de 610 segundos.
    • SSL_CERTIFICATE_NAME: o nome do certificado SSL.
    • URL_MAP_NAME: o nome do mapa de URL.
  7. Crie uma regra de encaminhamento para encaminhar as solicitações recebidas para o proxy.

    Para um balanceador de carga HTTP:

       gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \
   --load-balancing-scheme=EXTERNAL_MANAGED \
   --network-tier=PREMIUM \
   --address=example-ip \
   --target-http-proxy=TARGET_HTTP_PROXY_NAME \
   --global \
   --ports=80

    Para um balanceador de carga HTTPS:

       gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --network-tier=PREMIUM \
       --address=example-ip \
       --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
       --global \
       --ports=443

Como conectar seu domínio ao balanceador de carga

Após a criação do balanceador de carga, anote o endereço IP associado a ele, por exemplo, 30.90.80.100. Para apontar seu domínio para o balanceador de carga, crie um registro A usando o serviço de registro de domínio. Se você adicionou vários domínios ao certificado SSL, adicione um registro A para cada um deles, todos apontando para o endereço IP do balanceador de carga. Por exemplo, para criar registros A para www.example.com e example.com, use o seguinte:

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

Se você usa o Cloud DNS como provedor de DNS, consulte Adicionar, modificar e excluir registros.

Testar o balanceador de carga

Agora que você configurou o balanceador de carga, é possível começar a enviar tráfego para o endereço IP dele. Se você tiver configurado um domínio, também será possível enviar tráfego para o nome do domínio. No entanto, a propagação de DNS pode levar algum tempo para ser concluída. Portanto, é possível começar usando o endereço IP para o teste.

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique no balanceador de carga que você acabou de criar.

  3. Anote o Endereço IP do balanceador de carga.

  4. Para um balanceador de carga HTTP, é possível testar seu balanceador de carga usando um navegador da Web acessando http://IP_ADDRESS. Substitua IP_ADDRESS pelo endereço IP do balanceador de carga. Você será direcionado para a página inicial do serviço helloworld.

  5. Para um balanceador de carga HTTPS, é possível testar seu balanceador de carga usando um navegador da Web acessando https://IP_ADDRESS. Substitua IP_ADDRESS pelo endereço IP do balanceador de carga. Você será direcionado para a página inicial do serviço helloworld.
    Se isso não funcionar e você estiver usando um certificado gerenciado pelo Google, confirme se o status do recurso do certificado é "ATIVO". Para mais informações, consulte Status do recurso de certificado SSL gerenciado pelo Google.
    Caso você tenha usado um certificado autoassinado durante o teste, o navegador exibirá um aviso. Você precisa permitir que o navegador aceite um certificado autoassinado. Clique no aviso para ver a página real.

Outras opções de configuração

Nesta seção, o exemplo é detalhado para fornecer outras opções de configuração. Todas as tarefas são opcionais. É possível realizá-las em qualquer ordem.

Configurar o balanceamento de carga multirregional

No exemplo descrito anteriormente nesta página, temos apenas um serviço do Cloud Run servindo como back-end na região us-central1. Como o NEG sem servidor pode apontar para apenas um endpoint por vez, o balanceamento de carga não é executado em várias regiões. O balanceador de carga de aplicativo externo serve apenas como o front-end e envia o tráfego via proxy para o endpoint do aplicativo helloworld especificado. No entanto, convém disponibilizar o aplicativo do Cloud Run em mais de uma região para melhorar a latência do usuário final.

Se um serviço de back-end tiver vários NEGs sem servidor anexados a ele, o balanceador de carga equilibra o tráfego encaminhando solicitações para o NEG sem servidor na região disponível mais próxima. No entanto, os serviços de back-end só podem conter um NEG sem servidor por região. Para disponibilizar o serviço do Cloud Run em várias regiões, você precisará configurar o roteamento entre regiões. Você precisará usar um único esquema de URL que funcione em qualquer lugar do mundo, mas que exiba solicitações de usuários da região mais próxima do usuário.

Para configurar a exibição multirregional, você precisará usar o nível de rede Premium para garantir que todas as implantações regionais do Cloud Run sejam compatíveis e estejam prontas para veicular o tráfego de qualquer região.

Para configurar um balanceador de carga multirregional:

  1. Configure dois serviços do Cloud Run em regiões diferentes. Vamos supor que você implantou dois serviços do Cloud Run: um em uma região dos EUA e outro em uma região da Europa.
  2. Crie um balanceador de carga de aplicativo externo com a seguinte configuração:
    1. Configure um serviço de back-end global com dois NEGs sem servidor:
      1. Crie o primeiro NEG na mesma região do serviço do Cloud Run implantado nos EUA.
      2. Crie o segundo NEG na mesma região do serviço do Cloud Run implantado na Europa.
    2. Defina sua configuração de front-end com o Nível de serviço de rede Premium.

A configuração resultante é mostrada no diagrama a seguir.

Roteamento multirregional para aplicativos sem servidor.
Roteamento multirregional para aplicativos sem servidor

Esta seção se baseia na configuração do balanceador de carga descrita anteriormente nesta página, em que você criou um NEG sem servidor na região us-central1 que aponta para um serviço do Cloud Run na mesma região. Ela também pressupõe que você criou um segundo serviço do Cloud Run na região europe-west1. O segundo NEG sem servidor que você criar apontará para esse serviço do Cloud Run na região europe-west1.

Neste exemplo, você concluirá as seguintes etapas:

  1. Crie um segundo NEG sem servidor na região europe-west1.
  2. Anexe o segundo NEG sem servidor ao serviço de back-end.

Para adicionar um segundo NEG sem servidor a um serviço de back-end, siga estas etapas.

Console

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique no nome do balanceador de carga em que está o serviço de back-end a ser editado.

  3. Na página Detalhes do balanceador de carga, clique em Editar.

  4. Na página Editar balanceador de carga externo do aplicativo, clique em Configuração de back-end.

  5. Na página Configuração de back-end, clique em Editar no serviço de back-end que você quer modificar.

  6. Na seção Back-ends, clique em Adicionar um back-end.

  7. Na lista Grupos de endpoints de rede sem servidor, selecione Criar grupo de endpoints de rede sem servidor.

  8. Insira um nome para o NEG sem servidor.

  9. Em Região, selecione europe-west1.

  10. Em Tipo de grupo de endpoints de rede sem servidor, selecione Cloud Run e faça o seguinte:

    1. Selecione a opção Selecionar serviço.
    2. Na lista Serviço, selecione o serviço do Cloud Run para o qual você quer criar um balanceador de carga.

  11. Clique em Criar.

  12. Na página Novo back-end, clique em Concluído.

  13. Clique em Salvar.

  14. Para atualizar o serviço de back-end, clique em Atualizar.

  15. Para atualizar o balanceador de carga, na página Editar balanceador de carga de aplicativo externo global, clique em Atualizar.

gcloud

  1. Crie um segundo NEG sem servidor na mesma região em que o serviço do Cloud Run está implantado.

    gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME_2 \
  --region=europe-west1 \
  --network-endpoint-type=SERVERLESS \
  --cloud-run-service=CLOUD_RUN_SERVICE_2

    Substitua:

    • SERVERLESS_NEG_NAME_2: o nome do segundo NEG sem servidor
    • CLOUD_RUN_SERVICE_2: o nome do serviço do Cloud Run

  2. Adicione o segundo NEG sem servidor como back-end ao serviço de back-end:

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --global \
  --network-endpoint-group=SERVERLESS_NEG_NAME_2 \
  --network-endpoint-group-region=europe-west1

    Substitua:

    • BACKEND_SERVICE_NAME: o nome do serviço de back-end
    • SERVERLESS_NEG_NAME_2: o nome do segundo NEG sem servidor

Usar uma assinatura de push do Pub/Sub autenticada com uma implantação de várias regiões do Cloud Run

Para solicitações de push autenticadas, o Cloud Run espera um campo de público-alvo específico da região por padrão. No caso de uma implantação multirregional do Cloud Run, se a solicitação de push for roteada para um serviço do Cloud Run em uma região diferente, a verificação do token JWT falhará devido a uma incompatibilidade de público-alvo.

Para contornar essa restrição específica de região:

  1. Configure um público-alvo personalizado que seja o mesmo para implantações de serviço em regiões diferentes.
  2. Configure as mensagens de push do Pub/Sub para usar o público-alvo personalizado como o público-alvo no token JWT.

Configurar o roteamento regional

Um motivo comum para exibir aplicativos de várias regiões é atender aos requisitos de localidade de dados. Por exemplo, é possível garantir que as solicitações feitas por usuários europeus sejam sempre exibidas de uma região localizada na Europa. Para configurar isso, você precisa de um esquema com URLs separados para usuários da UE e usuários não pertencentes à UE, além de direcionar os usuários da UE para os URLs da UE.

Nesse cenário, você usa o mapa de URLs para encaminhar solicitações de URLs específicos para as regiões correspondentes. Nessa configuração, as solicitações feitas para uma região nunca são entregues a uma região diferente. Isso fornece isolamento entre as regiões. Por outro lado, quando uma região falha, as solicitações não são roteadas para uma região diferente. Portanto, essa configuração não aumenta a disponibilidade do serviço.

Para configurar o roteamento regional, você precisará usar o nível de rede Premium para combinar diferentes regiões em uma única regra de encaminhamento.

Para configurar um balanceador de carga com roteamento regional:

  1. Configure dois serviços do Cloud Run em regiões diferentes. Vamos supor que você tenha implantado dois serviços do Cloud Run: hello-world-eu em uma região na Europa e hello-world-us em uma região nos EUA.
  2. Crie um balanceador de carga de aplicativo externo com a seguinte configuração:
    1. Configure um serviço de back-end com um NEG sem servidor na Europa. O NEG sem servidor precisa ser criado na mesma região do serviço do Cloud Run implantado na Europa.
    2. Configure um segundo serviço de back-end com outro NEG sem servidor nos EUA. Esse NEG sem servidor precisa ser criado na mesma região do serviço do Cloud Run implantado nos EUA.
    3. Configure seu mapa de URL com as regras de host e caminho apropriadas para que um conjunto de URLs seja encaminhado para o serviço de back-end europeu, enquanto todas as solicitações serão encaminhadas para o serviço de back-end dos EUA.
    4. Defina sua configuração de front-end com o nível de rede Premium.

O restante da configuração pode ser o mesmo descrito anteriormente. A configuração resultante será semelhante a esta:

Roteamento regional para aplicativos sem servidor sem failover.
Roteamento regional para aplicativos sem servidor sem failover

Usar uma máscara de URL

Ao criar um NEG sem servidor, em vez de selecionar um serviço específico do Cloud Run, use uma máscara de URL para apontar para vários serviços exibidos no mesmo domínio. Uma máscara de URL é um modelo do esquema de URL. O NEG sem servidor usará esse modelo para extrair o nome do serviço do URL da solicitação recebida e mapear a solicitação para o serviço apropriado.

As máscaras de URL são particularmente úteis se o serviço estiver mapeado para um domínio personalizado em vez do endereço padrão fornecido pelo Google Cloud para o serviço implantado. Uma máscara de URL permite segmentar vários serviços e versões com uma única regra, mesmo quando seu aplicativo usa um padrão personalizado do URL.

Se você ainda não tiver feito isso, leia Visão geral do NEGS sem servidor: máscaras de URL.

Criar uma máscara de URL

Para criar uma máscara de URL para o balanceador de carga, comece com o URL do serviço. Neste exemplo, usaremos um aplicativo de amostra sem servidor em execução em https://example.com/login. Esse é o URL em que o serviço login do aplicativo será exibido.

  1. Remova o http ou o https do URL. Você ainda tem example.com/login.
  2. Substitua o nome do serviço por um marcador para a máscara de URL.
    1. Cloud Run: substitua o nome do serviço do Cloud Run pelo marcador <service>. Se o serviço do Cloud Run tiver uma tag associada a ele, substitua o nome da tag pelo marcador <tag>. Neste exemplo, a máscara de URL restante é example.com/<service>.
    2. Funções do Cloud Run: substitua o nome da função pelo marcador <function>. Neste exemplo, a máscara de URL restante é example.com/<function>.
    3. App Engine: substitua o nome do serviço pelo marcador <service>. Se o serviço tiver uma versão associada a ele, substitua a versão pelo marcador <version>. Neste exemplo, a máscara de URL restante é example.com/<service>.
    4. Gateway de API: substitua o nome do gateway pelo marcador <gateway>. Neste exemplo, a máscara de URL restante é example.com/<gateway>.

  3. (Opcional) Se o nome do serviço (ou função, versão ou tag) puder ser extraído da parte do caminho do URL, o domínio poderá ser omitido. A parte do caminho da máscara de URL é diferenciada pelo primeiro caractere /. Se um / não estiver presente na máscara de URL, a máscara será entendida para representar apenas o host. Portanto, para este exemplo, a máscara de URL pode ser reduzida para /<service>, /<gateway> ou/<function>.

    Da mesma forma, se o nome do serviço puder ser extraído da parte do host do URL, será possível omitir o caminho completamente da máscara de URL.

    Também é possível omitir todos os componentes de host ou subdomínio que vêm antes do primeiro marcador, bem como qualquer componente de caminho que vem depois do último marcador. Nesses casos, o marcador captura as informações necessárias para o componente.

Veja mais alguns exemplos que demonstram essas regras:

Cloud Run

Nesta tabela, pressupomos que você tenha um domínio personalizado chamado example.com e que todos os serviços do Cloud Run estejam sendo mapeados para esse domínio usando um balanceador de carga de aplicativo externo.

Serviço, nome da tag URL de domínio personalizado Máscara de URL
serviço: login https://login-home.example.com/web <service>-home.example.com
serviço: login https://example.com/login/web example.com/<service> ou /<service>
service: login, tag: test https://test.login.example.com/web <tag>.<service>.example.com
service: login, tag: test https://example.com/home/login/test example.com/home/<service>/<tag> ou /home/<service>/<tag>
service: login, tag: test https://test.example.com/home/login/web <tag>.example.com/home/<service>

Funções do Cloud Run

Nesta tabela, pressupomos que você tenha um domínio personalizado chamado example.com e que todos os serviços das funções do Cloud Run estejam sendo mapeados para esse domínio.

Nome da função URL de domínio personalizado Máscara de URL
Login https://example.com/login /<function>
Login https://example.com/home/login /home/<function>
Login https://login.example.com <function>.example.com
Login https://login.home.example.com <function>.home.example.com

App Engine

Nesta tabela, pressupomos que você tenha um domínio personalizado chamado example.com e que todos os seus serviços do App Engine estejam sendo mapeados para esse domínio.

Nome do serviço, versão URL de domínio personalizado Máscara de URL
serviço: login https://login.example.com/web <service>.example.com
serviço: login https://example.com/home/login/web example.com/home/<service>, or /home/<service>
serviço: login, versão: test https://test.example.com/login/web <version>.example.com/<service>
serviço: login, versão: test https://example.com/login/test example.com/<service>/<version>

API Gateway

Nesta tabela, pressupomos que você tenha um domínio personalizado chamado example.com e que todos os serviços do Cloud Functions estejam sendo mapeados para esse domínio.

Nome do gateway URL de domínio personalizado do gateway de API(visualização) Máscara de URL
login https://example.com/login /<gateway>
login https://example.com/home/login /home/<gateway>
login https://login.example.com <gateway>.example.com
login https://login.home.example.com <gateway>.home.example.com

Criar um NEG sem servidor com uma máscara de URL

Console

Para um novo balanceador de carga, é possível usar o mesmo processo completo conforme descrito anteriormente neste tópico. Ao configurar o serviço de back-end, em vez de selecionar um serviço específico, insira uma máscara de URL.

Se você tiver um balanceador de carga, poderá editar a configuração do back-end e fazer com que o ponto de NEG sem servidor acesse uma máscara de URL, em vez de um serviço específico.

Para adicionar um NEG sem base baseado em máscara de URL a um serviço de back-end atual:

  1. Acesse a página Balanceamento de carga no Console do Google Cloud.
    Acessar a página "Balanceamento de carga"
  2. Clique no nome do balanceador de carga em que está o serviço de back-end a ser editado.
  3. Na página Detalhes do balanceador de carga, clique em Editar .
  4. Na página Editar balanceador de carga externo do aplicativo, clique em Configuração de back-end.
  5. Na página Configuração de back-end, clique em Editar no serviço de back-end que você quer modificar.
  6. Clique em Adicionar back-end.
  7. Selecione Criar grupo de endpoints da rede sem servidor.
    1. Em Nome, insira helloworld-serverless-neg.
    2. Em Região, selecione us-central1.
    3. Em Tipo de grupo de endpoints de rede sem servidor, selecione a plataforma em que os aplicativos (ou serviços ou funções) sem servidor foram criados.
      1. Selecione Usar máscara de URL.
      2. Insira uma máscara de URL. Para receber instruções sobre como criar uma máscara de URL, consulte Como criar uma máscara de URL.
      3. Clique em Criar.
  8. Na seção Novo back-end, clique em Concluído.
  9. Clique em Atualizar.

gcloud: Cloud Run

Para criar um NEG sem servidor com uma máscara de URL de amostra de example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --cloud-run-url-mask="example.com/<service>"

gcloud: funções do Cloud Run

Para criar um NEG sem servidor com uma máscara de URL de amostra de example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
 --region=us-central1 \
 --network-endpoint-type=serverless \
 --cloud-function-url-mask="example.com/<service>"

gcloud: App Engine

Para criar um NEG sem servidor com uma máscara de URL de amostra de example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --app-engine-url-mask="example.com/<service>"

gcloud: Gateway de API

Para criar um NEG sem servidor com uma máscara de URL de amostra de example.com/<gateway>:

gcloud beta compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway \
  --serverless-deployment-url-mask="example.com/<gateway>"

Para saber como o balanceador de carga lida com problemas com incompatibilidades de máscara de URL, consulte Solução de problemas com NEGs sem servidor.

Mover seu domínio personalizado para que ele seja exibido pelo balanceador de carga de aplicativo externo

Se os aplicativos de computação sem servidor estiverem sendo mapeados para domínios personalizados, atualize os registros DNS para que o tráfego enviado para os URLs de domínio personalizados do Cloud Run (totalmente gerenciado), das funções do Cloud Run ou do App Engine seja roteado pelo balanceador de carga.

Por exemplo, se você tiver um domínio personalizado chamado example.com e todos os serviços do Cloud Run estiverem mapeados para esse domínio, atualize o registro DNS de example.com para apontar para o endereço IP do balanceador de carga.

Antes de atualizar os registros DNS, teste a configuração localmente forçando a resolução de DNS local do domínio personalizado para o endereço IP do balanceador de carga. Para testar localmente, modifique o arquivo /etc/hosts/ na máquina local para apontar example.com para o endereço IP do balanceador de carga ou use a sinalização curl --resolve para forçar curl a usar o IP do balanceador de carga para a solicitação.

Quando o registro DNS de example.com é resolvido para o endereço IP do balanceador de carga HTTP(S), as solicitações enviadas para example.com começam a ser roteadas por meio do balanceador de carga. O balanceador de carga os envia ao serviço de back-end relevante de acordo com o mapa de URL. Além disso, se o serviço de back-end estiver configurado com uma máscara de URL, o NEG sem servidor usará a máscara para encaminhar a solicitação para o serviço apropriado do Cloud Run, das funções do Cloud Run ou do App Engine.

Ativar o Cloud CDN

Ativar o Cloud CDN para o serviço Cloud Run permite otimizar o envio de conteúdo armazenando-o em cache próximo aos usuários.

É possível ativar o Cloud CDN em serviços de back-end usados por balanceadores de carga de aplicativo externos globais usando o comando gcloud compute backend-services update.

gcloud compute backend-services update helloworld-backend-service 

    --enable-cdn 

    --global

O Cloud CDN é compatível com serviços de back-end com back-ends do Cloud Run, as funções do Cloud Run, gateway de API e App Engine.

Ativar o IAP no balanceador de carga externo do aplicativo

Observação: o IAP não é compatível com o Cloud CDN.

É possível configurar o IAP para ser ativado ou desativado (padrão). Se ativado, você precisa fornecer valores para oauth2-client-id e oauth2-client-secret.

Para ativar o IAP, atualize o serviço de back-end para incluir a sinalização --iap=enabled com o oauth2-client-id e oauth2-client-secret.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \
    --global

Se preferir, ative o IAP para um recurso do Compute Engine usando o console do Google Cloud, a gcloud CLI ou a API do Google Cloud.

Ativar o Google Cloud Armor

O Google Cloud Armor é um produto de segurança que fornece proteção contra ataques distribuídos de negação de serviço (DDoS, na sigla em inglês) a todos os balanceadores de carga de proxy GCLB. O Google Cloud Armor também fornece políticas de segurança configuráveis para serviços acessados por um balanceador de carga de aplicativo externo. Para saber mais sobre as políticas de segurança do Google Cloud Armor para balanceadores de carga de aplicativo externos, consulte Visão geral da política de segurança do Google Cloud Armor.

Se você estiver usando as funções do Cloud Run, será possível garantir que as solicitações sejam enviadas para URLs padrão são bloqueadas usando a configuração de entrada internal-and-gclb.

Se você estiver usando o Cloud Run, poderá garantir que as solicitações enviadas a URLs padrão ou qualquer outro domínio personalizado configurado usando o Cloud Run sejam bloqueados por acesso restrito na entrada do "balanceamento de carga interno e na nuvem".

Se você estiver usando o App Engine, será possível usar controles de entrada para que seu aplicativo só receba solicitações enviadas do balanceador de carga (e da VPC, se estiver usando).

Sem as configurações de entrada adequadas, os usuários podem usar o URL padrão do aplicativo sem servidor para ignorar o balanceador de carga, as políticas de segurança do Google Cloud Armor, os certificados SSL e as chaves privadas transmitidas pelo balanceador de carga.

Opcional: configure uma política de segurança de back-end padrão. A política de segurança padrão limita o tráfego acima de um limite configurado pelo usuário. Para mais informações sobre as políticas de segurança padrão, consulte a Visão geral de limitação de taxa.

  1. Para desativar a política de segurança padrão do Google Cloud Armor, selecione None no menu da lista de políticas de segurança do back-end.
  2. Na seção Segurança, selecione Política de segurança padrão.
  3. No campo Nome da política, aceite o nome gerado automaticamente ou insira um nome para a política de segurança.
  4. No campo Contagem de solicitações, aceite a contagem de solicitações padrão ou insira um número inteiro entre 1 e 10,000.
  5. No campo Intervalo, selecione um intervalo.
  6. No campo Aplicar na chave, escolha um dos seguintes valores: Todos, Endereço IP ou Endereço IP X-Forwarded-For. Para mais informações sobre essas opções, consulte Identificar clientes para a limitação de taxa.

Ativar a geração de registros e o monitoramento

É possível ativar, desativar e ver registros para um serviço de back-end do balanceador de carga de aplicativo externo. Ao usar o Console do Google Cloud, a geração de registros é ativada por padrão para serviços de back-end com back-ends NEG sem servidor. Use gcloud para desativar a geração de registros para cada serviço de back-end conforme necessário. Para mais instruções, consulte Logging.

O balanceador de carga também exporta dados de monitoramento para o Cloud Monitoring. As métricas de monitoramento podem ser usadas para avaliar a configuração, o uso e o desempenho de um balanceador de carga. As métricas também podem ser usadas para resolver problemas e melhorar a utilização dos recursos e a experiência do usuário. Para mais instruções, consulte Monitoring.

Atualizar tempo limite do sinal de atividade HTTP do cliente

O balanceador de carga criado nas etapas anteriores foi configurado com um valor padrão para o tempo limite do sinal de atividade HTTP do cliente.

Para atualizar o tempo limite do sinal de atividade HTTP do cliente, use as instruções a seguir.

Console

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique no nome do balanceador de carga que você quer modificar.
  3. Clique em Editar.
  4. Clique em Configuração de front-end.
  5. Expanda Recursos avançados. Em Tempo limite de sinal de atividade HTTP, insira um valor de tempo limite.
  6. Clique em Atualizar.
  7. Para revisar as alterações, clique em Analisar e finalizar e depois em Atualizar.

gcloud

Para um balanceador de carga HTTP, atualize o proxy HTTP de destino usando o comando gcloud compute target-http-proxies update:

    gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global

Para um balanceador de carga HTTPS, atualize o proxy HTTPS de destino usando o comando gcloud compute target-https-proxies update:

    gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global

Substitua:

  • TARGET_HTTP_PROXY_NAME: o nome do proxy HTTP de destino.
  • TARGET_HTTPS_PROXY_NAME: o nome do proxy HTTPS de destino.
  • HTTP_KEEP_ALIVE_TIMEOUT_SEC: o valor do tempo limite do sinal de atividade HTTP de 5 a 600 segundos.

Ativar detecção de outliers

É possível ativar a detecção de outliers em serviços de back-end globais para identificar NEGs sem servidor não íntegros e reduzir o número de solicitações enviadas aos NEGs sem servidor não íntegros.

A detecção de outliers é ativada no serviço de back-end usando um dos seguintes métodos:

  • O método consecutiveErrors (outlierDetection.consecutiveErrors), em que um código de status HTTP da série 5xx se qualifica como erro.
  • O método consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), em que apenas os códigos de status HTTP 502, 503 e 504 se qualificam como erros.

Use as etapas a seguir para ativar a detecção de outliers para um serviço de back-end existente. Observe que, mesmo depois de ativar a detecção de outliers, algumas solicitações podem ser enviadas para o serviço não íntegro e retornar um código de status 5xx aos clientes. Para reduzir ainda mais a taxa de erro, configure valores mais agressivos nos parâmetros de detecção de outliers. Para mais informações, consulte o campo outlierDetection.

Console

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique no nome do balanceador de carga em que está o serviço de back-end a ser editado.

  3. Na página Detalhes do balanceador de carga, clique em Editar.

  4. Na página Editar balanceador de carga externo do aplicativo, clique em Configuração de back-end.

  5. Na página Configuração de back-end, clique em Editar no serviço de back-end que você quer modificar.

  6. Role para baixo e expanda a seção Advanced Configurations.

  7. Na seção Detecção de outliers, marque a caixa de seleção Ativar.

  8. Clique em Editar para configurar a detecção de outliers.

    Verifique se as seguintes opções estão configuradas com estes valores:

    Propriedade Valor
    Erros consecutivos 5
    Interval 1000
    Tempo base de expulsão 30000
    Percentual máximo de expulsão 50
    Como aplicar erros consecutivos 100

    Neste exemplo, a análise de detecção de outliers é executada a cada segundo. Se o número de código de status HTTP 5xx consecutivos recebidos por um proxy Envoy for cinco ou mais, o endpoint de back-end será removido do pool de balanceamento de carga desse proxy Envoy por 30 segundos. Quando a porcentagem de aplicação é definida em 100%, o serviço de back-end aplica a remoção de endpoints não íntegros dos pools de balanceamento de carga desses proxies Envoy específicos sempre que a análise de detecção de outliers é executada. Se as condições de remoção forem atendidas, até 50% dos endpoints de back-end do pool de balanceamento de carga poderão ser removidos.

  9. Clique em Salvar.

  10. Para atualizar o serviço de back-end, clique em Atualizar.

  11. Para atualizar o balanceador de carga, na página Editar balanceador de carga de aplicativo externo global, clique em Atualizar.

gcloud

  1. Exporte o serviço de back-end para um arquivo YAML.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME.yaml --global

    Substitua BACKEND_SERVICE_NAME pelo nome do serviço de back-end.

  2. Edite a configuração YAML do serviço de back-end para adicionar os campos de detecção de outliers conforme destacado na seguinte configuração YAML, na seção outlierDetection:

    Neste exemplo, a análise de detecção de outliers é executada a cada segundo. Se o número de código de status HTTP 5xx consecutivos recebidos por um proxy Envoy for cinco ou mais, o endpoint de back-end será removido do pool de balanceamento de carga desse proxy Envoy por 30 segundos. Quando a porcentagem de aplicação é definida em 100%, o serviço de back-end aplica a remoção de endpoints não íntegros dos pools de balanceamento de carga desses proxies Envoy específicos sempre que a análise de detecção de outliers é executada. Se as condições de remoção forem atendidas, até 50% dos endpoints de back-end do pool de balanceamento de carga poderão ser removidos. 

    name: BACKEND_SERVICE_NAME
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
outlierDetection:
  baseEjectionTime:
    nanos: 0
    seconds: 30
  consecutiveErrors: 5
  enforcingConsecutiveErrors: 100
  interval:
    nanos: 0
    seconds: 1
  maxEjectionPercent: 50
port: 80
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
sessionAffinity: NONE
timeoutSec: 30
...

    Substitua:

    • BACKEND_SERVICE_NAME: o nome do serviço de back-end
    • PROJECT_ID: ID do projeto
    • REGION_A e REGION_B: as regiões em que o balanceador de carga foi configurado.
    • SERVERLESS_NEG_NAME: o nome do primeiro NEG sem servidor
    • SERVERLESS_NEG_NAME_2: o nome do segundo NEG sem servidor

  3. Atualize o serviço de back-end importando a configuração mais recente.

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
  --source=BACKEND_SERVICE_NAME.yaml --global

    A detecção de outliers agora está ativada no serviço de back-end.

Excluir um NEG sem servidor

Um grupo de endpoints de rede não pode ser excluído se estiver conectado a um serviço de back-end. Antes de excluir um NEG, verifique se ele está separado do serviço de back-end.

Console

  1. Para garantir que o NEG sem servidor que você quer excluir não esteja sendo usado por nenhum serviço de back-end, acesse a guia Serviços de back-end no Menu avançado do balanceamento de carga.
    Acessar a guia "Serviços de back-end"
  2. Se o NEG sem servidor estiver em uso no momento:
    1. Clique no nome do serviço de back-end que está usando o NEG sem servidor.
    2. Clique em Editar .
    3. Na lista de Back-ends, clique em para remover o back-end NEG sem servidor do serviço de back-end.
    4. Clique em Salvar.
  3. Acesse a página Grupo de endpoints da rede no Console do Google Cloud.
    Acessar a página "Grupos de endpoints de rede"
  4. Marque a caixa de seleção do NEG sem servidor que você quer excluir.
  5. Clique em Excluir.
  6. Clique em Excluir novamente para confirmar.

gcloud

Para remover um NEG sem servidor de um serviço de back-end, especifique a região em que o NEG foi criado. Você também precisa especificar a sinalização --global porque helloworld-backend-service é um recurso global.

gcloud compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

Para excluir o NEG sem servidor:

gcloud compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1

A seguir