Veicular tráfego de várias regiões

Para dar respostas mais rápidas a usuários por todo o mundo, você precisa implantar serviços em várias regiões e encaminhar esses usuários para a região mais próxima.

Como os serviços do Cloud Run são implantados em regiões individuais, é necessário configurar o balanceador de carga de aplicativo externo para encaminhar os usuários a diferentes regiões do serviço.

Este guia mostra como configurar o balanceador de carga de aplicativo externo 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 seu serviço implantado.

A arquitetura descrita neste guia não encaminha automaticamente solicitações para uma região diferente quando um serviço regional do Cloud Run deixa de responder ou começa a retornar erros. Para aumentar a disponibilidade do serviço multirregional, 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 outro. região.

criar um balanceador de carga

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

Linha de comando

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

   No comando acima, substitua BACKEND_NAME pelo nome que você quer fornecer 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

   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.

Adicione o seguinte ao seu arquivo do Terraform (por exemplo, main.tf):

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. 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 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 de 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 do 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 do 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 do Google Cloud, conclua as etapas nas seções a seguir.

   Preparar o Cloud Shell

   1. Inicie o Cloud Shell.

   2. Defina o projeto padrão do Google Cloud 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 projeto do Google Cloud para ver os resultados. No console do Google Cloud, navegue até seus recursos na IU 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 projeto do Google Cloud.

Implantar em várias regiões

Implante o serviço nas regiões disponíveis do Cloud Run. Para facilitar o gerenciamento, use o mesmo nome de serviço em várias regiões.

Observação: os serviços do Cloud Run precisam ser implantados com a opção que permite o acesso (público) não autenticado.

Linha de comando

1. Escolha as regiões em que você quer disponibilizar o serviço.
2. Implante o serviço do Cloud Run em regiões individuais.

3. gcloud run deploy SERVICE_NAME \
   --allow-unauthenticated \
   --image=IMAGE_URL \
   --region=REGION

   Substitua as seguintes variáveis:

   • REGION por uma das regiões em que você quer implantar;
   • SERVICE_NAME pelo nome do serviço; Usar o mesmo nome de serviço em várias regiões facilita o controle das implantações em várias regiões;
   • IMAGE_URL por uma referência à imagem de contêiner. Por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest. Se você usa o Artifact Registry, o repositório REPO_NAME já precisará ter sido criado. O URL tem o formato REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
4. Repita a etapa anterior para cada região.

Terraform

Configura um serviço para cada região especificada na variável run_regions.

resource "google_cloud_run_v2_service" "run_default" {
  provider = google-beta
  count    = length(local.run_regions)
  name     = "myservice-run-app-${local.run_regions[count.index]}"
  location = local.run_regions[count.index]

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

  # Use an explicit depends_on clause to wait until API is enabled
  depends_on = [
    google_project_service.run_api
  ]
}

Repetições de todas as regiões especificadas na variável run_regions e nomeia cada novo serviço como: myservice-run-app-${var.run_regions[count.index]}. A definição do local do serviço também é aplicada. Substitua a imagem padrão us-docker.pkg.dev/cloudrun/container/hello" pela sua própria imagem.

Locais do Cloud Run

O Cloud Run é regional, o que significa que a infraestrutura que executa seus serviços do Cloud Run está localizada em uma região específica e é gerenciada pelo Google para estar disponível de maneira redundante em todas as zonas da região.

Atender aos seus requisitos de latência, disponibilidade ou durabilidade são os principais fatores para selecionar a região em que seus serviços do Cloud Run são executados. Geralmente, é possível selecionar a região mais próxima de seus usuários, mas considere a localização dos outros produtos do Google Cloud usados pelo serviço do Cloud Run. O uso de produtos do Google Cloud em vários locais pode afetar a latência e o custo do serviço.

O Cloud Run está disponível nas regiões a seguir:

Sujeitas aos preços do nível 1

• asia-east1 (Taiwan)
• asia-northeast1 (Tóquio)
• asia-northeast2 (Osaka)
• europe-north1 (Finlândia) Baixo CO₂
• europe-southwest1 (Madrid)
• europe-west1 (Bélgica) Baixo CO_₂
• europe-west4 (Países Baixos)
• europe-west8 (Milão)
• europe-west9 (Paris) Baixo CO₂
• me-west1 (Tel Aviv)
• us-central1 (Iowa) Baixo CO₂
• us-east1 (Carolina do Sul)
• us-east4 (Norte da Virgínia)
• us-east5 (Columbus)
• us-south1 (Dallas)
• us-west1 (Oregon) Baixo CO₂

Sujeitas aos preços do nível 2

• africa-south1 (Johannesburgo)
• asia-east2 (Hong Kong)
• asia-northeast3 (Seul, Coreia do Sul)
• asia-southeast1 (Singapura)
• asia-southeast2 (Jacarta)
• asia-south1 (Mumbai, Índia)
• asia-south2 (Déli, Índia)
• australia-southeast1 (Sydney)
• australia-southeast2 (Melbourne)
• europe-central2 (Varsóvia, Polônia)
• europe-west10 (Berlim)
• europe-west12 (Turim)
• europe-west2 (Londres, Reino Unido) Baixo CO₂
• europe-west3 (Frankfurt, Alemanha) Baixo CO₂
• europe-west6 (Zurique, Suíça) Baixo CO₂
• me-central1 (Doha)
• me-central2 (Damã)
• northamerica-northeast1 (Montreal) Baixo CO₂
• northamerica-northeast2 (Toronto) Baixo CO₂
• southamerica-east1 (São Paulo, Brasil) Baixo CO₂
• southamerica-west1 (Santiago, Chile) Baixo CO₂
• us-west2 (Los Angeles)
• us-west3 (Salt Lake City)
• us-west4 (Las Vegas)

Se você já criou um serviço do Cloud Run, é possível visualizar a região no painel do Cloud Run no console do Google Cloud.

OK

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, na sigla em inglês) e adicioná-los ao serviço de back-end usando as seguintes instruções:

Linha de comando

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

   No comando acima, 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 acima para cada região.

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

Apontar seu nome de domínio para a regra de encaminhamento criada por você exige atualizar seus registros DNS com o endereço IP que você criou.

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

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

   Substitua SERVICE_IP pelo nome do endereço IP criado anteriormente. Esse comando imprimirá 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, não é possível para um cliente 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, você precisa aguardar um tempo para que os registros DNS sejam propagados. Da mesma forma, é necessário esperar um pouco até que o certificado TLS gerenciado seja emitido para seu 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 tráfego.

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

Verificar o status

1. Para verificar o status da propagação de registro DNS usando o utilitário de linha de comando dig:

   dig A +short example.com

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

2. Verifique o status da emissão do certificado gerenciado. Execute:

   gcloud compute ssl-certificates describe CERT_NAME

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

   A saída deve mostrar 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 para os endpoints http:// responderão com o erro 404 Not Found. Se você precisar que as solicitações para seus URLs http:// sejam redirecionadas para o protocolo https://, será necessário criar um mapa de URL adicional e uma regra de encaminhamento usando as seguintes instruções:

Linha de comando

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ê 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ê 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ê criará (por exemplo, myservice-httplb).

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: tal como a regra de encaminhamento de HTTPS, criar a regra de encaminhamento adicional pode levar algum tempo. Quando estiver pronto, seu aplicativo será válido por http:// e redirecionará para o URL https:// com um código de status 301 "Movido Permanentemente".

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