Cette page a été traduite par l'API Cloud Translation.

Diffuser du trafic provenant de plusieurs régions

Vous pouvez renvoyer plus rapidement des réponses aux utilisateurs du monde entier en déployant des services dans plusieurs régions et en redirigeant les utilisateurs vers la région la plus proche. Le déploiement dans plusieurs régions offre une latence faible et une disponibilité accrue en cas d'indisponibilités régionales.

Comme les services Cloud Run sont déployés dans des régions individuelles, vous devez déployer votre service dans plusieurs régions, puis configurer l'équilibrage de charge mondial pour le service.

Vous pouvez automatiser le basculement multirégional à l'aide de l'état de santé des services Cloud Run.

Avant de commencer

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.

Configurez votre environnement de développement Cloud Run dans votre projet Google Cloud .
Installez et initialisez la gcloud CLI.
Assurez-vous que votre compte dispose des rôles IAM suivants :
- Administrateur Cloud Run (roles/run.admin)
- Administrateur de projet IAM (roles/resourcemanager.projectIamAdmin)
- Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer)

Attribuer les rôles

Console

Dans la console Google Cloud , accédez à la page IAM.
Accéder à IAM
Sélectionnez le projet.
Cliquez sur Accorder l'accès.
Dans le champ Nouveaux comptes principaux, saisissez votre identifiant utilisateur. Il s'agit généralement de l'adresse e-mail du compte Google utilisé pour déployer le service Cloud Run.
Dans la liste Sélectionner un rôle, sélectionnez un rôle.
Pour attribuer des rôles supplémentaires, cliquez sur Ajouter un autre rôle et sélectionnez tous les rôles supplémentaires.
Cliquez sur Enregistrer.

gcloud

Pour attribuer les rôles IAM requis à votre compte dans votre projet :

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

Remplacez :

PROJECT_NUMBER par le numéro de votre projet Google Cloud .
PROJECT_ID par l'ID de votre projet Google Cloud .
PRINCIPAL par le compte pour lequel vous ajoutez la liaison. Il s'agit généralement de l'adresse e-mail du compte Google utilisé pour déployer le service Cloud Run.
ROLE par le rôle que vous ajoutez au compte du déployeur.

Consultez la page des tarifs de Cloud Run. Pour obtenir une estimation des coûts en fonction de votre utilisation prévue, utilisez le simulateur de coût.
Activez les API Artifact Registry, Cloud Build, Cloud Run Admin, Compute Engine et Network Services en exécutant la commande suivante :

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

Déployer le service dans plusieurs régions

Les paramètres de scaling que vous configurez s'appliquent à plusieurs régions. Dans un déploiement multirégional, par exemple, la valeur minimale des instances s'applique à chacune des régions.

Vous déployez le même service dans plusieurs régions à l'aide de l'une des méthodes suivantes :

Répétez les étapes pour déployer dans une seule région.
Déployez un service multirégional.

Déployer un service multirégional

Cette section explique comment déployer et configurer un service multirégional à l'aide d'une seule commande gcloud CLI ou à l'aide d'un fichier YAML ou Terraform.

gcloud

Pour créer et déployer un service multirégional, exécutez la commande gcloud run deploy à l'aide de l'option --regions :
```
gcloud run deploy SERVICE_NAME \
  --image=IMAGE_URL \
  --regions=REGIONS
```
Remplacez les éléments suivants :
- SERVICE_NAME : nom du service multirégional que vous souhaitez déployer.
- IMAGE_URL : référence à l'image de conteneur, par exemple us-docker.pkg.dev/cloudrun/container/hello:latest.
- REGIONS : liste des régions dans lesquelles vous souhaitez effectuer le déploiement. Exemple :europe-west1,asia-east1

YAML

Créez le fichier YAML pour votre service, en utilisant l'attribut run.googleapis.com/regions pour définir les régions dans lesquelles vous souhaitez déployer votre service :
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE_NAME
  annotations:
    run.googleapis.com/regions: REGIONS
spec:
  template:
    spec:
      containers:
      - image: IMAGE_URL
```
Remplacez les éléments suivants :
- SERVICE_NAME : nom du service multirégional dans lequel vous souhaitez effectuer le déploiement.
- REGIONS : liste des régions que vous souhaitez mettre à jour. Exemple :europe-west1,asia-east1
- IMAGE_URL : référence à l'image de conteneur, par exemple us-docker.pkg.dev/cloudrun/container/hello:latest.

Créez le service à l'aide de la commande suivante :

gcloud run multi-region-services replace service.yaml

Terraform

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez Commandes Terraform de base.

Ajoutez les éléments suivants à une ressource google_cloud_run_v2_service dans votre configuration 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"
}
}
}

Remplacez "REGION_1" et "REGION_2" par chacune des régionsGoogle Cloud requises. Par exemple, europe-west1 et us-central1.

Mettre à jour un service multirégional

Cette section explique comment ajouter ou supprimer des régions d'un service multirégional à l'aide d'une seule commande gcloud CLI ou d'un fichier YAML.

gcloud

Pour ajouter ou supprimer des régions d'un service multirégional, exécutez la commande gcloud run multi-region-services update.

Pour ajouter le service multirégional à une ou plusieurs régions supplémentaires, utilisez l'option --add-regions :
```
gcloud run multi-region-services update SERVICE_NAME \
  --add-regions=REGIONS
```
Pour supprimer le service multirégional d'une ou de plusieurs régions, utilisez l'option --remove-regions :
```
gcloud run multi-region-services update SERVICE_NAME \
  --remove-regions=REGIONS
```
Remplacez les éléments suivants :
- SERVICE_NAME : nom du service multirégional que vous souhaitez mettre à jour.
- REGIONS : région ou régions dans lesquelles vous souhaitez ajouter ou supprimer votre service. Exemple : us-central1,asia-east1.

YAML

Pour mettre à jour un service multirégional existant, téléchargez sa configuration YAML :

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

Mettez à jour l'attribut run.googleapis.com/regions pour ajouter ou supprimer la liste des régions dans lesquelles vous souhaitez déployer le service :
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE_NAME
  annotations:
    run.googleapis.com/regions: REGIONS
```
Remplacez les éléments suivants :
- SERVICE_NAME : nom du service multirégional dans lequel vous souhaitez effectuer le déploiement.
- REGIONS : nouvelle liste des régions dans lesquelles vous souhaitez déployer la révision du service.
Mettez à jour le service à l'aide de la commande suivante :
```
gcloud run multi-region-services replace service.yaml
```

Supprimer un service multirégional

Pour supprimer un service multirégional, exécutez la commande gcloud run multi-region-services delete :
```
gcloud run multi-region-services delete SERVICE_NAME
```
Remplacez SERVICE_NAME par le nom du service multirégional que vous souhaitez supprimer.

Configurer un équilibreur de charge d'application externe global

Cette section décrit comment configurer un équilibreur de charge d'application externe mondial 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 qui déploie votre service.

L'architecture décrite dans les sections suivantes n'achemine pas automatiquement les requêtes vers une autre région lorsqu'un service Cloud Run régional ne répond plus ou renvoie des erreurs.

Pour augmenter la disponibilité de votre service multirégional :

Automatiser le basculement interrégional avec l'état de santé des services Cloud Run
Configurez 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 région.

Créer un équilibreur de charge d'application externe global

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

gcloud

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.
Créez un service de backend.
```
gcloud compute backend-services create \
  --global BACKEND_NAME \
  --load-balancing-scheme=EXTERNAL_MANAGED
```
Remplacez BACKEND_NAME par le nom que vous souhaitez attribuer au service de backend. Exemple :myservice-backend
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).
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).
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).
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 \
  --load-balancing-scheme=EXTERNAL_MANAGED 
```
Remplacez FORWARDING_RULE_NAME par le nom de la ressource de règle de transfert que vous souhaitez créer. 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.

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez Commandes Terraform de base.

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 of presence Google le plus proche des visiteurs.

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.

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.

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

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.

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.

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.
Remarque : Les exemples Terraform partent généralement du principe que les API requises sont activées dans votre projet 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 :

gcloud CLI

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
```
Remplacez les éléments suivants :
- 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.

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.

Répétez les étapes précédentes pour chaque région.

Terraform

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez Commandes Terraform de base.

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

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, mettez à jour ses enregistrements DNS avec l'adresse IP que vous avez créée.

Recherchez l'adresse IP réservée de l'équilibreur de charge en exécutant la commande suivante :
```
gcloud compute addresses describe SERVICE_IP \
  --global \
  --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.
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égion, un client ne peut pas savoir à l'avance vers quel service régional une requête sera acheminée. Par conséquent, pour un déploiement multirégional, configurez votre service pour qu'il utilise 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, attendez que les enregistrements DNS se propagent. De même, attendez 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

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 affiche l'adresse IP que vous avez configurée dans vos enregistrements DNS.
Vérifiez l'état de l'émission de votre 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 affiche 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://, créez un mappage d'URL et une règle de transfert supplémentaires en suivant les instructions suivantes :

gcloud CLI

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

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

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez Commandes Terraform de base.

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

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

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

Pour découvrir d'autres options de configuration, consultez Configurer un équilibreur de charge d'application externe global avec Cloud Run.

Automatiser le basculement multirégional avec l'état du service Cloud Run

L'état de santé des services Cloud Run minimise les interruptions de service et automatise le basculement et le rétablissement interrégionaux. Configurez un service Cloud Run multirégional et à haute disponibilité avec des fonctionnalités de basculement et de reprise automatisées pour le trafic interne.

Limites

Les limites suivantes s'appliquent à l'état de santé des services Cloud Run :

Vous devez configurer au moins une instance minimale au niveau du service ou de la révision par région pour calculer l'état. Vous pouvez également utiliser la métrique Nombre d'instances de conteneur dans Cloud Monitoring pour estimer le nombre minimal d'instances requis pour vos régions.
Les basculements nécessitent au moins deux services provenant de régions différentes. Sinon, si un service échoue, le message d'erreur no healthy upstream s'affiche.
L'état de santé des services Cloud Run n'est pas compatible avec les équilibreurs de charge d'application internes interrégionaux comportant plus de cinq backends NEG sans serveur.
Vous ne pouvez pas configurer de masque d'URL ni de tags dans les NEG sans serveur.
Vous ne pouvez pas activer IAP à partir d'un service de backend ou d'un équilibreur de charge. Activez IAP directement depuis Cloud Run.
Si un service Cloud Run est supprimé, Cloud Run ne signale pas d'état non opérationnel à l'équilibreur de charge.
Le premier test d'aptitude d'une nouvelle instance ne sera pas comptabilisé. Par conséquent, une requête peut être brièvement acheminée vers un service qui vient de démarrer avant de devenir non opérationnel.
L'état de santé du service Cloud Run est calculé sur toutes les instances. Les révisions sans sondes sont traitées comme inconnues. L'équilibreur de charge considère les instances inconnues comme opérationnelles.

Signaler l'état de santé régional

Pour agréger l'état de santé des services Cloud Run régionaux et signaler un état sain ou non sain à l'équilibreur de charge, procédez comme suit :

Déployez une révision de service Cloud Run dans plusieurs régions avec un ou plusieurs nombres minimaux d'instances. Exécutez la commande suivante pour utiliser la vérification d'aptitude que vous avez configurée à l'étape précédente :
```
gcloud beta run deploy SERVICE_NAME \
--regions=REGION_A,REGION_B \
--min=MIN_INSTANCES
```
Remplacez les éléments suivants :
- SERVICE_NAME : nom du service.
- REGION_A, REGION_B : différentes régions pour la révision de votre service. Par exemple, définissez REGION_A sur us-central1 et REGION_B sur europe-west1.
- MIN_INSTANCES : nombre d'instances de conteneur à garder en attente et prêtes à recevoir des requêtes. Vous devez définir la valeur minimale sur 1 ou plus.
Configurez une vérification de préparation gRPC ou HTTP sur chaque instance de conteneur.
Configurez un équilibreur de charge d'application interne interrégional pour rediriger le trafic des régions non opérationnelles.
Configurez des NEG sans serveur pour chaque service Cloud Run dans chaque région.
Configurez un service de backend pour qu'il se connecte aux NEG sans serveur.

Bonnes pratiques

Vous pouvez combiner des vérifications d'aptitude, la répartition du trafic et un nombre minimal d'instances pour effectuer des déploiements progressifs et sécurisés. Cela vous permet de vérifier l'état d'une nouvelle révision dans une seule région "canari" avant de la promouvoir, en vous assurant que l'équilibreur de charge n'envoie le trafic qu'aux backends régionaux opérationnels.

Processus de déploiement recommandé

Vous pouvez déployer une révision de service sur un service Cloud Run existant qui n'utilise pas de vérification d'aptitude ni l'état de santé du service Cloud Run. Suivez cette procédure région par région pour déployer une nouvelle révision en toute sécurité :

Déployez la nouvelle révision dans une seule région "canary" avec une vérification de l'état de préparation configurée.
Envoyez une petite quantité de trafic (par exemple, 1 %) vers la nouvelle révision.
Utilisez un nombre minimal d'instances non nul au niveau du service plutôt qu'au niveau de la révision.
Vérifiez la métrique de sonde de disponibilité (run.googleapis.com/container/instance_count_with_readiness) pour vous assurer que les nouvelles instances sont opérationnelles.
Augmentez progressivement le pourcentage de trafic dirigé vers la nouvelle révision. À mesure que vous augmentez le trafic, surveillez la métrique d'état du service Cloud Run régional (run.googleapis.com/service_health_count), qui est utilisée par l'équilibreur de charge. Les rapports sur l'état du service Cloud Run UNKNOWN jusqu'à ce qu'un trafic suffisant soit acheminé vers la nouvelle révision.
Une fois que la révision reçoit 100 % du trafic et que l'état du service Cloud Run régional est stable et opérationnel, répétez ce processus pour toutes les autres régions.

Surveiller les vérifications de l'état

Une fois que vous avez configuré l'état de santé du service Cloud Run, les NEG sans serveur collectent la métrique d'état de santé du service Cloud Monitoring. Vous pouvez consulter l'état des services régionaux existants. Le schéma suivant montre comment ces composants d'état de santé du service Cloud Run répondent aux requêtes adressées à votre service :

Illustration des composants d'état du service Cloud Run

Si un service d'une région n'est pas opérationnel, l'équilibreur de charge redirige le trafic de la région non opérationnelle vers une région opérationnelle. Le trafic est rétabli une fois la région redevenue opérationnelle.

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 multirégional Cloud Run.

Configurer un basculement manuel

Pour configurer manuellement le basculement du trafic vers une région saine, modifiez le mappage d'URL de l'équilibreur de charge d'application externe global.

Pour mettre à jour le mappage d'URL de l'équilibreur de charge d'application externe global, supprimez le NEG du service de backend à l'aide de l'indicateur --global :
```
gcloud compute backend-services remove-backend BACKEND_NAME \
--network-endpoint-group=NEG_NAME \
--network-endpoint-group-region=REGION \
--global
```
Remplacez les éléments suivants :
- BACKEND_NAME : nom du service de backend.
- NEG_NAME : nom de la ressource du groupe de points de terminaison du réseau, par exemple myservice-neg-uscentral1.
- REGION : région dans laquelle le NEG a été créé et à partir de laquelle vous souhaitez supprimer votre service. Exemple : us-central1,asia-east1.
Pour vérifier qu'une région opérationnelle diffuse désormais le trafic, accédez à https://<domain-name>.

Étapes suivantes

Découvrez comment configurer des vérifications d'état pour les services Cloud Run, y compris les sondes de disponibilité.

Consultez un exemple de code écrit en Go pour une vérification de l'état de préparation et de l'état de santé d'un service Cloud Run.

Diffuser du trafic provenant de plusieurs régions Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Avant de commencer

Attribuer les rôles

Console

gcloud

Déployer le service dans plusieurs régions

Déployer un service multirégional

gcloud

YAML

Terraform

Mettre à jour un service multirégional

gcloud

YAML

Supprimer un service multirégional

Configurer un équilibreur de charge d'application externe global

Créer un équilibreur de charge d'application externe global

gcloud

Terraform

Préparer Cloud Shell

Préparer le répertoire

Appliquer les modifications

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

gcloud CLI

Terraform

Configurer des enregistrements DNS sur votre domaine

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

Attendre le provisionnement de l'équilibreur de charge

Valider l'état

Configurer la redirection HTTP vers HTTPS

gcloud CLI

Terraform

Automatiser le basculement multirégional avec l'état du service Cloud Run

Limites

Signaler l'état de santé régional

Bonnes pratiques

Processus de déploiement recommandé

Surveiller les vérifications de l'état

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

Configurer un basculement manuel

Étapes suivantes

Diffuser du trafic provenant de plusieurs régions