Veicular tráfego de várias regiões

Para dar respostas mais rápidas a usuários de todo o mundo, implante serviços em várias regiões e encaminhe esses usuários para a região mais próxima. A implantação em várias regiões oferece baixa latência e maior disponibilidade em caso de interrupções regionais.

Como os serviços do Cloud Run são implantados em regiões individuais, é necessário implantar o serviço em várias regiões e configurar o balanceamento de carga global para ele.

É possível automatizar o failover entre regiões usando a integridade do serviço do Cloud Run.

Antes de começar

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. Configure o ambiente de desenvolvimento do Cloud Run no seu projeto do Google Cloud .
2. Instale e inicialize a gcloud CLI.
3. Verifique se sua conta tem os seguintes papéis do IAM:
   • Administrador do Cloud Run (roles/run.admin)
   • Administrador de projetos do IAM (roles/resourcemanager.projectIamAdmin)
   • Consumidor do Service Usage (roles/serviceusage.serviceUsageConsumer)

Conceder os papéis

Console

1. No console do Google Cloud , acesse a página IAM.

   Acessar o IAM
2. Selecione o projeto.
3. Clique em Conceder acesso.

4. No campo Novos principais, digite seu identificador de usuário. Normalmente, esse é o endereço de e-mail da Conta do Google usado para implantar o serviço do Cloud Run.

5. Na lista Selecionar papel, escolha um.
6. Para conceder outros papéis, clique em Adicionar outro papel e selecione cada papel adicional.
7. Clique em Salvar.

gcloud

Para conceder os papéis do IAM necessários à sua conta no projeto:

        gcloud projects add-iam-policy-binding PROJECT_ID \
            --member=PRINCIPAL \
            --role=ROLE
        

Substitua:

• PROJECT_NUMBER pelo número do projeto do Google Cloud .
• PROJECT_ID com seu Google Cloud ID do projeto.
• PRINCIPAL com a conta a que você está adicionando a vinculação. Normalmente, é o endereço de e-mail da Conta do Google usado para implantar o serviço do Cloud Run.
• ROLE com o papel que você está adicionando à conta do implantador.
4. Consulte a página de preços do Cloud Run. Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.
5. Ative as APIs Artifact Registry, Cloud Build, Cloud Run Admin, Compute Engine e Network Services executando o seguinte comando:

  gcloud services enable artifactregistry.googleapis.com \
    cloudbuild.googleapis.com \
    run.googleapis.com \
    compute.googleapis.com \
    networkservices.googleapis.com
  

Implantar o serviço em várias regiões

Os parâmetros de escalonamento que você configura são aplicados em várias regiões. Em uma implantação multirregional, por exemplo, o valor mínimo de instâncias se aplica a cada uma das várias regiões.

Implante o mesmo serviço em várias regiões usando um dos seguintes métodos:

• Repita as etapas para fazer a implantação em uma única região.
• Implante um serviço multirregional.

Implantar um serviço multirregional

Esta seção mostra como implantar e configurar um serviço multirregional usando um único comando da CLI gcloud ou um arquivo YAML ou Terraform.

gcloud

• Para criar e implantar um serviço multirregional, execute o comando gcloud run deploy usando a flag --regions:

  gcloud run deploy SERVICE_NAME \
    --image=IMAGE_URL \
    --regions=REGIONS

  Substitua:

  • SERVICE_NAME: o nome do serviço multirregional que você quer implantar.
  • IMAGE_URL: uma referência à imagem de contêiner, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest.
  • REGIONS: a lista de várias regiões para fazer a implantação. Por exemplo, europe-west1,asia-east1.

YAML

1. Crie o arquivo YAML para seu serviço usando o atributo run.googleapis.com/regions para definir as várias regiões em que você quer implantar o serviço:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: SERVICE_NAME
     annotations:
       run.googleapis.com/regions: REGIONS
   spec:
     template:
       spec:
         containers:
         - image: IMAGE_URL

   Substitua:

   • SERVICE_NAME: o nome do serviço multirregional que você quer implantar.
   • REGIONS: a lista de várias regiões que você quer atualizar. Por exemplo, europe-west1,asia-east1.
   • IMAGE_URL: uma referência à imagem de contêiner, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest.

2. Crie o serviço usando o seguinte comando:

   gcloud run multi-region-services replace service.yaml

Terraform

Para saber como aplicar ou remover uma configuração do Terraform, consulte Comandos básicos do Terraform.

Adicione o seguinte a um recurso google_cloud_run_v2_service na configuração do Terraform.

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-multi-region"
  regions = [
    "REGION_1",
    "REGION_2",
  ]

template {
containers {
  image = "us-docker.pkg.dev/cloudrun/container/hello"
}
}
}

Substitua "REGION_1" e "REGION_2" por cada uma das regiõesGoogle Cloud necessárias. Por exemplo, europe-west1 e us-central1.

Atualizar um serviço multirregional

Observação: não é possível modificar serviços regionais individuais após a implantação. São recursos somente leitura.

Esta seção mostra como adicionar ou remover regiões de um serviço multirregional usando um único comando da CLI gcloud ou um arquivo YAML.

gcloud

Para adicionar ou remover regiões de um serviço multirregional, execute o comando gcloud run multi-region-services update.

• Para adicionar o serviço multirregional a outras regiões, use a flag --add-regions:

  gcloud run multi-region-services update SERVICE_NAME \
    --add-regions=REGIONS

• Para remover o serviço multirregional de uma ou mais regiões, use a flag --remove-regions:

  gcloud run multi-region-services update SERVICE_NAME \
    --remove-regions=REGIONS

  Substitua:

  • SERVICE_NAME: o nome do serviço multirregional que você quer atualizar.
  • REGIONS: as regiões para adicionar ou remover o serviço. Por exemplo, us-central1,asia-east1.

YAML

1. Para atualizar um serviço multirregional, baixe a configuração YAML:

   gcloud run multi-region-services describe SERVICE_NAME --format export > service.yaml

2. Atualize o atributo run.googleapis.com/regions para adicionar ou remover a lista de regiões em que você quer que o serviço seja implantado:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: SERVICE_NAME
     annotations:
       run.googleapis.com/regions: REGIONS

   Substitua:

   • SERVICE_NAME: o nome do serviço multirregional que você quer implantar.
   • REGIONS: a nova lista de várias regiões para onde você quer implantar a revisão do serviço.

3. Atualize o serviço usando o seguinte comando:

   gcloud run multi-region-services replace service.yaml

Excluir um serviço multirregional

Observação: não é possível modificar serviços regionais individuais após a implantação. São recursos somente leitura.

• Para excluir um serviço multirregional, execute o comando gcloud run multi-region-services delete:

  gcloud run multi-region-services delete SERVICE_NAME

  Substitua SERVICE_NAME pelo nome do serviço multirregional que você quer excluir.

Configurar um balanceador de carga de aplicativo externo global

Esta seção mostra como configurar um balanceador de carga de aplicativo externo global com um domínio protegido por um certificado TLS gerenciado que aponta para um endereço IP anycast global, que direciona os usuários para o data center do Google mais próximo com o serviço implantado.

A arquitetura descrita nas seções a seguir não encaminha automaticamente solicitações para uma região diferente quando um serviço regional do Cloud Run deixa de responder ou retorna erros.

Para aumentar a disponibilidade do seu serviço multirregional:

• Automatizar o failover entre regiões com a integridade do serviço do Cloud Run
• Configure a detecção de outliers para identificar serviços não íntegros do Cloud Run com base na taxa de erros HTTP e divergir algumas solicitações para outra região.

Criar um balanceador de carga de aplicativo externo global

A criação de um balanceador de carga de aplicativo externo global envolve a criação de vários recursos de rede e a conexão deles:

gcloud

1. Reserve um endereço IP estático para não precisar atualizar seus registros DNS ao recriar seu balanceador de carga.

   gcloud compute addresses create --global SERVICE_IP

   No comando acima, substitua SERVICE_IP por um nome para o recurso de endereço IP (por exemplo, myservice-ip).

   Por exemplo, é um endereço IPv4 anycast global que encaminha para o data center do Google ou para o ponto de presença mais próximo dos visitantes.

2. Crie um serviço de back-end.

   gcloud compute backend-services create \
     --global BACKEND_NAME \
     --load-balancing-scheme=EXTERNAL_MANAGED

   Substitua BACKEND_NAME pelo nome que você quer dar ao serviço de back-end. Por exemplo, myservice-backend.

3. Crie um mapa de URLs.

   gcloud compute url-maps create URLMAP_NAME --default-service=BACKEND_NAME

   Substitua URLMAP_NAME pelo nome que você quer dar ao mapa de URLs (por exemplo, myservice-urlmap).

4. Crie um certificado TLS gerenciado para seu domínio para exibir o tráfego HTTPS. (Substitua example.com pelo nome do seu domínio.)

   gcloud compute ssl-certificates create CERT_NAME \
     --domains=example.com

   Substitua CERT_NAME pelo nome que você quer dar ao certificado SSL gerenciado (por exemplo, myservice-cert).

5. Crie um proxy de destino HTTPS.

   gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
     --ssl-certificates=CERT_NAME \
     --url-map=URLMAP_NAME

   Substitua HTTPS_PROXY_NAME pelo nome que você quer fornecer ao proxy de destino HTTPS (por exemplo, myservice-https).

6. Crie uma regra de encaminhamento que conecte os recursos de rede que você criou ao endereço IP.

   gcloud compute forwarding-rules create --global FORWARDING_RULE_NAME \
     --target-https-proxy=HTTPS_PROXY_NAME \
     --address=SERVICE_IP \
     --ports=443 \
     --load-balancing-scheme=EXTERNAL_MANAGED 

   Substitua FORWARDING_RULE_NAME pelo nome do recurso de regra de encaminhamento que você quer criar. Por exemplo, myservice-lb.

Terraform

Como alternativa às etapas descritas nesta seção, é possível usar o módulo de balanceador de carga HTTP global do Terraform.

Para saber como aplicar ou remover uma configuração do Terraform, consulte Comandos básicos do Terraform.

1. Configure o endereço IP:

   resource "google_compute_global_address" "lb_default" {
     provider = google-beta
     name     = "myservice-service-ip"
   
     # Use an explicit depends_on clause to wait until API is enabled
     depends_on = [
       google_project_service.compute_api
     ]
   }
   output "load_balancer_ip_addr" {
     value = google_compute_global_address.lb_default.address
   }

   Configura o nome do recurso de endereço IP como myservice-service-ip. É possível mudar isso para seu próprio valor. Esse endereço IP é um endereço IPv4 anycast global que faz o encaminhamento para o data center do Google ou o ponto de presença mais próximo dos visitantes.

2. Crie e configure o serviço de back-end:

   resource "google_compute_backend_service" "lb_default" {
     provider              = google-beta
     name                  = "myservice-backend"
     load_balancing_scheme = "EXTERNAL_MANAGED"
   
     backend {
       group = google_compute_region_network_endpoint_group.lb_default[0].id
     }
   
     backend {
       group = google_compute_region_network_endpoint_group.lb_default[1].id
     }
   
     # Use an explicit depends_on clause to wait until API is enabled
     depends_on = [
       google_project_service.compute_api,
     ]
   }

   Este recurso configura o serviço de back-end como myservice-backend. É possível mudar isso para seu próprio valor.

3. Configure o mapa de URL:

   resource "google_compute_url_map" "lb_default" {
     provider        = google-beta
     name            = "myservice-lb-urlmap"
     default_service = google_compute_backend_service.lb_default.id
   
     path_matcher {
       name            = "allpaths"
       default_service = google_compute_backend_service.lb_default.id
       route_rules {
         priority = 1
         url_redirect {
           https_redirect         = true
           redirect_response_code = "MOVED_PERMANENTLY_DEFAULT"
         }
       }
     }
   }

   Conecta o recurso do serviço de back-end (myservice-backend) ao novo recurso de mapa de URL (myservice-lb-urlmap). É possível mudar para seus próprios valores.

4. Crie um certificado TLS gerenciado para seu domínio para disponibilizar o tráfego HTTPS. Substitua example.com pelo seu nome de domínio no recurso google_compute_managed_ssl_certificate:

   resource "google_compute_managed_ssl_certificate" "lb_default" {
     provider = google-beta
     name     = "myservice-ssl-cert"
   
     managed {
       domains = ["example.com"]
     }
   }

5. Configure o proxy HTTPS:

   resource "google_compute_target_https_proxy" "lb_default" {
     provider = google-beta
     name     = "myservice-https-proxy"
     url_map  = google_compute_url_map.lb_default.id
     ssl_certificates = [
       google_compute_managed_ssl_certificate.lb_default.name
     ]
     depends_on = [
       google_compute_managed_ssl_certificate.lb_default
     ]
   }

   Cria o recurso google_compute_target_https_proxy com o nome de destino myservice-https-proxy e conecta o certificado TLS criado anteriormente (myservice-ssl-cert) e os recursos de mapeamento de URL (myservice-lb-urlmap). É possível mudar para seus próprios valores.

6. Configure a regra de encaminhamento:

   resource "google_compute_global_forwarding_rule" "lb_default" {
     provider              = google-beta
     name                  = "myservice-lb-fr"
     load_balancing_scheme = "EXTERNAL_MANAGED"
     target                = google_compute_target_https_proxy.lb_default.id
     ip_address            = google_compute_global_address.lb_default.id
     port_range            = "443"
     depends_on            = [google_compute_target_https_proxy.lb_default]
   }

   Cria o recurso google_compute_global_forwarding_rule com o nome de destino myservice-https-proxy e conecta o destino do proxy HTTPS criado anteriormente (myservice-https-proxy) e o recurso de endereço IP (myservice-service-ip). É possível mudar para seus próprios valores.

7. Aplicar esta configuração:

   Para aplicar a configuração do Terraform em um projeto Google Cloud , siga as etapas nas seções a seguir.

   Preparar o Cloud Shell

   1. Inicie o Cloud Shell.

   2. Defina o projeto Google Cloud padrão em que você quer aplicar as configurações do Terraform.

      Você só precisa executar esse comando uma vez por projeto, e ele pode ser executado em qualquer diretório.

      export GOOGLE_CLOUD_PROJECT=PROJECT_ID

      As variáveis de ambiente serão substituídas se você definir valores explícitos no arquivo de configuração do Terraform.

   Preparar o diretório

   Cada arquivo de configuração do Terraform precisa ter o próprio diretório, também chamado de módulo raiz.

   1. No Cloud Shell, crie um diretório e um novo arquivo dentro dele. O nome do arquivo precisa ter a extensão .tf, por exemplo, main.tf. Neste tutorial, o arquivo é chamado de main.tf.

      mkdir DIRECTORY && cd DIRECTORY && touch main.tf

   2. Se você estiver seguindo um tutorial, poderá copiar o exemplo de código em cada seção ou etapa.

      Copie o exemplo de código no main.tf recém-criado.

      Se preferir, copie o código do GitHub. Isso é recomendado quando o snippet do Terraform faz parte de uma solução de ponta a ponta.

   3. Revise e modifique os parâmetros de amostra para aplicar ao seu ambiente.
   4. Salve as alterações.
   5. Inicialize o Terraform. Você só precisa fazer isso uma vez por diretório.

      terraform init

      Opcionalmente, para usar a versão mais recente do provedor do Google, inclua a opção -upgrade:

      terraform init -upgrade

   Aplique as alterações

   1. Revise a configuração e verifique se os recursos que o Terraform vai criar ou atualizar correspondem às suas expectativas:

      terraform plan

      Faça as correções necessárias na configuração.

   2. Para aplicar a configuração do Terraform, execute o comando a seguir e digite yes no prompt:

      terraform apply

      Aguarde até que o Terraform exiba a mensagem "Apply complete!".

   3. Abra seu Google Cloud projeto para conferir os resultados. No console do Google Cloud , navegue até seus recursos na interface para verificar se foram criados ou atualizados pelo Terraform.
   Observação:as amostras do Terraform geralmente presumem que as APIs necessárias estejam ativadas no seu projeto Google Cloud .

Configurar grupos de endpoints de rede regionais

Para cada região implantada na etapa anterior, você precisa criar grupos de endpoints de rede sem servidor (NEGs) e adicioná-los ao serviço de back-end seguindo estas instruções:

CLI da gcloud

1. Crie um grupo de endpoints de rede para o serviço Cloud Run em REGION:

   gcloud compute network-endpoint-groups create NEG_NAME \
     --region=REGION \
     --network-endpoint-type=serverless \
     --cloud-run-service=SERVICE_NAME

   Substitua:

   • NEG_NAME pelo nome do recurso de grupo de endpoints da rede. Por exemplo, myservice-neg-uscentral1.
   • REGION pela região em que o serviço foi implantado.
   • SERVICE_NAME pelo nome do serviço.

2. Adicione o grupo de endpoints da rede ao serviço de back-end:

   gcloud compute backend-services add-backend --global BACKEND_NAME \
     --network-endpoint-group-region=REGION \
     --network-endpoint-group=NEG_NAME

   Especifique o NEG_NAME que você criou na etapa anterior para a região.

3. Repita as etapas anteriores para cada região.

Terraform

Para saber como aplicar ou remover uma configuração do Terraform, consulte Comandos básicos do Terraform.

1. Configure um grupo de endpoints da rede com o nome myservice-neg para o serviço do Cloud Run em cada região especificada na variável run_regions:

   resource "google_compute_region_network_endpoint_group" "lb_default" {
     provider              = google-beta
     count                 = length(local.run_regions)
     name                  = "myservice-neg"
     network_endpoint_type = "SERVERLESS"
     region                = local.run_regions[count.index]
     cloud_run {
       service = google_cloud_run_v2_service.run_default[count.index].name
     }
   }

2. Configure um serviço de back-end para anexar o grupo de endpoints da rede (myservice-neg):

   resource "google_compute_backend_service" "lb_default" {
     provider              = google-beta
     name                  = "myservice-backend"
     load_balancing_scheme = "EXTERNAL_MANAGED"
   
     backend {
       group = google_compute_region_network_endpoint_group.lb_default[0].id
     }
   
     backend {
       group = google_compute_region_network_endpoint_group.lb_default[1].id
     }
   
     # Use an explicit depends_on clause to wait until API is enabled
     depends_on = [
       google_project_service.compute_api,
     ]
   }

Configurar registros DNS no seu domínio

Para apontar o nome de domínio para a regra de encaminhamento criada, atualize os registros DNS com o endereço IP criado.

1. Encontre o endereço IP reservado do balanceador de carga executando o seguinte comando:

   gcloud compute addresses describe SERVICE_IP \
     --global \
     --format='value(address)'

   Substitua SERVICE_IP pelo nome do endereço IP criado anteriormente. Esse comando imprime o endereço IP na saída.

2. Atualize os registros DNS do seu domínio adicionando um registro A a esse endereço IP.

Configurar o público-alvo personalizado se estiver usando serviços autenticados

Os serviços autenticados são protegidos pelo IAM. Esses serviços do Cloud Run exigem autenticação de cliente que declara o destinatário pretendido de uma solicitação no momento da geração de credenciais (o público-alvo).

Geralmente, o público é o URL completo do serviço de destino que, por padrão, é um URL gerado com final run.app nos serviços do Cloud Run. No entanto, em uma implantação multirregional, um cliente não pode saber com antecedência para qual serviço regional uma solicitação será encaminhada. Portanto, para uma implantação multirregional, configure seu serviço para usar públicos-alvo personalizados.

Aguardar o provisionamento do balanceador de carga

Depois de configurar o domínio com o endereço IP do balanceador de carga, aguarde até que os registros DNS sejam propagados. Da mesma forma, aguarde até que o certificado TLS gerenciado seja emitido para o domínio e esteja pronto para começar a disponibilizar o tráfego HTTPS globalmente.

Pode levar até 30 minutos para que o balanceador de carga comece a disponibilizar o tráfego.

Quando ele estiver pronto, acesse o URL do site com o prefixo https:// para fazer um teste.

Verificar o status

1. Para verificar o status da propagação de registros DNS, use o utilitário de linha de comando dig:

   dig A +short example.com

   A saída mostra o endereço IP configurado nos registros DNS.

2. Para verificar o status da emissão do certificado gerenciado, execute o seguinte comando:

   gcloud compute ssl-certificates describe CERT_NAME

   Substitua CERT_NAME pelo nome escolhido anteriormente para o recurso de certificado SSL.

   A saída mostra uma linha contendo status: ACTIVE.

Configurar o redirecionamento HTTP para HTTPS

Observação: a criação de regras de encaminhamento adicionais está sujeita a cobrança. Consulte os preços do balanceador de carga.

Por padrão, uma regra de encaminhamento só processa um único protocolo. Portanto, as solicitações feitas aos endpoints http:// respondem com 404 Não encontrado. Se você precisar que as solicitações para os URLs http:// sejam redirecionadas para o protocolo https://, crie um mapa de URL adicional e uma regra de encaminhamento seguindo estas instruções:

CLI da gcloud

1. Crie um mapa de URL com uma regra de redirecionamento.

   gcloud compute url-maps import HTTP_URLMAP_NAME \
     --global \
     --source /dev/stdin <<EOF
           name: HTTP_URLMAP_NAME
           defaultUrlRedirect:
             redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
             httpsRedirect: True
           EOF

   Substitua HTTP_URLMAP_NAME pelo nome do recurso de mapa de URL que você vai criar (por exemplo, myservice-httpredirect).

2. Crie um proxy HTTP de destino com o mapa de URL.

   gcloud compute target-http-proxies create HTTP_PROXY_NAME \
     --url-map=HTTP_URLMAP_NAME

   Substitua HTTP_PROXY_NAME pelo nome do proxy HTTP de destino que você vai criar (por exemplo, myservice-http).

3. Crie uma regra de encaminhamento na porta 80 com o mesmo endereço IP reservado.

   gcloud compute forwarding-rules create --global HTTP_FORWARDING_RULE_NAME \
     --target-http-proxy=HTTP_PROXY_NAME \
     --address=SERVICE_IP \
     --ports=80
           

   Substitua HTTP_FORWARDING_RULE_NAME pelo nome da nova regra de encaminhamento que você vai criar (por exemplo, myservice-httplb).

Terraform

Para saber como aplicar ou remover uma configuração do Terraform, consulte Comandos básicos do Terraform.

1. Crie um mapa de URL com uma regra de redirecionamento:

   resource "google_compute_url_map" "https_default" {
     provider = google-beta
     name     = "myservice-https-urlmap"
   
     default_url_redirect {
       redirect_response_code = "MOVED_PERMANENTLY_DEFAULT"
       https_redirect         = true
       strip_query            = false
     }
   }

2. Crie um proxy HTTP de destino com o recurso de mapa de URL recém-criado (myservice-https-urlmap):

   resource "google_compute_target_http_proxy" "https_default" {
     provider = google-beta
     name     = "myservice-http-proxy"
     url_map  = google_compute_url_map.https_default.id
   
     depends_on = [
       google_compute_url_map.https_default
     ]
   }

3. Crie uma regra de encaminhamento na porta 80 com o mesmo endereço IP reservado (myservice-http-proxy).

   resource "google_compute_global_forwarding_rule" "https_default" {
     provider   = google-beta
     name       = "myservice-https-fr"
     target     = google_compute_target_http_proxy.https_default.id
     ip_address = google_compute_global_address.lb_default.id
     port_range = "80"
     depends_on = [google_compute_target_http_proxy.https_default]
   }

Observação: assim como acontece com a regra de encaminhamento de HTTPS, a criação da regra de encaminhamento adicional pode levar algum tempo. Quando tudo estiver pronto, vai ser possível acessar o aplicativo por http:// e ele vai fazer o redirecionamento para o URL https:// com um código de status 301 Movido permanentemente.

Para mais opções de configuração, consulte Configurar um balanceador de carga de aplicativo externo global com o Cloud Run.

Automatizar o failover entre regiões com a integridade do serviço do Cloud Run

Pré-lançamento — Cloud Run service health

Este recurso está sujeito aos "Termos da Oferta Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

A integridade do serviço do Cloud Run minimiza as interrupções e automatiza o failover e o failback entre regiões. Configure um serviço do Cloud Run multirregional de alta disponibilidade com recursos automatizados de failover e failback para tráfego interno.

Limitações

As seguintes limitações se aplicam à integridade do serviço do Cloud Run:

• É necessário configurar pelo menos uma instância mínima no nível de serviço ou de revisão por região para calcular a integridade. Você também pode usar a métrica Contagem de instâncias de contêiner no Cloud Monitoring para estimar o número mínimo de instâncias necessárias para suas regiões.
• Os failovers exigem pelo menos dois serviços de regiões diferentes. Caso contrário, se um serviço falhar, a mensagem de erro no healthy upstream será exibida.
• A integridade do serviço do Cloud Run não é compatível com balanceadores de carga de aplicativo internos entre regiões com mais de cinco back-ends de NEG sem servidor.
• Não é possível configurar uma máscara de URL ou tags em NEGs sem servidor.
• Não é possível ativar o IAP em um serviço de back-end ou balanceador de carga. Ative o IAP diretamente no Cloud Run.
• Se um serviço do Cloud Run for excluído, o Cloud Run não vai informar um status não íntegro ao balanceador de carga.
• Iniciar uma nova instância não conta a primeira sonda de prontidão. Portanto, uma solicitação pode ser brevemente encaminhada para um serviço recém-iniciado antes de ficar sem integridade.
• A integridade do serviço do Cloud Run é calculada em todas as instâncias. As revisões sem sondagens são tratadas como desconhecidas. O balanceador de carga trata instâncias desconhecidas como íntegras.

Informar o status de integridade regional

Para agregar a integridade do serviço regional do Cloud Run e informar um status íntegro ou não íntegro ao balanceador de carga, siga estas etapas:

1. Implante uma revisão de serviço do Cloud Run em várias regiões com uma ou mais instâncias mínimas. Execute o comando a seguir para usar a sondagem de prontidão configurada na etapa anterior:

   gcloud beta run deploy SERVICE_NAME \
   --regions=REGION_A,REGION_B \
   --min=MIN_INSTANCES

   Substitua:

   • SERVICE_NAME: o nome do serviço.
   • REGION_A, REGION_B: diferentes regiões para sua revisão de serviço. Por exemplo, defina REGION_A como us-central1 e REGION_B como europe-west1.
   • MIN_INSTANCES: o número de instâncias de contêiner a serem mantidas quentes e prontas para receber solicitações. Defina o valor mínimo como 1 ou mais.

2. Configure uma sondagem de preparo do gRPC ou HTTP em cada instância de contêiner.

3. Configure um balanceador de carga de aplicativo interno entre regiões para desviar o tráfego de regiões não íntegras.

4. Configure NEGs sem servidor para cada serviço do Cloud Run em cada região.

5. Configure um serviço de back-end para se conectar a NEGs sem servidor.

Práticas recomendadas

É possível usar uma combinação de sondagens de prontidão, divisão de tráfego e instâncias mínimas para fazer lançamentos graduais e seguros. Isso permite verificar a integridade de uma nova revisão em uma única região "canary" antes de promovê-la, garantindo que o balanceador de carga envie tráfego apenas para back-ends regionais íntegros.

Processo de lançamento recomendado

É possível implantar uma revisão de serviço em um serviço do Cloud Run que não esteja usando uma sondagem de prontidão ou a integridade do serviço do Cloud Run. Siga este processo uma região por vez para implantar com segurança uma nova revisão:

1. Implante a nova revisão em uma única região "canário" com uma sonda de prontidão configurada.

2. Envie uma pequena quantidade de tráfego (por exemplo, 1%) para a nova revisão.

3. Use instâncias mínimas diferentes de zero no nível de serviço, em vez do nível de revisão.

4. Verifique a métrica de sondagem de prontidão (run.googleapis.com/container/instance_count_with_readiness) para garantir que as novas instâncias estejam íntegras.

5. Em etapas incrementais, aumente a porcentagem de tráfego para a nova revisão. À medida que você aumenta, monitore a métrica de integridade do serviço regional do Cloud Run (run.googleapis.com/service_health_count), que é usada pelo balanceador de carga. Os relatórios de integridade do serviço do Cloud Run UNKNOWN até que tráfego suficiente seja roteado para a nova revisão.

6. Quando a revisão receber 100% do tráfego e a integridade do serviço regional do Cloud Run estiver estável e íntegra, repita esse processo para todas as outras regiões.

Monitorar verificações de integridade

Depois de configurar a integridade do serviço do Cloud Run, os NEGs sem servidor coletam a métrica de integridade do serviço do Cloud Monitoring. É possível conferir o status de integridade dos serviços regionais atuais. O diagrama a seguir mostra como esses componentes de integridade do serviço do Cloud Run respondem a solicitações para seu serviço:



Se um serviço em uma região não estiver íntegro, o balanceador de carga vai desviar o tráfego da região não íntegra para uma região íntegra. O tráfego é recuperado depois que a região volta a ficar íntegra.

Usar assinaturas de push do Pub/Sub autenticadas com implantação em várias regiões

Por padrão, um serviço Pub/Sub entrega mensagens para endpoints de push na mesma região Google Cloud em que o serviço do Pub/Sub armazena as mensagens. Para uma solução alternativa para esse comportamento, consulte Como usar uma assinatura de push do Pub/Sub autenticada com uma implantação de várias regiões do Cloud Run.

Configurar um failover manual

Para configurar manualmente o failover de tráfego para uma região íntegra, modifique o mapa de URL do balanceador de carga de aplicativo externo global.

1. Para atualizar o mapa de URL do balanceador de carga de aplicativo externo global, remova o NEG do serviço de back-end usando a flag --global:

   gcloud compute backend-services remove-backend BACKEND_NAME \
   --network-endpoint-group=NEG_NAME \
   --network-endpoint-group-region=REGION \
   --global
   

   Substitua:

   • BACKEND_NAME: o nome do serviço de back-end.
   • NEG_NAME: o nome do recurso do grupo de endpoints da rede, por exemplo, myservice-neg-uscentral1.
   • REGION: a região em que o NEG foi criado e de onde você quer remover o serviço. Por exemplo, us-central1,asia-east1.

2. Para confirmar que uma região íntegra está veiculando tráfego, acesse https://<domain-name>.

A seguir

• Saiba como configurar verificações de integridade para serviços do Cloud Run, incluindo sondagens de prontidão.
• Confira um exemplo de código de verificação de prontidão do Cloud Run e integridade do serviço escrito em Go.