Entrega tráfico desde varias regiones

Para mostrar respuestas más rápidas a los usuarios de todo el mundo, debes implementar servicios en varias regiones y enrutar a tus usuarios a la región más cercana.

Debido a que los servicios de Cloud Run se implementan en regiones individuales, debes configurar un balanceador de cargas de aplicaciones externo para enrutar a los usuarios a diferentes regiones del servicio.

En esta guía, se muestra cómo configurar el balanceador de cargas de aplicaciones externo con un dominio protegido con un certificado TLS administrado que apunte a una dirección IP anycast global (que enruta los usuarios al centro de datos de Google más cercano en que se implementa tu servicio).

La arquitectura que se describe en esta guía no enruta automáticamente las solicitudes a una región diferente cuando un servicio regional de Cloud Run deja de responder o comienza a mostrar errores. Para aumentar la disponibilidad de tu servicio multirregional, puedes configurar la detección de valores atípicos a fin de identificar los servicios de Cloud Run en mal estado según su tasa de error de HTTP y desviar algunas solicitudes a otra. región

Crea un balanceador de cargas

Crear un balanceador de cargas externo implica crear varios recursos de red y conectarlos:

Línea de comandos

1. Reserva una dirección IP estática para que no tengas que actualizar los registros DNS cuando vuelves a crear el balanceador de cargas.

   gcloud compute addresses create --global SERVICE_IP

   En el comando anterior, reemplaza SERVICE_IP por un nombre para el recurso de dirección IP (p. ej., myservice-ip).

   Esta dirección IP es una dirección IPv4 anycast global que se enruta al centro de datos de Google o al punto de presencia más cercano a los visitantes.

2. Crea un servicio de backend.

   gcloud compute backend-services create --global BACKEND_NAME

   En el comando anterior, reemplaza BACKEND_NAME por el nombre que deseas darle al servicio de backend (p. ej., myservice-backend).

3. Crea un mapa de URL.

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

   Reemplaza URLMAP_NAME por el nombre que deseas asignar al mapa de URL (p. ej., myservice-urlmap).

4. Crea un certificado TLS administrado para que el dominio entregue tráfico de HTTPS. Reemplaza example.com por el nombre de dominio.

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

   Reemplaza CERT_NAME por el nombre que quieres que tenga el certificado SSL administrado (p. ej., myservice-cert).

5. Crea un proxy HTTPS de destino.

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

   Reemplaza HTTPS_PROXY_NAME por el nombre que deseas otorgar al proxy HTTPS de destino (p. ej., myservice-https).

6. Crea una regla de reenvío que conecte los recursos de red que creaste a la dirección IP.

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

   Reemplaza FORWARDING_RULE_NAME por el nombre del recurso de regla de reenvío que deseas crear (p. ej., myservice-lb).

Terraform

Como alternativa a los pasos descritos en esta sección, puedes usar el Módulo de Terraform del balanceador de cargas de HTTP global.

Agrega lo siguiente a tu archivo de Terraform (por ejemplo, main.tf):

1. Configura la dirección 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 el nombre del recurso de dirección IP como myservice-service-ip. Puedes cambiar esto a tu propio valor. Esta dirección IP es una dirección IPv4 anycast global que se enruta al centro de datos de Google o al punto de presencia más cercano a los visitantes.

2. Crea y configura el servicio de backend:

   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 el servicio de backend para que se llame myservice-backend. Puedes cambiar esto a tu propio valor.

3. Configura el 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 el recurso de servicio de backend (myservice-backend) al nuevo recurso de mapa de URL (myservice-lb-urlmap). Puedes cambiarlos por tus propios valores.

4. Crea un certificado TLS administrado para que el dominio entregue tráfico de HTTPS. Reemplaza example.com por tu nombre de dominio en el 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. Configura el 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
     ]
   }

   Crea un recurso google_compute_target_https_proxy con el nombre de destino myservice-https-proxy y conecta el certificado TLS creado previamente (myservice-ssl-cert) y los recursos de asignación de URL (myservice-lb-urlmap). Puedes cambiarlos por tus propios valores.

6. Configura la regla de reenvío:

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

   Crea el recurso google_compute_global_forwarding_rule con el nombre de destino myservice-https-proxy y conecta el proxy HTTPS de destino (myservice-https-proxy) y el recurso de dirección IP (myservice-service-ip) que creaste anteriormente. Puedes cambiarlos a tus propios valores.

7. Aplica esta configuración:

   Para aplicar tu configuración de Terraform en un proyecto de Google Cloud, completa los pasos de las siguientes secciones.

   Prepara Cloud Shell

   1. Inicia Cloud Shell

   2. Establece el proyecto de Google Cloud predeterminado en el que deseas aplicar tus configuraciones de Terraform.

      Solo necesitas ejecutar este comando una vez por proyecto y puedes ejecutarlo en cualquier directorio.

      export GOOGLE_CLOUD_PROJECT=PROJECT_ID

      Las variables de entorno se anulan si configuras valores explícitos en el archivo de configuración de Terraform.

   Prepara el directorio

   Cada archivo de configuración de Terraform debe tener su propio directorio (también llamado módulo raíz).

   1. En Cloud Shell, crea un directorio y un archivo nuevo dentro de ese directorio. El nombre del archivo debe tener la extensión .tf, por ejemplo, main.tf. En este instructivo, el archivo se denomina main.tf.

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

   2. Si sigues un instructivo, puedes copiar el código de muestra en cada sección o paso.

      Copia el código de muestra en el main.tf recién creado.

      De manera opcional, copia el código de GitHub. Esto se recomienda cuando el fragmento de Terraform es parte de una solución de extremo a extremo.

   3. Revisa y modifica los parámetros de muestra que se aplicarán a tu entorno.
   4. Guarda los cambios.
   5. Inicialice Terraform. Solo debes hacerlo una vez por directorio.

      terraform init

      De manera opcional, incluye la opción -upgrade para usar la última versión del proveedor de Google:

      terraform init -upgrade

   Aplica los cambios

   1. Revisa la configuración y verifica que los recursos que creará o actualizará Terraform coincidan con tus expectativas:

      terraform plan

      Corrige la configuración según sea necesario.

   2. Para aplicar la configuración de Terraform, ejecuta el siguiente comando y, luego, escribe yes cuando se te solicite:

      terraform apply

      Espera hasta que Terraform muestre el mensaje “¡Aplicación completa!”.

   3. Abre tu proyecto de Google Cloud para ver los resultados. En la consola de Google Cloud, navega a tus recursos en la IU para asegurarte de que Terraform los haya creado o actualizado.
   Nota: Por lo general, las muestras de Terraform suponen que las APIs necesarias están habilitadas en tu proyecto de Google Cloud.

Implementa en varias regiones

Implementa el servicio en las regiones de Cloud Run disponibles. Para facilitar la administración, puedes usar el mismo nombre de servicio en varias regiones.

Nota: Los servicios de Cloud Run deben implementarse con la opción que permite el acceso no autenticado (público).

Línea de comandos

1. Elige las regiones en las que quieres que tu servicio esté disponible.
2. Implementa el servicio de Cloud Run en regiones individuales.

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

   Reemplaza las siguientes variables:

   • REGION por una de las regiones en las que deseas realizar la implementación
   • SERVICE_NAME por el nombre de tu servicio Usar el mismo nombre de servicio en varias regiones facilita el seguimiento de las implementaciones multirregionales.
   • IMAGE_URL por una referencia a la imagen del contenedor, como us-docker.pkg.dev/cloudrun/container/hello:latest Si usas Artifact Registry, el repositorio REPO_NAME debe estar creado. La URL tiene el formato REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
4. Repite el paso anterior para cada región.

Terraform

Configura un servicio para cada región especificada en la variable 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
  ]
}

Recorre todas las regiones especificadas en la variable run_regions y nombra cada servicio nuevo de la siguiente manera: myservice-run-app-${var.run_regions[count.index]}. La definición de la ubicación del servicio se aplica de manera similar. Reemplaza la imagen predeterminada us-docker.pkg.dev/cloudrun/container/hello" por tu propia imagen.

Ubicaciones de Cloud Run

Cloud Run es regional, lo que significa que la infraestructura que ejecuta los servicios se ubica en una región específica, y Google la administra para que esté disponible de manera redundante en todas las zonas de esa región.

El cumplimiento de los requisitos de latencia, disponibilidad o durabilidad es el factor principal para seleccionar la región en la que se ejecutan los servicios de Cloud Run. Por lo general, puedes seleccionar la región más cercana a los usuarios, pero debes considerar la ubicación de los otros productos de Google Cloud que usa el servicio de Cloud Run. Si usas productos de Google Cloud en varias ubicaciones, la latencia y el costo del servicio pueden verse afectados.

Cloud Run está disponible en las siguientes regiones:

Sujetas a los Precios del nivel 1

• asia-east1 (Taiwán)
• asia-northeast1 (Tokio)
• asia-northeast2 (Osaka)
• europe-north1 (Finlandia) Bajo nivel de CO₂
• europe-southwest1 (Madrid)
• europe-west1 (Bélgica) Bajo nivel de CO₂
• europe-west4 (Países Bajos)
• europe-west8 (Milán)
• europe-west9 (París) Bajo nivel de CO₂
• me-west1 (Tel Aviv)
• us-central1 (Iowa) Bajo nivel de CO₂
• us-east1 (Carolina del Sur)
• us-east4 (Virginia del Norte)
• us-east5 (Columbus)
• us-south1 (Dallas)
• us-west1 (Oregón) Bajo nivel de CO₂

Sujetas a los Precios del nivel 2

• africa-south1 (Johannesburgo)
• asia-east2 (Hong Kong)
• asia-northeast3 (Seúl, Corea del Sur)
• asia-southeast1 (Singapur)
• asia-southeast2 (Yakarta)
• asia-south1 (Bombay, India)
• asia-south2 Delhi (India)
• australia-southeast1 (Sídney)
• australia-southeast2 (Melbourne)
• europe-central2 (Varsovia, Polonia)
• europe-west10 (Berlín)
• europe-west12 (Turín)
• europe-west2 (Londres, Reino Unido) Bajo nivel de CO₂
• europe-west3 (Fráncfort, Alemania) Bajo nivel de CO₂
• europe-west6 (Zúrich, Suiza) Bajo nivel de CO₂
• me-central1 (Doha)
• me-central2 (Dammam)
• northamerica-northeast1 (Montreal) Bajo nivel de CO₂
• northamerica-northeast2 (Toronto) Bajo nivel de CO₂
• southamerica-east1 (São Paulo, Brasil) Bajo nivel de CO₂
• southamerica-west1 (Santiago, Chile) Bajo nivel de CO₂
• us-west2 (Los Ángeles)
• us-west3 (Salt Lake City)
• us-west4 (Las Vegas)

Si ya creaste un servicio de Cloud Run, puedes ver la región en el panel de Cloud Run en la consola de Google Cloud.

Aceptar

Configura grupos de extremos de red regionales

Para cada región que implementaste en el paso anterior, debes crear grupos de extremos de red (NEG) sin servidores y agregarlos al servicio de backend mediante las siguientes instrucciones:

Línea de comandos

1. Crea un grupo de extremos de red para el servicio de Cloud Run en REGION:

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

   En el comando anterior, reemplaza los siguientes valores:

   • NEG_NAME por el nombre del recurso del grupo de extremos de red (p. ej., “myservice-neg-uscentral1”)
   • REGION por la [region][loc] en la que se implementa el servicio
   • SERVICE_NAME por el nombre de tu servicio

2. Agrega el grupo de extremos de red al servicio de backend:

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

   Especifica el NEG_NAME que creaste en el paso anterior para la región.

3. Repite los pasos anteriores para cada región.

Terraform

1. Configura un grupo de extremos de red con el nombre myservice-neg para el servicio de Cloud Run en cada región especificada en la variable 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. Configura un servicio de backend para conectar el grupo de extremos de red (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,
     ]
   }

Configura registros DNS en el dominio

Para apuntar el nombre de dominio a la regla de reenvío que creaste, debes actualizar los registros DNS con la dirección IP que creaste.

1. Busca la dirección IP reservada del balanceador de cargas mediante la ejecución del siguiente comando:

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

   Reemplaza SERVICE_IP por el nombre de la dirección IP que creaste antes. Con este comando, se imprimirá la dirección IP en el resultado.

2. Para actualizar los registros DNS del dominio, agrega un registro A con esta dirección IP.

Configura el público personalizado si usas servicios autenticados

Los servicios autenticados están protegidos por IAM. Estos servicios de Cloud Run requieren una autenticación de cliente que declare el destinatario previsto de una solicitud durante la generación de la credencial (el público).

El público suele ser la URL completa del servicio de destino, que de forma predeterminada es una URL generada que termina en run.app para los servicios de Cloud Run. Sin embargo, en una implementación multirregional, no es posible que un cliente sepa con anticipación a qué servicio regional se enrutará una solicitud. Por lo tanto, para una implementación multirregional, configura el servicio para usar públicos personalizados.

Espera a que el balanceador de cargas se aprovisione

Después de configurar el dominio con la dirección IP del balanceador de cargas, debes esperar un tiempo para que se propaguen los registros DNS. Del mismo modo, debes esperar un tiempo hasta que se emita el certificado TLS administrado para el dominio y esté listo para entregar tráfico de HTTPS de manera global.

Puede llevar hasta 30 minutos que el balanceador de cargas comience a entregar tráfico.

Una vez que esté listo, visita la URL del sitio web con el prefijo https:// para probarlo.

Verifica el estado

1. Para verificar el estado de la propagación de los registros DNS, usa la utilidad de línea de comandos de dig:

   dig A +short example.com

   El resultado debería mostrar la dirección IP que configuraste en los registros DNS.

2. Para verificar el estado de la emisión del certificado administrado, ejecuta lo siguiente:

   gcloud compute ssl-certificates describe CERT_NAME

   Reemplaza CERT_NAME por el nombre que elegiste antes para el recurso del certificado SSL.

   El resultado debe mostrar una línea que contenga status: ACTIVE.

Configurar el redireccionamiento de HTTP a HTTPS

Nota: La creación de reglas de reenvío adicionales está sujeta a cargos. Consulta los precios del balanceador de cargas.

Según la configuración predeterminada, una regla de reenvío solo controla un único protocolo y, por lo tanto, las solicitudes a los extremos http:// responderán con el error 404 Not Found. Si necesitas que las solicitudes a las URLs http:// se redireccionen al protocolo https://, debes crear un mapa de URL adicional y una regla de reenvío mediante las siguientes instrucciones:

Línea de comandos

1. Cree un mapa de URL con una regla de redireccionamiento.

   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

   Reemplaza HTTP_URLMAP_NAME por el nombre del recurso de mapa de URL que crearás (p. ej., myservice-httpredirect).

2. Crea un proxy HTTP de destino con el mapa de URL.

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

   Reemplaza HTTP_PROXY_NAME por el nombre del proxy HTTP de destino que crearás (p. ej., myservice-http).

3. Crea una regla de reenvío en el puerto 80 con la misma dirección IP reservada.

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

   Reemplaza HTTP_FORWARDING_RULE_NAME por el nombre de la regla de reenvío nueva que crearás (p. ej., myservice-httplb).

Terraform

1. Cree un recurso de mapa de URL con una regla de redireccionamiento.

   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. Crea un proxy HTTP de destino con el recurso de asignación de URL recién creado (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. Crea una regla de reenvío en el puerto 80 con la misma dirección IP reservada (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]
   }

Nota: Al igual que sucede con la regla de reenvío de HTTPS, la creación de la regla de reenvío adicional puede tomar cierto tiempo. Una vez que esté lista, se podrá acceder a la aplicación a través de http://, y la aplicación redireccionará a la URL https:// con un código de estado 301 Moved Permanently.

Usa suscripciones de envío de Pub/Sub autenticadas con implementación multirregional

De forma predeterminada, un servicio de Pub/Sub entrega mensajes a los extremos de envío en la misma región de Google Cloud en la que el servicio de Pub/Sub almacena los mensajes. Para obtener una solución alternativa a este comportamiento, consulta Usa una suscripción de envío de Pub/Sub autenticada con una implementación de Cloud Run multirregional.