Esta página foi traduzida pela API Cloud Translation.

Publicar tráfego de várias regiões

Devolve respostas mais rápidas aos seus utilizadores em todo o mundo implementando serviços em várias regiões e encaminhando os seus utilizadores para a região mais próxima. A implementação em várias regiões oferece baixa latência e maior disponibilidade em caso de interrupções regionais.

Uma vez que os serviços do Cloud Run são implementados em regiões individuais, tem de implementar o seu serviço em várias regiões e, em seguida, configurar o balanceamento de carga global para o serviço.

Pode automatizar a comutação por falha entre regiões através do estado de funcionamento 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.

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.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Configure o ambiente de programação do Cloud Run no seu Google Cloud projeto.
Instale e inicialize a CLI gcloud.
Certifique-se de que a sua conta tem as seguintes funções do IAM:
- Administrador do Cloud Run (roles/run.admin)
- Project IAM Admin (roles/resourcemanager.projectIamAdmin)
- Service Usage Consumer (roles/serviceusage.serviceUsageConsumer)

Conceda as funções

Consola

Na Google Cloud consola, aceda à página IAM.
Aceda ao IAM
Selecione o projeto.
Clique em Conceder acesso.
No campo Novos responsáveis, introduza o identificador do utilizador. Normalmente, este é o endereço de email da Conta Google usado para implementar o serviço do Cloud Run.
Na lista Selecionar uma função, selecione uma função.
Para conceder funções adicionais, clique em Adicionar outra função e selecione cada função adicional.
Clique em Guardar.

gcloud

Para conceder as funções de IAM necessárias à sua conta no seu projeto:

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

Substituir:

PROJECT_NUMBER com o número do seu projeto. Google Cloud
PROJECT_ID com o ID do seu Google Cloud projeto.
PRINCIPAL com a conta à qual está a adicionar a associação. Normalmente, este é o endereço de email da Conta Google que é usado para implementar o serviço do Cloud Run.
ROLE com a função que está a adicionar à conta do implementador.

Reveja a página de preços do Cloud Run. Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.
Ative as APIs Artifact Registry, Cloud Build, Cloud Run Admin API, Compute Engine e Network Services API executando o seguinte comando:

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

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

Os parâmetros de escalabilidade que configurar aplicam-se a várias regiões. Numa implementação em várias regiões, por exemplo, o valor mínimo de instâncias aplica-se a cada uma das várias regiões.

Implementa o mesmo serviço em várias regiões através de um dos seguintes métodos:

Repita os passos para implementar numa única região.
Implemente um serviço multirregional.

Implemente um serviço multirregião

Esta secção mostra como implementar e configurar um serviço de várias regiões a partir de um único comando da CLI gcloud ou através de um ficheiro YAML ou Terraform.

gcloud

Para criar e implementar um serviço de várias regiões, execute o comando gcloud run deploy com a flag --regions:
```
gcloud run deploy SERVICE_NAME \
  --image=IMAGE_URL \
  --regions=REGIONS
```
Substitua o seguinte:
- SERVICE_NAME: o nome do serviço multirregião que quer implementar.
- IMAGE_URL: uma referência à imagem do contentor, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest.
- REGIONS: a lista de várias regiões para as quais quer fazer a implementação. Por exemplo, europe-west1,asia-east1.

YAML

Crie o ficheiro YAML para o seu serviço, usando o atributo run.googleapis.com/regions para definir as várias regiões nas quais quer implementar o seu 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 o seguinte:
- SERVICE_NAME: o nome do serviço multirregião para o qual quer implementar.
- REGIONS: a lista de várias regiões que quer atualizar. Por exemplo, europe-west1,asia-east1.
- IMAGE_URL: uma referência à imagem do contentor, por exemplo, us-docker.pkg.dev/cloudrun/container/hello:latest.

Crie o serviço com o seguinte comando:

gcloud run multi-region-services replace service.yaml

Terraform

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

Adicione o seguinte a um recurso google_cloud_run_v2_service na sua 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ões Google Cloud necessárias. Por exemplo, europe-west1 e us-central1.

Atualize um serviço multirregião

Esta secção mostra como adicionar ou remover regiões de um serviço com várias regiões a partir de um único comando da CLI gcloud ou de um ficheiro YAML.

gcloud

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

Para adicionar o serviço multirregional a uma ou mais regiões adicionais, 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 o seguinte:
- SERVICE_NAME: o nome do serviço multirregional que quer atualizar.
- REGIONS: a região ou as regiões às quais quer adicionar o seu serviço ou das quais quer remover o seu serviço. Por exemplo, us-central1,asia-east1.

YAML

Para atualizar um serviço multirregião existente, transfira a respetiva configuração YAML:

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

Atualize o atributo run.googleapis.com/regions para adicionar ou remover a lista de regiões para as quais quer implementar o serviço:
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE_NAME
  annotations:
    run.googleapis.com/regions: REGIONS
```
Substitua o seguinte:
- SERVICE_NAME: o nome do serviço multirregião para o qual quer implementar.
- REGIONS: a nova lista de várias regiões para as quais quer implementar a revisão do serviço.

Atualize o serviço com o seguinte comando:

gcloud run multi-region-services replace service.yaml

Elimine um serviço multirregião

Para eliminar um serviço de várias regiões, 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 quer eliminar.

Configure um balanceador de carga de aplicações externo global

Esta secção mostra como configurar um Application Load Balancer externo global com um domínio protegido com um certificado TLS gerido que aponta para um endereço IP de anycast global, que encaminha os utilizadores para o centro de dados da Google mais próximo que implementa o seu serviço.

A arquitetura descrita nas secções seguintes não encaminha automaticamente pedidos para uma região diferente quando um serviço do Cloud Run regional deixa de responder ou devolve erros.

Para aumentar a disponibilidade do seu serviço multirregional:

Automatize a ativação pós-falha entre regiões com o estado de funcionamento do serviço do Cloud Run
Configure a deteção de valores atípicos para identificar serviços do Cloud Run não íntegros com base na respetiva taxa de erros HTTP e desviar alguns pedidos para outra região.

Crie um balanceador de carga de aplicações externo global

A criação de um balanceador de carga de aplicações externo global envolve a criação de vários recursos de rede e a respetiva ligação:

gcloud

Reserve um endereço IP estático para não ter de atualizar os registos de DNS quando recriar o 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).
Este endereço IP é um endereço IPv4 anycast global que encaminha para o centro de dados ou o ponto de presença da Google mais próximo dos seus visitantes.
Crie um serviço de back-end.
```
gcloud compute backend-services create \
  --global BACKEND_NAME \
  --load-balancing-scheme=EXTERNAL_MANAGED
```
Substitua BACKEND_NAME por um nome que quer dar ao serviço de back-end. Por exemplo, myservice-backend.
Crie um mapa de URLs.
```
gcloud compute url-maps create URLMAP_NAME --default-service=BACKEND_NAME
```
Substitua URLMAP_NAME por um nome que quer atribuir ao mapa de URLs (por exemplo, myservice-urlmap).
Crie um certificado TLS gerido para o seu domínio para apresentar 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 quer que o certificado SSL gerido tenha (por exemplo, myservice-cert).
Crie um proxy HTTPS de destino.
```
gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
  --ssl-certificates=CERT_NAME \
  --url-map=URLMAP_NAME
```
Substitua HTTPS_PROXY_NAME pelo nome que quer dar ao proxy HTTPS de destino (por exemplo, myservice-https).

Crie uma regra de encaminhamento que associe os recursos de rede que 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 da regra de encaminhamento que quer criar. Por exemplo, myservice-lb.

Terraform

Em alternativa aos passos descritos nesta secção, pode usar o módulo Terraform do balanceador de carga HTTP global.

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

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 do endereço IP como myservice-service-ip. Pode alterar este valor para o seu próprio valor. Este endereço IP é um endereço IPv4 anycast global que encaminha para o centro de dados ou o ponto de presença da Google mais próximo dos seus visitantes.

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 para ter o nome myservice-backend. Pode alterar este valor para o seu próprio valor.

Configure o mapa de URLs:

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"
      }
    }
  }
}

Associa o recurso do serviço de back-end (myservice-backend) ao novo recurso do mapa de URLs (myservice-lb-urlmap). Pode alterar estes valores para os seus próprios valores.

Crie um certificado TLS gerido para o seu domínio para apresentar tráfego HTTPS. Substitua example.com pelo nome do seu 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"]
  }
}

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 um recurso google_compute_target_https_proxy com o nome de destino myservice-https-proxy e associa o certificado TLS (myservice-ssl-cert) e os recursos de mapeamento de URLs (myservice-lb-urlmap) criados anteriormente. Pode alterar estes valores para os seus próprios valores.

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 associa o destino do proxy HTTPS criado anteriormente (myservice-https-proxy) e o recurso de endereço IP (myservice-service-ip). Pode alterar estes valores para os seus próprios valores.

Aplicar esta configuração:

Para aplicar a configuração do Terraform num Google Cloud projeto, conclua os passos nas secções seguintes.

Prepare o Cloud Shell
1. Inicie o Cloud Shell.
2. Defina o Google Cloud projeto predefinido onde quer aplicar as suas configurações do Terraform.
  
  Só tem de executar este comando uma vez por projeto e pode executá-lo em qualquer diretório.
```
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
```
  As variáveis de ambiente são substituídas se definir valores explícitos no ficheiro de configuração do Terraform.
Prepare o diretório

Cada ficheiro de configuração do Terraform tem de ter o seu próprio diretório (também denominado módulo raiz).
1. No Cloud Shell, crie um diretório e um novo ficheiro nesse diretório. O nome do ficheiro tem de ter a extensão .tf, por exemplo, main.tf. Neste tutorial, o ficheiro é denominado main.tf.
```
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
```
2. Se estiver a seguir um tutorial, pode copiar o código de exemplo em cada secção ou passo.
  
  Copie o exemplo de código para o main.tf criado recentemente.
  
  Opcionalmente, copie o código do GitHub. Isto é recomendado quando o fragmento do Terraform faz parte de uma solução completa.
3. Reveja e modifique os parâmetros de exemplo para aplicar ao seu ambiente.
4. Guarde as alterações.
5. Inicialize o Terraform. Só tem de fazer isto uma vez por diretório.
```
terraform init
```
  Opcionalmente, para usar a versão mais recente do fornecedor Google, inclua a opção -upgrade:
```
terraform init -upgrade
```
Aplique as alterações
1. Reveja a configuração e verifique se os recursos que o Terraform vai criar ou atualizar correspondem às suas expetativas:
```
terraform plan
```
  Faça correções à configuração conforme necessário.
2. Aplique a configuração do Terraform executando o seguinte comando e introduzindo yes no comando:
```
terraform apply
```
  Aguarde até que o Terraform apresente a mensagem "Apply complete!" (Aplicação concluída!).
3. Abra o seu Google Cloud projeto para ver os resultados. Na Google Cloud consola, navegue para os seus recursos na IU para se certificar de que o Terraform os criou ou atualizou.
Nota: os exemplos do Terraform partem do princípio de que as APIs necessárias estão ativadas no seu Google Cloud projeto.

Configure grupos de pontos finais de rede regionais

Para cada região na qual fez a implementação no passo anterior, tem de criar grupos de pontos finais de rede (NEGs) sem servidor e adicioná-los ao serviço de back-end através das seguintes instruções:

CLI gcloud

Crie um grupo de pontos finais de rede para o serviço do Cloud Run em REGION:
```
gcloud compute network-endpoint-groups create NEG_NAME \
  --region=REGION \
  --network-endpoint-type=serverless \
  --cloud-run-service=SERVICE_NAME
```
Substitua o seguinte:
- NEG_NAME com o nome do recurso do grupo de pontos finais de rede. (por exemplo, myservice-neg-uscentral1)
- REGION com a região na qual o seu serviço está implementado.
- SERVICE_NAME com o nome do seu serviço.

Adicione o grupo de pontos finais de 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 criou no passo anterior para a região.

Repita os passos anteriores para cada região.

Terraform

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

Configure um grupo de pontos finais de rede com o nome myservice-neg para o serviço do Cloud Run para 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
  }
}

Configure um serviço de back-end para anexar o grupo de pontos finais 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,
  ]
}

Configure os registos DNS no seu domínio

Para direcionar o seu nome de domínio para a regra de encaminhamento que criou, atualize os respetivos registos de DNS com o endereço IP que criou.

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 que criou anteriormente. Este comando imprime o endereço IP no resultado.
Atualize os registos de DNS do seu domínio adicionando um registo A com este endereço IP.

Configure o público-alvo personalizado se usar serviços autenticados

Os serviços autenticados estão protegidos pela IAM. Estes serviços do Cloud Run requerem autenticação do cliente que declara o destinatário pretendido de um pedido no momento da geração de credenciais (o público-alvo).

O público-alvo é normalmente o URL completo do serviço de destino, que, por predefinição, para os serviços do Cloud Run, é um URL gerado que termina em run.app. No entanto, numa implementação em várias regiões, um cliente não pode saber antecipadamente para que serviço regional um pedido vai ser encaminhado. Assim, para uma implementação em várias regiões, configure o seu serviço para usar públicos-alvo personalizados.

Aguarde o aprovisionamento do balanceador de carga

Depois de configurar o domínio com o endereço IP do balanceador de carga, aguarde que os registos de DNS sejam propagados. Da mesma forma, aguarde que o certificado TLS gerido seja emitido para o seu domínio e esteja pronto para começar a publicar tráfego HTTPS a nível global.

O balanceador de carga pode demorar até 30 minutos a começar a publicar tráfego.

Quando estiver pronto, visite o URL do seu Website com o prefixo https:// para o experimentar.

Validar estado

Para verificar o estado da propagação do seu registo DNS, use a dig utilidade de linha de comandos:
```
dig A +short example.com
```
O resultado mostra o endereço IP que configurou nos seus registos DNS.
Verifique o estado da emissão do certificado gerido executando o seguinte comando:
```
gcloud compute ssl-certificates describe CERT_NAME
```
Substitua CERT_NAME pelo nome que escolheu anteriormente para o recurso de certificado SSL.

O resultado mostra uma linha que contém status: ACTIVE.

Configure o redirecionamento de HTTP para HTTPS

Por predefinição, uma regra de encaminhamento processa apenas um único protocolo e, por isso, os pedidos aos seus pontos finais http:// respondem com "404 Not Found". Se precisar que os pedidos aos seus http://URLs sejam redirecionados para o protocolo https://, crie um mapa de URLs adicional e uma regra de encaminhamento com as seguintes instruções:

CLI gcloud

Crie um mapa de URLs 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 do mapa de URLs que vai criar (por exemplo, myservice-httpredirect).

Crie um proxy HTTP de destino com o mapa de URLs.
```
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 vai criar (por exemplo, myservice-http).
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 vai criar (por exemplo, myservice-httplb).

Terraform

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

Crie um recurso de mapa de URLs 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
  }
}

Crie um proxy HTTP de destino com o recurso de mapa de URLs 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
  ]
}

Crie uma regra de encaminhamento na porta 80 com o mesmo recurso de 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]
}

Para opções de configuração adicionais, consulte o artigo Configure um Application Load Balancer externo global com o Cloud Run.

Automatize a comutação por falha entre regiões com o estado de funcionamento do serviço do Cloud Run

O estado de funcionamento do serviço do Cloud Run minimiza as interrupções do serviço e automatiza a comutação por falha e a recuperação entre regiões. Configure um serviço do Cloud Run de alta disponibilidade em várias regiões com capacidades de ativação pós-falha e recuperação automáticas para tráfego interno.

Limitações

As seguintes limitações aplicam-se ao estado de funcionamento do serviço do Cloud Run:

Tem de configurar, pelo menos, uma instância mínima ao nível do serviço ou da revisão por região para calcular o estado de funcionamento. Também pode usar a métrica Contagem de instâncias de contentores no Cloud Monitoring para estimar as instâncias mínimas necessárias para as suas regiões.
As comutações por falha requerem, pelo menos, dois serviços de regiões diferentes. Caso contrário, se um dos serviços falhar, é apresentada a mensagem de erro no healthy upstream.
O estado de funcionamento do serviço do Cloud Run não suporta equilibradores de carga de aplicações internos entre regiões com mais de 5 back-ends de NEG sem servidor.
Não pode configurar uma máscara de URL nem etiquetas em NEGs sem servidor.
Não pode ativar o IAP a partir de um serviço de back-end ou de um balanceador de carga. Ative o IAP diretamente a partir do Cloud Run.
Se um serviço do Cloud Run for eliminado, o Cloud Run não comunica um estado não saudável ao equilibrador de carga.
O início de uma nova instância não conta com a primeira sondagem de prontidão, pelo que um pedido pode ser brevemente encaminhado para um serviço iniciado recentemente antes de ficar em mau estado.
O estado de funcionamento do serviço do Cloud Run é calculado em todas as instâncias. As revisões sem sondas são tratadas como desconhecidas. O balanceador de carga trata as instâncias desconhecidas como íntegras.

Comunique o estado de saúde regional

Para agregar o estado de funcionamento do serviço do Cloud Run regional e comunicar um estado em bom ou mau estado ao equilibrador de carga, siga estes passos:

Implemente 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 seguinte para usar a sondagem de prontidão que configurou no passo anterior:
```
gcloud beta run deploy SERVICE_NAME \
--regions=REGION_A,REGION_B \
--min=MIN_INSTANCES
```
Substitua o seguinte:
- SERVICE_NAME: o nome do serviço.
- REGION_A, REGION_B: regiões diferentes para a revisão do seu 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 contentores a manter ativas, prontas para receber pedidos. Tem de definir o valor mínimo como 1 ou mais.
Configure uma sondagem de disponibilidade de gRPC ou HTTP configurada em cada instância do contentor.
Configure um Application Load Balancer interno entre regiões para desviar o tráfego de regiões não saudáveis.
Configure NEGs sem servidor para cada serviço do Cloud Run em cada região.
Configure um serviço de back-end para estabelecer ligação a NEGs sem servidor.

Práticas recomendadas

Pode usar uma combinação de sondas de prontidão, divisão de tráfego e instâncias mínimas para fazer implementações seguras e graduais. Isto permite-lhe validar o estado de funcionamento de uma nova revisão numa única região de "teste" antes de a promover, garantindo que o balanceador de carga envia tráfego apenas para back-ends regionais em bom estado.

Processo de implementação recomendado

Pode implementar uma revisão de serviço num serviço do Cloud Run existente que não esteja a usar uma sondagem de disponibilidade nem o estado de funcionamento do serviço do Cloud Run. Siga este processo uma região de cada vez para implementar em segurança uma nova revisão:

Implemente a nova revisão numa única região "canary" com uma sondagem de disponibilidade configurada.
Envie uma pequena quantidade de tráfego (por exemplo, 1%) para a nova revisão.
Use instâncias mínimas diferentes de zero ao nível do serviço, em vez de ao nível da revisão.
Verifique a métrica da sondagem de disponibilidade (run.googleapis.com/container/instance_count_with_readiness) para garantir que as novas instâncias estão em bom estado.
Aumente a percentagem de tráfego para a nova revisão em passos incrementais. À medida que aumenta a escala, monitorize a métrica de estado do serviço do Cloud Run regional (run.googleapis.com/service_health_count), que é usada pelo balanceador de carga. Relatórios de estado do serviço do Cloud Run UNKNOWN até que seja encaminhado tráfego suficiente para a nova revisão.
Quando a revisão receber 100% do tráfego e o estado do serviço do Cloud Run regional estiver estável e em bom estado, repita este processo para todas as outras regiões.

Monitorize as verificações de funcionamento

Depois de configurar o estado de funcionamento do serviço do Cloud Run, os NEGs sem servidor recolhem a métrica de estado de funcionamento do Cloud Monitoring. Pode ver o estado de funcionamento dos serviços regionais existentes. O diagrama seguinte mostra como estes componentes de verificação do estado do serviço do Cloud Run respondem aos pedidos para o seu serviço:

Ilustração dos componentes de estado de funcionamento do serviço do Cloud Run

Se um serviço numa região estiver em mau estado, o balanceador de carga desvia o tráfego da região em mau estado para uma região em bom estado. O tráfego é recuperado depois de a região voltar a ficar em bom estado.

Use subscrições push do Pub/Sub autenticadas com implementação em várias regiões

Por predefinição, um serviço Pub/Sub envia mensagens para pontos finais de envio por push na mesma Google Cloud região onde o serviço Pub/Sub armazena as mensagens. Para uma solução alternativa a este comportamento, consulte o artigo Usar uma subscrição push do Pub/Sub autenticada com uma implementação do Cloud Run em várias regiões.

Configure uma comutação por falha manual

Para configurar manualmente o tráfego para comutação por falha para uma região em bom estado, modifique o mapa de URLs do balanceador de carga de aplicações externo global.

Para atualizar o mapa de URLs do Application Load Balancer externo global, remova o NEG do serviço de back-end com a flag --global:
```
gcloud compute backend-services remove-backend BACKEND_NAME \
--network-endpoint-group=NEG_NAME \
--network-endpoint-group-region=REGION \
--global
```
Substitua o seguinte:
- BACKEND_NAME: o nome do serviço de back-end.
- NEG_NAME: o nome do recurso do grupo de pontos finais da rede, por exemplo, myservice-neg-uscentral1.
- REGION: a região onde o NEG foi criado e da qual quer remover o seu serviço. Por exemplo, us-central1,asia-east1.
Para confirmar que uma região saudável está agora a publicar tráfego, navegue para https://<domain-name>.

O que se segue?

Saiba como configurar verificações de estado para serviços do Cloud Run, incluindo sondas de prontidão.

Consulte um exemplo de código de uma sondagem de prontidão do Cloud Run e do estado de funcionamento do serviço escrito em Go.

Publicar tráfego de várias regiões Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Conceda as funções

Consola

gcloud

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

Implemente um serviço multirregião

gcloud

YAML

Terraform

Atualize um serviço multirregião

gcloud

YAML

Elimine um serviço multirregião

Configure um balanceador de carga de aplicações externo global

Crie um balanceador de carga de aplicações externo global

gcloud

Terraform

Prepare o Cloud Shell

Prepare o diretório

Aplique as alterações

Configure grupos de pontos finais de rede regionais

CLI gcloud

Terraform

Configure os registos DNS no seu domínio

Configure o público-alvo personalizado se usar serviços autenticados

Aguarde o aprovisionamento do balanceador de carga

Validar estado

Configure o redirecionamento de HTTP para HTTPS

CLI gcloud

Terraform

Automatize a comutação por falha entre regiões com o estado de funcionamento do serviço do Cloud Run

Limitações

Comunique o estado de saúde regional

Práticas recomendadas

Processo de implementação recomendado

Monitorize as verificações de funcionamento

Use subscrições push do Pub/Sub autenticadas com implementação em várias regiões

Configure uma comutação por falha manual

O que se segue?

Publicar tráfego de várias regiões