Configure um balanceador de carga de aplicações clássico com o Cloud Run, o App Engine ou as funções do Cloud Run

Esta página mostra como criar um Application Load Balancer externo para encaminhar pedidos 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 equilibradores de carga de aplicações externos com o API Gateway permite que os seus backends sem servidor tirem partido de todas as funcionalidades fornecidas pelo Cloud Load Balancing. Para configurar um balanceador de carga de aplicações externo para encaminhar tráfego para um API Gateway, consulte o artigo Introdução a um balanceador de carga de aplicações externo para o API Gateway. O suporte do balanceador de carga de aplicações externo para o gateway da API está em pré-visualização.

Os NEGs sem servidor permitem-lhe usar Google Cloud apps sem servidor com equilibradores de carga de aplicações externos. Depois de configurar um balanceador de carga com o back-end do NEG sem servidor, os pedidos ao balanceador de carga são encaminhados para o back-end da app sem servidor.

Para saber mais sobre os NEGs sem servidor, leia a vista geral dos NEGs sem servidor.

Antes de começar

  1. Implemente um App Engine, funções do Cloud Run ou um serviço do Cloud Run.
  2. Se ainda não o fez, instale a CLI Google Cloud.
  3. Configurar autorizações.
  4. Adicione um recurso de certificado SSL.

Implemente um serviço do App Engine, do Cloud Run ou funções do Cloud Run

As instruções nesta página pressupõem que já tem um serviço do Cloud Run, das funções do Cloud Run ou do App Engine em execução.

Para o exemplo nesta página, usámos o início rápido do Python do Cloud Run para implementar um serviço do Cloud Run na região us-central1. O resto desta página mostra-lhe como configurar um Application Load Balancer externo que usa um back-end de NEG sem servidor para encaminhar pedidos para este serviço.

Se ainda não implementou uma app sem servidor ou se quiser experimentar um NEG sem servidor com uma app de exemplo, use um dos seguintes inícios rápidos. Pode criar uma app sem servidor em qualquer região, mas tem de usar a mesma região mais tarde para criar o NEG sem servidor e o equilibrador de carga.

Cloud Run

Para criar uma aplicação simples Hello World, agrupe-a numa imagem de contentor e, em seguida, implemente a imagem de contentor no Cloud Run. Consulte o Início rápido: crie e implemente.

Se já tiver um contentor de exemplo carregado para o registo de contentores, consulte o Início rápido: implemente um contentor de exemplo pré-criado.

Funções do Cloud Run

Consulte o Início rápido do Python: funções do Cloud Run.

App Engine

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

Instale a CLI Google Cloud

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

Se não tiver executado a CLI gcloud anteriormente, execute primeiro gcloud init para inicializar o diretório gcloud.

Configure autorizações

Para seguir este guia, tem de criar um NEG sem servidor e um balanceador de carga HTTP(S) externo num projeto. Deve ser proprietário ou editor do projeto, ou ter as seguintes funções IAM do Compute Engine:

Tarefa Função necessária
Crie um balanceador de carga e componentes de rede Administrador da rede
Crie e modifique NEGs Administrador de instâncias do Compute
Crie e modifique certificados SSL Administrador de segurança

Reserve um endereço IP externo

Agora que os seus serviços estão em funcionamento, configure um endereço IP externo estático global que os seus clientes usam para aceder ao balanceador de carga.

Consola

  1. Na Google Cloud consola, aceda à página Endereços IP externos.

    Aceda a Endereços IP externos

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

  3. Em Nome, introduza example-ip.

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

  5. Para Versão do IP, selecione IPv4.

  6. Para Tipo, selecione Global.

  7. Clique em Reservar.

gcloud 

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

Tome nota do endereço IPv4 que foi reservado:

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

Substitua EXAMPLE_IP pelo nome do endereço IP.

Crie um recurso de certificado SSL

Para criar um balanceador de carga HTTPS, tem de adicionar um recurso de certificado SSL ao front-end do balanceador de carga. Crie um recurso de certificado SSL usando um certificado SSL gerido pela Google ou um certificado SSL autogerido.

  • Certificados geridos pela Google. Recomendamos a utilização de certificados geridos pela Google porque Google Cloud obtém, gere e renova estes certificados automaticamente. Para criar um certificado gerido pela Google, tem de ter um domínio e os registos de DNS desse domínio para que o certificado seja aprovisionado.

    Além disso, tem de atualizar o registo A de DNS do domínio para apontar para o endereço IP do balanceador de carga criado no passo anterior. Se tiver vários domínios num certificado gerido pela Google, tem de atualizar os registos de DNS de todos os domínios e subdomínios para apontarem para o endereço IP do seu equilibrador de carga. Para instruções detalhadas, consulte o artigo Usar certificados geridos pela Google.

  • Certificados autoassinados. Se não quiser configurar um domínio neste momento, pode usar um certificado SSL autoassinado para testes.

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

Se quiser testar este processo sem criar um recurso de certificado SSL (ou um domínio, conforme exigido pelos certificados geridos pela Google), pode continuar a usar as instruções nesta página para configurar um balanceador de carga HTTP.

Crie o balanceador de carga

No diagrama seguinte, o balanceador de carga usa um back-end do NEG sem servidor para direcionar pedidos para um serviço do Cloud Run sem servidor. Para este exemplo, usámos o início rápido do Python do Cloud Run para implementar um serviço do Cloud Run.

Arquitetura do balanceador de carga de aplicações externo para uma aplicação do Cloud Run.
Arquitetura do balanceador de carga de aplicações externas para uma aplicação do Cloud Run (clique para aumentar).

Uma vez que as verificações de estado não são suportadas para serviços de back-end com back-ends NEG sem servidor, não precisa de criar uma regra de firewall que permita verificações de estado se o equilibrador de carga tiver apenas back-ends NEG sem servidor.

Consola

Selecione o tipo de balanceador de carga

  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

    Aceda a Balanceamento de carga

  2. Clique em Criar equilibrador de carga.
  3. Em Tipo de balanceador de carga, selecione Balanceador de carga de aplicações (HTTP/HTTPS) e clique em Seguinte.
  4. Para Público ou interno, selecione Público (externo) e clique em Seguinte.
  5. Para a Implementação global ou de região única, selecione Melhor para cargas de trabalho globais e clique em Seguinte.
  6. Para Geração do balanceador de carga, selecione Classic Application Load Balancer e clique em Seguinte.
  7. Clique em Configurar.

Configuração básica

  1. Para o nome do balanceador de carga, introduza serverless-lb.
  2. Mantenha a janela aberta para continuar.

Configuração da interface

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

    Recomendamos que use um certificado gerido pela Google, conforme descrito anteriormente.

    4. Para configurar um Application Load Balancer externo, preencha os campos da seguinte forma.

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

    Propriedade Valor (introduza um valor ou selecione uma opção conforme especificado)
    Protocolo HTTPS
    Nível de serviço de rede Premium
    Versão do IP IPv4
    Endereço IP example-ip
    Porta 443
    Certificado Selecione um certificado SSL existente ou crie um novo certificado.

    Para criar um balanceador de carga HTTPS, tem de ter um recurso de certificado SSL para usar no proxy HTTPS. Pode criar um recurso de certificado SSL através de um certificado SSL gerido pela Google ou um certificado SSL autogerido.
    Para criar um certificado gerido pela Google, tem de ter um domínio. O registo A do domínio tem de resolver para o endereço IP do equilibrador de carga que criou anteriormente neste procedimento. Recomendamos a utilização de certificados geridos pela Google porque Google Cloud obtém, gere e renova estes certificados automaticamente. Se não tiver um domínio, pode usar um certificado SSL autoassinado para testes.
    Opcional: ative o redirecionamento de HTTP para HTTPS Use esta caixa de verificação para ativar os redirecionamentos de HTTP para HTTPS.

    Selecione esta caixa de verificação para criar um balanceador de carga HTTP parcial adicional que usa o mesmo endereço IP que o seu balanceador de carga HTTPS e redireciona os pedidos HTTP para o frontend HTTPS do seu balanceador de carga.

    Esta caixa de verificação só pode ser selecionada quando o protocolo HTTPS estiver selecionado e for usado um endereço IP reservado.

    Se quiser testar este processo sem configurar um recurso de certificado SSL (ou um domínio, conforme exigido pelos certificados geridos pela Google), pode configurar 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 (introduza um valor ou selecione uma opção conforme especificado)
    Protocolo HTTP
    Nível de serviço de rede Premium
    Versão do IP IPv4
    Endereço IP example-ip
    Porta 80
  4. Clique em Concluído.

Configuração do back-end

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

Regras de encaminhamento

As regras de encaminhamento determinam como o seu tráfego é direcionado. Para configurar o encaminhamento, configura regras de anfitrião e correspondências de caminhos, que são componentes de configuração de um balanceador de carga de aplicações externo do mapa de URLs.

  1. Clique em Regras de anfitrião e caminho.

  2. Manter os anfitriões e os caminhos predefinidos. Para este exemplo, todos os pedidos são enviados para o serviço de back-end criado no passo anterior.

Rever a configuração

  1. Clique em Rever e finalizar.
  2. Reveja todas as definições.
  3. Opcional: clique em Código equivalente para ver o pedido da API REST que vai ser usado para criar o balanceador de carga.
  4. Clique em Criar.
  5. Aguarde a criação do balanceador de carga.
  6. Clique no nome do balanceador de carga (serverless-lb).
  7. Tome nota do endereço IP do equilibrador de carga para a tarefa seguinte. É conhecido como IP_ADDRESS.

gcloud

  1. Crie um NEG sem servidor para a sua 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 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 \
       --global
  3. Adicione o 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 \
       --network-endpoint-group-region=us-central1
  4. Crie um mapa de URLs para encaminhar pedidos recebidos para o serviço de back-end: 
       gcloud compute url-maps create URL_MAP_NAME \
       --default-service BACKEND_SERVICE_NAME

    Este mapa de URLs de exemplo segmenta apenas um serviço de back-end que representa uma app sem servidor única, pelo que não precisamos de configurar regras de anfitrião nem correspondências de caminhos. Se tiver mais do que um serviço de back-end, pode usar regras de anfitrião para direcionar pedidos para diferentes serviços com base no nome do anfitrião e pode configurar correspondências de caminhos para direcionar pedidos para diferentes serviços com base no caminho do pedido.

  5. Para criar um balanceador de carga HTTPS, tem de ter um recurso de certificado SSL para usar no proxy HTTPS de destino. Pode criar um recurso de certificado SSL usando um certificado SSL gerido pela Google ou um certificado SSL autogerido. Recomendamos a utilização de certificados geridos pela Google, uma vez que Google Cloud obtêm, gerem e renovam estes certificados automaticamente.

    Para criar um certificado gerido pela Google, tem de ter um domínio. Se não tiver um domínio, pode usar um certificado SSL autoassinado para testes.

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

  6. Crie um proxy HTTP(S) de destino para encaminhar pedidos para o seu mapa de URLs.

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

       gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
       --url-map=URL_MAP_NAME

    Para um balanceador de carga HTTPS, crie um proxy HTTPS de destino. O proxy é a parte do balanceador de carga que contém o certificado SSL para o balanceamento de carga HTTPS, pelo que também carrega o certificado neste passo.

       gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
      --ssl-certificates=SSL_CERTIFICATE_NAME \
      --url-map=URL_MAP_NAME
  7. Crie uma regra de encaminhamento para encaminhar pedidos recebidos para o proxy.

    Para um balanceador de carga HTTP:

       gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \
       --load-balancing-scheme=EXTERNAL \
       --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 \
       --network-tier=PREMIUM \
       --address=EXAMPLE_IP \
       --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
       --global \
       --ports=443

Associe o seu domínio ao balanceador de carga

Após a criação do balanceador de carga, tome nota do endereço IP associado ao balanceador de carga, por exemplo, 30.90.80.100. Para direcionar o seu domínio para o equilibrador de carga, crie um registo A através do serviço de registo de domínios. Se adicionou vários domínios ao seu certificado SSL, tem de adicionar um registo A para cada um, todos a apontar para o endereço IP do equilibrador de carga. Por exemplo, para criar registos 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 usar o Cloud DNS como fornecedor de DNS, consulte o artigo Adicione, modifique e elimine registos.

Teste o balanceador de carga

Agora que configurou o equilibrador de carga, pode começar a enviar tráfego para o endereço IP do equilibrador de carga. Se configurou um domínio, também pode enviar tráfego para o nome de domínio. No entanto, a propagação de DNS pode demorar algum tempo a ser concluída, pelo que pode começar por usar o endereço IP para testes.

  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

    Aceda a Balanceamento de carga

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

  3. Tome nota do endereço IP do balanceador de carga.

  4. Para um balanceador de carga de HTTP, pode testar o balanceador de carga através de um navegador de Internet acedendo a http://IP_ADDRESS. Substitua IP_ADDRESS pelo endereço IP do balanceador de carga. É apresentada a página inicial do serviço helloworld.

  5. Para um balanceador de carga HTTPS, pode testar o balanceador de carga através de um navegador de Internet acedendo a https://IP_ADDRESS. Substitua IP_ADDRESS pelo endereço IP do balanceador de carga. É apresentada a página inicial do serviço helloworld.
    Se isso não funcionar e estiver a usar um certificado gerido pela Google, confirme que o estado do recurso do certificado é ACTIVE. Para mais informações, consulte o estado do recurso do certificado SSL gerido pela Google.
    Se usou um certificado autoassinado para testes, o navegador apresenta um aviso. Tem de instruir explicitamente o navegador para aceitar um certificado autossinado. Clique no aviso para ver a página real.

Opções de configuração adicionais

Esta secção expande o exemplo de configuração para oferecer opções de configuração alternativas e adicionais. Todas as tarefas são opcionais. Pode realizá-las por qualquer ordem.

Configure o balanceamento de carga em várias regiões

No exemplo descrito anteriormente nesta página, temos apenas um serviço do Cloud Run que funciona como back-end na região us-central1. Uma vez que o NEG sem servidor só pode apontar para um endpoint de cada vez, o equilíbrio de carga não é realizado em várias regiões. O Application Load Balancer externo funciona apenas como front-end e encaminha o tráfego para o ponto final da app helloworld especificado. No entanto, pode querer publicar a sua app do Cloud Run a partir de mais do que uma região para melhorar a latência do utilizador final.

Se um serviço de back-end tiver vários NEGs sem servidor associados, o equilibrador de carga equilibra o tráfego encaminhando pedidos 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 seu serviço do Cloud Run a partir de várias regiões, tem de configurar o encaminhamento entre regiões. Deve poder usar um único esquema de URL que funcione em qualquer parte do mundo, mas que responda a pedidos de utilizadores da região mais próxima do utilizador.

Para configurar o fornecimento em várias regiões, tem de usar o nível de rede Premium para garantir que todas as implementações regionais do Cloud Run são compatíveis e estão prontas para fornecer tráfego a partir de qualquer região.

Para configurar um equilibrador de carga multirregional:

  1. Configure dois serviços do Cloud Run em regiões diferentes. Vamos supor que implementou dois serviços do Cloud Run: um numa região nos EUA e outro numa região na Europa.
  2. Crie um Application Load Balancer 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 que o serviço do Cloud Run implementado nos EUA.
      2. Crie o segundo NEG na mesma região que o serviço do Cloud Run implementado na Europa.
    2. Configure a configuração do frontend com o nível de serviço de rede Premium.

A configuração resultante é apresentada no diagrama seguinte.

Encaminhamento multirregional para aplicações sem servidor.
Encaminhamento multirregião para aplicações sem servidor

Esta secção baseia-se na configuração do equilibrador de carga descrita anteriormente nesta página, na qual criou um NEG sem servidor na região us-central1 que aponta para um serviço do Cloud Run na mesma região. Também pressupõe que criou um segundo serviço do Cloud Run na região europe-west1. O segundo NEG sem servidor que criar vai apontar para este serviço do Cloud Run na região europe-west1.

Neste exemplo, conclui os seguintes passos:

  1. Crie um segundo NEG sem servidor na região europe-west1.
  2. Associe 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 existente, siga estes passos.

Consola

  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

    Aceda a Balanceamento de carga

  2. Clique no nome do balanceador de carga cujo serviço de back-end quer editar.

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

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

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

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

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

  8. Introduza um nome para o NEG sem servidor.

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

  10. Para o Tipo de grupo de pontos finais da rede sem servidor, selecione Cloud Run e, em seguida, 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 quer criar um equilibrador de carga.

  11. Clique em Criar.

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

  13. Clique em Guardar.

  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 aplicações 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á implementado.

    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 o seguinte:

    • 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 o seguinte:

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

Use uma subscrição push do Pub/Sub autenticada com uma implementação do Cloud Run em várias regiões

Para pedidos push autenticados, o Cloud Run espera um campo de público-alvo específico da região por predefinição. No caso de uma implementação do Cloud Run em várias regiões, se o pedido push for encaminhado para um serviço do Cloud Run numa região diferente, a validação do token JWT falha devido a uma incompatibilidade de público-alvo.

Para contornar esta restrição específica da região:

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

Configure o encaminhamento regional

Um motivo comum para publicar aplicações a partir de várias regiões é cumprir os requisitos de localidade dos dados. Por exemplo, pode querer garantir que os pedidos feitos por utilizadores europeus são sempre publicados a partir de uma região localizada na Europa. Para configurar esta opção, precisa de um esquema de URL com URLs separados para utilizadores da UE e de fora da UE, e direcionar os utilizadores da UE para os URLs da UE.

Neste cenário, usaria o mapa de URLs para encaminhar pedidos de URLs específicos para as respetivas regiões correspondentes. Com esta configuração, os pedidos destinados a uma região nunca são enviados para uma região diferente. Isto oferece isolamento entre regiões. Por outro lado, quando uma região falha, os pedidos não são encaminhados para uma região diferente. Assim, esta configuração não aumenta a disponibilidade do seu serviço.

Para configurar o encaminhamento regional, tem de usar o nível de rede Premium para poder combinar diferentes regiões numa única regra de encaminhamento.

Para configurar um balanceador de carga com encaminhamento regional:

  1. Configure dois serviços do Cloud Run em regiões diferentes. Suponhamos que implementou dois serviços do Cloud Run: hello-world-eu numa região da Europa e hello-world-us numa região dos EUA.
  2. Crie um Application Load Balancer 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 tem de ser criado na mesma região que o serviço do Cloud Run implementado na Europa.
    2. Configure um segundo serviço de back-end com outro NEG sem servidor nos EUA. Este NEG sem servidor tem de ser criado na mesma região que o serviço do Cloud Run implementado nos EUA.
    3. Configure o seu mapa de URLs com as regras de anfitrião e caminho adequadas para que um conjunto de URLs seja encaminhado para o serviço de back-end europeu, enquanto todos os pedidos são encaminhados para o serviço de back-end dos EUA.
    4. Configure a sua configuração de front-end com o nível de rede Premium.

O resto da configuração pode ser igual ao descrito anteriormente. A configuração resultante deve ter o seguinte aspeto:

Encaminhamento regional para aplicações sem servidor sem comutação por falha.
Encaminhamento regional para aplicações sem servidor sem comutação por falha

Use uma máscara de URL

Quando cria um NEG sem servidor, em vez de selecionar um serviço do Cloud Run específico, pode usar uma máscara de URL para apontar para vários serviços publicados no mesmo domínio. Uma máscara de URL é um modelo do seu esquema de URL. O NEG sem servidor usa este modelo para extrair o nome do serviço do URL do pedido recebido e mapear o pedido para o serviço adequado.

As máscaras de URL são particularmente úteis se o seu serviço estiver mapeado para um domínio personalizado em vez do endereço predefinido que aGoogle Cloud fornece para o serviço implementado. Uma máscara de URL permite-lhe segmentar vários serviços e versões com uma única regra, mesmo quando a sua aplicação está a usar um padrão de URL personalizado.

Se ainda não o fez, certifique-se de que lê o artigo Vista geral dos NEGs sem servidor: máscaras de URL.

Construa uma máscara de URL

Para criar uma máscara de URL para o seu equilibrador de carga, comece com o URL do seu serviço. Para este exemplo, vamos usar uma app sem servidor de exemplo em execução em https://example.com/login. Este é o URL onde o serviço loginda app vai ser publicado.

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

  3. (Opcional) Se o nome do serviço (ou a função, a versão ou a etiqueta) puder ser extraído da parte do caminho do URL, o domínio pode ser omitido. A parte do caminho da máscara de URL distingue-se pelo primeiro caráter /. Se não estiver presente um / na máscara do URL, entende-se que a máscara representa apenas o anfitrião. Por conseguinte, para este exemplo, a máscara do 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 anfitrião do URL, pode omitir completamente o caminho da máscara de URL.

    Também pode omitir quaisquer componentes de anfitrião ou subdomínio que venham antes do primeiro marcador de posição, bem como quaisquer componentes de caminho que venham depois do último marcador de posição. Nestes casos, o marcador de posição captura as informações necessárias para o componente.

Seguem-se mais alguns exemplos que demonstram estas regras:

Cloud Run

Esta tabela pressupõe que tem um domínio personalizado denominado example.com e que todos os seus serviços do Cloud Run estão a ser mapeados para este domínio através de um Application Load Balancer externo.

Serviço, nome da etiqueta URL de domínio personalizado Máscara de URL
service: login https://login-home.example.com/web <service>-home.example.com
service: 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

Esta tabela pressupõe que tem um domínio personalizado denominado example.com e que todos os seus serviços de funções do Cloud Run estão a ser mapeados para este 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

Esta tabela pressupõe que tem um domínio personalizado denominado example.com e que todos os seus serviços do App Engine estão a ser mapeados para este domínio.

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

API Gateway

Esta tabela pressupõe que tem um domínio personalizado denominado example.com e que todos os seus serviços do API Gateway estão a ser mapeados para este domínio.

Nome do gateway URL de domínio personalizado do API Gateway(pré-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

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

Consola

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

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

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

  1. Aceda à página Balanceamento de carga na Google Cloud consola.
    Aceda à página Balanceamento de carga
  2. Clique no nome do balanceador de carga cujo serviço de back-end quer editar.
  3. Na página Detalhes do equilibrador de carga, clique em Editar .
  4. Na página Editar balanceador de carga de aplicações externo global, clique em Configuração do back-end.
  5. Na página Configuração de back-end, clique em Editar para o serviço de back-end que quer modificar.
  6. Clique em Adicionar back-end.
  7. Selecione Criar grupo de pontos finais de rede sem servidor.
    1. No campo Nome, introduza helloworld-serverless-neg.
    2. Em Região, selecione us-central1.
    3. Em Tipo de grupo de pontos finais da rede sem servidor, selecione a plataforma onde as suas apps (ou serviços ou funções) sem servidor foram criadas.
      1. Selecione Usar máscara de URL.
      2. Introduza uma máscara de URL. Para ver instruções sobre como criar uma máscara de URL, consulte o artigo Construir uma máscara de URL.
      3. Clique em Criar.
  8. Na secçã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 exemplo 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 exemplo 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 exemplo 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: API Gateway

Para criar um NEG sem servidor com uma máscara de URL de exemplo 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 equilibrador de carga processa problemas com incompatibilidades de máscaras de URL, consulte a secção Resolução de problemas com NEGs sem servidor.

Mova o seu domínio personalizado para ser publicado pelo Application Load Balancer externo

Se as suas apps de computação sem servidor estiverem mapeadas para domínios personalizados, é recomendável que atualize os seus registos de DNS para que o tráfego enviado para os URLs de domínios personalizados do Cloud Run, das funções do Cloud Run, do API Gateway ou do App Engine existentes seja encaminhado através do balanceador de carga.

Por exemplo, se tiver um domínio personalizado denominado example.com e todos os seus serviços do Cloud Run estiverem mapeados para este domínio, deve atualizar o registo DNS de example.com para apontar para o endereço IP do balanceador de carga.

Antes de atualizar os registos de DNS, pode testar 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 ficheiro /etc/hosts/ no seu computador local para apontar example.com para o endereço IP do equilibrador de carga ou use a flag curl --resolve para forçar curl a usar o endereço IP do equilibrador de carga para o pedido.

Quando o registo DNS para example.com é resolvido para o endereço IP do balanceador de carga HTTP(S), os pedidos enviados para example.com começam a ser encaminhados através do balanceador de carga. O balanceador de carga envia-os para o serviço de back-end relevante de acordo com o respetivo mapa de URLs. Além disso, se o serviço de back-end estiver configurado com uma máscara de URL, o NEG sem servidor usa a máscara para encaminhar o pedido para o serviço do Cloud Run, das funções do Cloud Run, do API Gateway ou do App Engine adequado.

Ative o Cloud CDN

A ativação do Cloud CDN para o seu serviço do Cloud Run permite-lhe otimizar a entrega de conteúdo colocando conteúdo em cache perto dos seus utilizadores.

Pode ativar o Cloud CDN em serviços de back-end usados por balanceadores de carga de aplicações externos globais usando o comando gcloud compute backend-services update.

gcloud compute backend-services update helloworld-backend-service 

    --enable-cdn 

    --global

O CDN na nuvem é suportado para serviços de back-end com o Cloud Run, as funções do Cloud Run, o API Gateway e os back-ends do App Engine.

Ative a IAP no Application Load Balancer externo

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

Pode configurar as CAs para estarem ativadas ou desativadas (predefinição). Se a opção estiver ativada, tem de fornecer valores para oauth2-client-id e oauth2-client-secret.

Para ativar as CAs, atualize o serviço de back-end para incluir a flag --iap=enabled com 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

Opcionalmente, pode ativar a IAP para um recurso do Compute Engine através da Google Cloud consola, da CLI gcloud ou da API.

Ative o Google Cloud Armor

O Cloud Armor é um produto de segurança que oferece proteção contra ataques de negação de serviço distribuída (DDoS) a todos os balanceadores de carga de proxy do GCLB. O Cloud Armor também fornece políticas de segurança configuráveis para serviços acedidos através de um Application Load Balancer externo. Para saber mais sobre as políticas de segurança do Cloud Armor para equilibradores de carga de aplicações externos, consulte o artigo Vista geral da política de segurança do Cloud Armor.

Se estiver a usar funções do Cloud Run, pode garantir que os pedidos enviados para URLs predefinidos são bloqueados através da internal-and-gclbdefinição de entrada.

Se estiver a usar o Cloud Run, pode garantir que os pedidos enviados para URLs predefinidos ou qualquer outro domínio personalizado configurado através do Cloud Run são bloqueados restringindo a entrada a "equilíbrio de carga interno e na nuvem".

Se estiver a usar o App Engine, pode usar os controlos de entrada para que a sua app só receba pedidos enviados a partir do equilibrador de carga (e da VPC, se a usar).

Sem as definições de entrada adequadas, os utilizadores podem usar o URL predefinido da sua aplicação sem servidor para contornar o balanceador de carga, as políticas de segurança do Cloud Armor, os certificados SSL e as chaves privadas que são transmitidas através do balanceador de carga.

Opcional: configure uma política de segurança do back-end predefinida. A política de segurança predefinida limita o tráfego acima de um limite configurado pelo utilizador. Para mais informações sobre as políticas de segurança predefinidas, consulte a vista geral da limitação de taxa.

  1. Para desativar a política de segurança predefinida do Cloud Armor, selecione None na lista Política de segurança de back-end do Cloud Armor.
  2. Para configurar a política de segurança predefinida do Cloud Armor, selecione Política de segurança predefinida na lista Política de segurança de back-end do Cloud Armor.
  3. No campo Nome da política, aceite o nome gerado automaticamente ou introduza um nome para a sua política de segurança.
  4. No campo Contagem de pedidos, aceite a contagem de pedidos predefinida ou introduza um número inteiro entre 1 e 10,000.
  5. No campo Intervalo, selecione um intervalo.
  6. No campo Aplicar à chave, escolha um dos seguintes valores: Tudo, Endereço IP ou Endereço IP X-Forwarded-For. Para mais informações acerca destas opções, consulte o artigo Identificar clientes para a limitação de taxa.

Ative o registo e a monitorização

Pode ativar, desativar e ver registos de um serviço de back-end do Application Load Balancer externo. Quando usa a consola Google Cloud , o registo está ativado por predefinição para serviços de back-end com back-ends NEG sem servidor. Pode usar gcloud para desativar o registo de cada serviço de back-end conforme necessário. Para ver instruções, consulte a secção Registo.

O balanceador de carga também exporta dados de monitorização para o Cloud Monitoring. As métricas de monitorização podem ser usadas para avaliar a configuração, a utilização e o desempenho de um equilibrador de carga. As métricas também podem ser usadas para resolver problemas e melhorar a utilização de recursos e a experiência do utilizador. Para ver instruções, consulte a secção Monitorização.

Elimine um NEG sem servidor

Não é possível eliminar um grupo de pontos finais de rede se estiver anexado a um serviço de back-end. Antes de eliminar um NEG, certifique-se de que está desvinculado do serviço de back-end.

Consola

  1. Para se certificar de que o NEG sem servidor que quer eliminar não está atualmente a ser usado por nenhum serviço de back-end, aceda ao separador Serviços de back-end no menu avançado de equilíbrio de carga.
    Aceda ao separador Serviços de back-end
  2. Se o NEG sem servidor estiver atualmente em utilização:
    1. Clique no nome do serviço de back-end que usa o NEG sem servidor.
    2. Clique em Editar .
    3. Na lista de Back-ends, clique em para remover o back-end do NEG sem servidor do serviço de back-end.
    4. Clique em Guardar.
  3. Aceda à página Grupo de pontos finais de rede na Google Cloud consola.
    Aceda à página Grupo de pontos finais da rede
  4. Selecione a caixa de verificação do NEG sem servidor que quer eliminar.
  5. Clique em Eliminar.
  6. Clique novamente em Eliminar para confirmar.

gcloud

Para remover um NEG sem servidor de um serviço de back-end, tem de especificar a região onde o NEG foi criado. Também tem de especificar a flag --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 eliminar o NEG sem servidor:

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

O que se segue?