Diffuser du trafic provenant de plusieurs régions

Pour renvoyer plus rapidement des réponses aux utilisateurs du monde entier, vous devez déployer des services dans plusieurs régions et diriger les utilisateurs vers la région la plus proche.

Comme les services Cloud Run sont déployés dans des régions individuelles, vous devez configurer un équilibreur de charge d'application externe de manière à diriger les utilisateurs vers différentes régions de votre service.

Ce guide décrit comment configurer un équilibreur de charge d'application externe en utilisant un domaine sécurisé à l'aide d'un certificat TLS géré pointant vers une adresse IP anycast globale qui dirige les utilisateurs vers le centre de données Google le plus proche sur lequel votre service est déployé.

L'architecture décrite dans ce guide n'achemine pas automatiquement les requêtes vers une autre région lorsqu'un service Cloud Run régional ne répond plus ou commence à renvoyer des erreurs. Pour augmenter la disponibilité de votre service multirégional, vous pouvez configurer la détection des anomalies pour identifier les services Cloud Run non opérationnels en fonction de leur taux d'erreur HTTP et répartir certaines requêtes vers une autre.

Créer un équilibreur de charge

Pour créer un équilibreur de charge externe, vous devez créer plusieurs ressources réseau et les associer entre elles :

Ligne de commande

  1. Réservez une adresse IP statique afin de ne pas avoir à mettre à jour vos enregistrements DNS lorsque vous recréez votre équilibreur de charge.
    gcloud compute addresses create --global SERVICE_IP
    Dans la commande ci-dessus, remplacez SERVICE_IP par le nom de la ressource d'adresse IP (par exemple, myservice-ip).

    Cette adresse IP est une adresse IPv4 anycast globale qui redirige vers le centre de données ou le point de présence Google le plus proche des visiteurs.

  2. Créez un service de backend.
    gcloud compute backend-services create --global BACKEND_NAME

    Dans la commande ci-dessus, remplacez BACKEND_NAME par le nom que vous souhaitez attribuer au service de backend (par exemple, myservice-backend).

  3. Créez un mappage d'URL :
    gcloud compute url-maps create URLMAP_NAME --default-service=BACKEND_NAME

    Remplacez URLMAP_NAME par le nom que vous souhaitez attribuer au mappage d'URL (par exemple, myservice-urlmap).

  4. Créez un certificat TLS géré pour que votre domaine diffuse le trafic HTTPS. (Remplacez example.com par votre nom de domaine.)
    gcloud compute ssl-certificates create CERT_NAME \
      --domains=example.com

    Remplacez CERT_NAME par le nom que vous souhaitez attribuer au certificat SSL géré (par exemple, myservice-cert).

  5. Créez un proxy HTTPS cible.
    gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
      --ssl-certificates=CERT_NAME \
      --url-map=URLMAP_NAME

    Remplacez HTTPS_PROXY_NAME par le nom que vous souhaitez attribuer au proxy HTTPS cible (par exemple, myservice-https).

  6. Créez une règle de transfert qui associe les ressources réseau créées à l'adresse IP.
    gcloud compute forwarding-rules create --global FORWARDING_RULE_NAME \
      --target-https-proxy=HTTPS_PROXY_NAME \
      --address=SERVICE_IP \
      --ports=443

    Remplacez FORWARDING_RULE_NAME par le nom de ressource de la règle de transfert que vous souhaitez créer (par exemple, myservice-lb).

Terraform

Au lieu des étapes décrites dans cette section, vous pouvez également utiliser le module Terraform de l'équilibreur de charge HTTP global.

Ajoutez les éléments suivants à votre fichier Terraform (par exemple, main.tf) :

  1. Configurez l'adresse 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
    }

    Nommez votre ressource d'adresse IP myservice-service-ip. Vous pouvez remplacer cette valeur par votre propre valeur. Cette adresse IP est une adresse IPv4 anycast globale qui redirige vers le centre de données ou le point de présence Google le plus proche des visiteurs.

  2. Créez et configurez le service 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,
      ]
    }

    Cette ressource configure le service de backend sous le nom myservice-backend. Vous pouvez remplacer cette valeur par votre propre valeur.

  3. Configurez le mappage d'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"
          }
        }
      }
    }

    Associez la ressource de service de backend (myservice-backend) à la nouvelle ressource de mappage d'URL (myservice-lb-urlmap). Vous pouvez remplacer ces valeurs par vos propres valeurs.

  4. Créez un certificat TLS géré pour que votre domaine diffuse le trafic HTTPS : Remplacez example.com par votre nom de domaine dans la ressource 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. Configurez le 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
      ]
    }

    Créez une ressource google_compute_target_https_proxy avec le nom cible myservice-https-proxy, puis associez les ressources de certificat TLS (myservice-ssl-cert) et de mappage d'URL (myservice-lb-urlmap) précédemment créées. Vous pouvez remplacer ces valeurs par vos propres valeurs.

  6. Configurez la règle de transfert :

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

    Créez une ressource google_compute_global_forwarding_rule avec le nom cible myservice-https-proxy, puis associez les ressources de cible de proxy HTTPS (myservice-https-proxy) et d'adresse IP (myservice-service-ip) précédemment créées. Vous pouvez remplacer ces valeurs par vos propres valeurs.

  7. Appliquez cette configuration :

    Pour appliquer votre configuration Terraform dans un projet Google Cloud, suivez les procédures des sections suivantes.

    Préparer Cloud Shell

    1. Lancez Cloud Shell.
    2. Définissez le projet Google Cloud par défaut dans lequel vous souhaitez appliquer vos configurations Terraform.

      Vous n'avez besoin d'exécuter cette commande qu'une seule fois par projet et vous pouvez l'exécuter dans n'importe quel répertoire.

      export GOOGLE_CLOUD_PROJECT=PROJECT_ID

      Les variables d'environnement sont remplacées si vous définissez des valeurs explicites dans le fichier de configuration Terraform.

    Préparer le répertoire

    Chaque fichier de configuration Terraform doit avoir son propre répertoire (également appelé module racine).

    1. Dans Cloud Shell, créez un répertoire et un nouveau fichier dans ce répertoire. Le nom du fichier doit comporter l'extension .tf, par exemple main.tf. Dans ce tutoriel, le fichier est appelé main.tf.
      mkdir DIRECTORY && cd DIRECTORY && touch main.tf
    2. Si vous suivez un tutoriel, vous pouvez copier l'exemple de code dans chaque section ou étape.

      Copiez l'exemple de code dans le fichier main.tf que vous venez de créer.

      Vous pouvez également copier le code depuis GitHub. Cela est recommandé lorsque l'extrait Terraform fait partie d'une solution de bout en bout.

    3. Examinez et modifiez les exemples de paramètres à appliquer à votre environnement.
    4. Enregistrez les modifications.
    5. Initialisez Terraform. Cette opération n'est à effectuer qu'une seule fois par répertoire.
      terraform init

      Vous pouvez également utiliser la dernière version du fournisseur Google en incluant l'option -upgrade :

      terraform init -upgrade

    Appliquer les modifications

    1. Examinez la configuration et vérifiez que les ressources que Terraform va créer ou mettre à jour correspondent à vos attentes :
      terraform plan

      Corrigez les modifications de la configuration si nécessaire.

    2. Appliquez la configuration Terraform en exécutant la commande suivante et en saisissant yes lorsque vous y êtes invité :
      terraform apply

      Attendez que Terraform affiche le message "Apply completed!" (Application terminée).

    3. Ouvrez votre projet Google Cloud pour afficher les résultats. Dans la console Google Cloud, accédez à vos ressources dans l'interface utilisateur pour vous assurer que Terraform les a créées ou mises à jour.

Déployer un service dans plusieurs régions

Déployez votre service dans les régions disponibles du service Cloud Run. Pour faciliter la gestion, vous pouvez utiliser le même nom de service dans plusieurs régions.

Ligne de commande

  1. Choisissez les régions dans lesquelles vous souhaitez rendre votre service disponible.
  2. Déployez le service Cloud Run dans des régions individuelles.
  3. gcloud run deploy SERVICE_NAME \
    --allow-unauthenticated \
    --image=IMAGE_URL \
    --region=REGION

    Remplacez les variables suivantes :

    • REGION par l'une des régions dans laquelle vous souhaitez effectuer le déploiement.
    • SERVICE_NAME par le nom de votre service. L'utilisation du même nom de service dans plusieurs régions vous permet de suivre plus facilement les déploiements multirégionaux.
    • IMAGE_URL par une référence à l'image de conteneur, par exemple us-docker.pkg.dev/cloudrun/container/hello:latest. Si vous utilisez Artifact Registry, le dépôt REPO_NAME doit déjà être créé. L'URL se présente sous la forme suivante : LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
  4. Répétez l'étape précédente pour chaque région.

Terraform

Configurez un service pour chaque région spécifiée dans 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
  ]
}

Parcourez toutes les régions spécifiées dans la variable run_regions et nommez chaque nouveau service comme suit : myservice-run-app-${var.run_regions[count.index]}. La définition d'un emplacement de service est également appliquée. Remplacez l'image par défaut us-docker.pkg.dev/cloudrun/container/hello" par votre propre image.

Emplacements Cloud Run

Cloud Run est régional, ce qui signifie que l'infrastructure qui exécute vos services Cloud Run est située dans une région spécifique et gérée par Google pour être disponible de manière redondante dans toutes les zones de cette région.

Lors de la sélection de la région dans laquelle exécuter vos services Cloud Run, vous devez tout d'abord considérer vos exigences en matière de latence, de disponibilité et de durabilité. Vous pouvez généralement sélectionner la région la plus proche de vos utilisateurs, mais vous devez tenir compte de l'emplacement des autres produits Google Cloud utilisés par votre service Cloud Run. L'utilisation conjointe de produits Google Cloud dans plusieurs emplacements peut avoir une incidence sur la latence et le coût de votre service.

Cloud Run est disponible dans les régions suivantes :

Soumis aux tarifs de niveau 1

Soumis aux tarifs de niveau 2

  • africa-south1 (Johannesburg)
  • asia-east2 (Hong Kong)
  • asia-northeast3 (Séoul, Corée du Sud)
  • asia-southeast1 (Singapour)
  • asia-southeast2 (Jakarta)
  • asia-south1 (Mumbai, Inde)
  • asia-south2 (Delhi, Inde)
  • australia-southeast1 (Sydney)
  • australia-southeast2 (Melbourne)
  • europe-central2 (Varsovie, Pologne)
  • europe-west10 (Berlin)
  • europe-west12 (Turin)
  • europe-west2 (Londres, Royaume-Uni) icône feuille Faibles émissions de CO2
  • europe-west3 (Francfort, Allemagne) icône feuille Faibles émissions de CO2
  • europe-west6 (Zurich, Suisse) icône feuille Faibles émissions de CO2
  • me-central1 (Doha)
  • me-central2 (Dammam)
  • northamerica-northeast1 (Montréal) icône feuille Faibles émissions de CO2
  • northamerica-northeast2 (Toronto) icône feuille Faibles émissions de CO2
  • southamerica-east1 (São Paulo, Brésil) icône feuille Faibles émissions de CO2
  • southamerica-west1 (Santiago, Chili) icône feuille Faibles émissions de CO2
  • us-west2 (Los Angeles)
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)

Si vous avez déjà créé un service Cloud Run, vous pouvez afficher la région dans le tableau de bord Cloud Run de la console Google Cloud.

Configurer des groupes de points de terminaison du réseau régionaux

Pour chaque région déployée à l'étape précédente, vous devez créer des groupes de points de terminaison du réseau sans serveur (NEG) et les ajouter au service de backend en procédant comme suit :

Ligne de commande

  1. Créez un groupe de points de terminaison du réseau pour le service Cloud Run dans REGION :

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

    Dans la commande ci-dessus, remplacez :

    • NEG_NAME par le nom de la ressource du groupe de points de terminaison du réseau. (par exemple, "myservice-neg-uscentral1")
    • REGION par la région dans laquelle votre service est déployé.
    • SERVICE_NAME par le nom de votre service.
  2. Ajoutez le groupe de points de terminaison du réseau au service de backend :

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

    Indiquez le nom NEG_NAME créé à l'étape précédente pour cette région.

  3. Répétez les étapes ci-dessus pour chaque région.

Terraform

  1. Configurez un groupe de points de terminaison du réseau nommé myservice-neg pour le service Cloud Run dans chaque région spécifiée dans 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. Configurez un service de backend pour associer le groupe de points de terminaison du réseau (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,
      ]
    }

Configurer des enregistrements DNS sur votre domaine

Pour faire pointer votre nom de domaine vers la règle de transfert créée, vous devez mettre à jour ses enregistrements DNS avec l'adresse IP que vous avez créée.

  1. Recherchez l'adresse IP réservée de l'équilibreur de charge en exécutant la commande suivante :

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

    Remplacez SERVICE_IP par le nom de l'adresse IP que vous avez créée précédemment. Cette commande affiche l'adresse IP dans la sortie.

  2. Mettez à jour les enregistrements DNS de votre domaine en ajoutant un enregistrement A avec cette adresse IP.

Configurer une audience personnalisée si vous utilisez des services authentifiés

Les services authentifiés sont protégés par IAM. Les services Cloud Run nécessitent une authentification client qui déclare le destinataire souhaité d'une requête au moment de la génération des identifiants (l'audience).

L'audience est généralement l'URL complète du service cible, qui est par défaut une URL générée se terminant par run.app. Toutefois, dans un déploiement multirégional, un client ne peut pas savoir à l'avance vers quel service régional une requête sera acheminée. Ainsi, pour un déploiement multirégional, configurez votre service pour utiliser des audiences personnalisées.

Attendre le provisionnement de l'équilibreur de charge

Après avoir configuré le domaine avec l'adresse IP de l'équilibreur de charge, vous devez attendre un certain temps avant que les enregistrements DNS se propagent. De même, vous devez attendre un peu avant que le certificat TLS géré soit émis pour votre domaine et qu'il soit prêt à diffuser le trafic HTTPS à l'échelle mondiale.

Votre équilibreur de charge peut prendre jusqu'à 30 minutes pour commencer à diffuser le trafic.

Une fois que l'équilibreur de charge est prêt, accédez à l'URL de votre site Web en ajoutant le préfixe https:// pour l'essayer.

Valider l'état

  1. Pour vérifier l'état de la propagation de votre enregistrement DNS à l'aide de l'utilitaire de ligne de commande dig, procédez comme suit :

    dig A +short example.com

    Le résultat doit afficher l'adresse IP que vous avez configurée dans vos enregistrements DNS.

  2. Vérifiez l'état de l'émission du certificat géré en exécutant la commande suivante :

    gcloud compute ssl-certificates describe CERT_NAME

    Remplacez CERT_NAME par le nom précédemment choisi pour la ressource de certificat SSL.

    Le résultat doit afficher une ligne contenant status: ACTIVE.

Configurer la redirection HTTP vers HTTPS

Par défaut, une règle de transfert ne gère qu'un seul protocole. Par conséquent, les requêtes adressées à vos points de terminaison http:// renvoient la réponse "404 Not Found" (non trouvé). Si vous devez rediriger les requêtes adressées à vos URL http:// vers le protocole https://, vous devez créer un mappage d'URL et une règle de transfert supplémentaire en suivant les instructions suivantes :

Ligne de commande

  1. Créez un mappage d'URL avec une règle de redirection.

    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

    Remplacez HTTP_URLMAP_NAME par le nom de la ressource de mappage d'URL que vous allez créer (par exemple, myservice-httpredirect).

  2. Créez un proxy HTTP cible avec le mappage d'URL.

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

    Remplacez HTTP_PROXY_NAME par le nom du proxy HTTP cible que vous allez créer (par exemple, myservice-http).

  3. Créez une règle de transfert sur le port 80 avec la même adresse IP réservée.

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

    Remplacez HTTP_FORWARDING_RULE_NAME par le nom de la nouvelle règle de transfert que vous allez créer (par exemple, myservice-httplb).

Terraform

  1. Créez une ressource de mappage d'URL avec une règle de redirection :

    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. Créez un proxy HTTP cible avec la ressource de mappage d'URL (myservice-https-urlmap) que vous venez de créer :

    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. Créez une règle de transfert sur le port 80 avec la même ressource d'adresse IP réservée (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]
    }

Utiliser des abonnements push Pub/Sub authentifiés avec un déploiement multirégional

Par défaut, un service Pub/Sub envoie des messages à des points de terminaison push dans la même région Google Cloud où le service Pub/Sub les stocke. Pour contourner ce problème, consultez la page Utiliser un abonnement push Pub/Sub authentifié avec un déploiement Cloud Run multirégion.