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

Configurez un équilibreur de charge d'application interne interrégional avec des backends de groupes d'instances de VM.

Ce document fournit des instructions de configuration d'un équilibreur de charge d'application interne interrégional pour vos services exécutés sur des instances de machine virtuelle (VM) Compute Engine.

Avant de commencer

Avant de suivre ce guide, familiarisez-vous avec les points suivants :

Présentation de l'équilibreur de charge d'application interne, y compris la section Limites
Présentation des règles de pare-feu VPC

Configurer une ressource de certificat SSL

Créez une ressource de certificat SSL pour le gestionnaire de certificats, comme décrit dans les articles suivants :

Nous vous recommandons d'utiliser un certificat géré par Google.

Autorisations

Pour suivre ce guide, vous devez savoir comment créer des instances et modifier un réseau dans un projet. Vous devez être propriétaire ou éditeur du projet, ou disposer de tous les rôles IAM Compute Engine suivants :

Tâche	Rôle requis
Créer des réseaux, des sous-réseaux et des composants de l'équilibreur de charge	Administrateur de réseaux Compute
Ajouter et supprimer des règles de pare-feu	Administrateur de sécurité de Compute
Créer des instances	Administrateur d'instances Compute

Pour en savoir plus, consultez les guides suivants :

Vue d'ensemble de la configuration

Vous pouvez configurer l'équilibreur de charge comme indiqué dans le schéma suivant :

Déploiement haute disponibilité de l'équilibreur de charge d'application interne interrégional (cliquez pour agrandir)

Comme le montre le schéma, cet exemple crée un équilibreur de charge d'application interne interrégional dans un réseau VPC, avec un service de backend et deux groupes d'instances gérés dans les régions REGION_A et REGION_B.

Le schéma montre les éléments suivants :

Un réseau VPC avec les sous-réseaux suivants :
- Le sous-réseau SUBNET_A et un sous-réseau proxy réservé dans REGION_A.
- Le sous-réseau SUBNET_B et un sous-réseau proxy réservé dans REGION_B.
Vous devez créer des sous-réseaux proxy réservés dans chaque région du réseau VPC dans lequel vous utilisez des équilibreurs de charge d'application internes interrégionaux. Le sous-réseau proxy réservé de la région est partagé entre tous les équilibreurs de charge d'application internes interrégionaux dans la région. Les adresses sources des paquets envoyés depuis l'équilibreur de charge vers les backends de votre service sont attribuées à partir du sous-réseau proxy réservé. Dans cet exemple, le sous-réseau proxy réservé de la région REGION_A possède une plage d'adresses IP principale de 10.129.0.0/23 et, pour REGION_B, une plage d'adresses IP principale de 10.130.0.0/23 utilisant la taille de sous-réseau recommandée.
La configuration à haute disponibilité intègre des backends de groupes d'instances gérés pour les déploiements de VM Compute Engine dans les régions REGION_A et REGION_B. Si les backends d'une région sont indisponibles, le trafic bascule vers l'autre région.
Un service de backend global surveillant l'utilisation et l'état des backends.
Un mappage d'URL global qui analyse l'URL des requêtes et les transfère à des services de backend spécifiques en fonction de l'hôte et du chemin d'accès de l'URL de la requête.
Un proxy HTTP ou HTTPS global cible qui reçoit la requête de l'utilisateur et la transfère au mappage d'URL. Pour le protocole HTTPS, configurez une ressource de certificat SSL global. Le proxy cible utilise le certificat SSL pour déchiffrer le trafic SSL si vous configurez l'équilibrage de charge HTTPS. Le proxy cible peut transférer le trafic vers vos instances à l'aide du protocole HTTP ou HTTPS.
Les règles de transfert globales, qui disposent de l'adresse IP interne régionale de votre équilibreur de charge, pour transmettre chaque requête entrante au proxy cible.

L'adresse IP interne associée à la règle de transfert peut provenir de n'importe quel sous-réseau du même réseau et de la même région que les backends. Veuillez noter les conditions suivantes :
- L'adresse IP peut (mais ne doit pas nécessairement) provenir du même sous-réseau que les groupes d'instances backend.
- L'adresse IP ne doit pas provenir d'un sous-réseau proxy réservé dont l'option --purpose est définie sur GLOBAL_MANAGED_PROXY.
- Si vous souhaitez utiliser la même adresse IP interne avec plusieurs règles de transfert, définissez l'option d'adresse IP --purpose sur SHARED_LOADBALANCER_VIP.
Facultatif : Configurez des règles de routage DNS de type GEO pour acheminer le trafic client vers l'adresse IP virtuelle de l'équilibreur de charge dans la région la plus proche du client.

Configurer le réseau et les sous-réseaux

Au sein du réseau VPC, configurez un sous-réseau dans chaque région où vos backends sont configurés. En outre, configurez un objet proxy-only-subnet dans chaque région où vous souhaitez configurer l'équilibreur de charge.

Cet exemple utilise le réseau VPC, la région et les sous-réseaux suivants :

Réseau : le réseau est un réseau VPC en mode personnalisé nommé NETWORK.
Sous-réseaux pour les backends.
- Un sous-réseau nommé SUBNET_A dans la région REGION_A utilise 10.1.2.0/24 pour sa plage d'adresses IP principale.
- Un sous-réseau nommé SUBNET_B dans la région REGION_B utilise 10.1.3.0/24 pour sa plage d'adresses IP principale.
Sous-réseaux pour les proxys.
- Un sous-réseau nommé PROXY_SN_A dans la région REGION_A utilise 10.129.0.0/23 pour sa plage d'adresses IP principale.
- Un sous-réseau nommé PROXY_SN_B dans la région REGION_B utilise 10.130.0.0/23 pour sa plage d'adresses IP principale.

Les équilibreurs de charge d'application internes interrégionaux sont accessibles depuis n'importe quelle région du VPC. Ainsi, les clients de n'importe quelle région peuvent accéder aux backends de votre équilibreur de charge à l'échelle mondiale.

Configurer les sous-réseaux backend

Console

Dans la console Google Cloud, accédez à la page Réseaux VPC.

Accéder aux réseaux VPC
Cliquez sur Créer un réseau VPC.
Saisissez un Nom pour le réseau.
Dans la section Sous-réseaux, définissez le Mode de création du sous-réseau sur Personnalisé.
Créez un sous-réseau pour les backends de l'équilibreur de charge. Dans la section Nouveau sous-réseau, saisissez les informations suivantes :
- Renseignez un Nom pour le sous-réseau.
- Sélectionnez une région : REGION_A.
- Saisissez une plage d'adresses IP : 10.1.2.0/24
Cliquez sur OK.
Cliquez sur Ajouter un sous-réseau.
Créez un sous-réseau pour les backends de l'équilibreur de charge. Dans la section Nouveau sous-réseau, saisissez les informations suivantes :
- Renseignez un Nom pour le sous-réseau.
- Sélectionnez une région : REGION_B.
- Saisissez une plage d'adresses IP : 10.1.3.0/24
Cliquez sur OK.
Cliquez sur Créer.

gcloud

Créez le réseau VPC personnalisé à l'aide de la commande gcloud compute networks create :
```
gcloud compute networks create NETWORK \
    --subnet-mode=custom
```
Créez un sous-réseau dans le réseau NETWORK de la région REGION_A à l'aide de la commande gcloud compute networks subnets create :
```
gcloud compute networks subnets create SUBNET_A \
    --network=NETWORK \
    --range=10.1.2.0/24 \
    --region=REGION_A
```
Créez un sous-réseau dans le réseau NETWORK de la région REGION_B à l'aide de la commande gcloud compute networks subnets create :
```
gcloud compute networks subnets create SUBNET_B \
    --network=NETWORK \
    --range=10.1.3.0/24 \
    --region=REGION_B
```

Terraform

Pour créer le réseau VPC, utilisez la ressource google_compute_network.

resource "google_compute_network" "default" {
  auto_create_subnetworks = false
  name                    = "lb-network-crs-reg"
  provider                = google-beta
}

Pour créer le sous-réseau VPC dans le réseau lb-network-crs-reg, utilisez la ressource google_compute_subnetwork.

resource "google_compute_subnetwork" "subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.1.2.0/24"
  name          = "lbsubnet-uswest1"
  network       = google_compute_network.default.id
  region        = "us-west1"
}

resource "google_compute_subnetwork" "subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.1.3.0/24"
  name          = "lbsubnet-useast1"
  network       = google_compute_network.default.id
  region        = "us-east1"
}

API

Envoyez une requête POST à la méthode networks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

Envoyez une requête POST à la méthode subnetworks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/lb-network-crs-reg",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

Envoyez une requête POST à la méthode subnetworks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

Configurer le sous-réseau proxy réservé

Un sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google Cloud pour exécuter des proxys Envoy en votre nom. Les proxys interrompent les connexions du client et créent de nouvelles connexions vers les backends.

Ce sous-réseau proxy réservé est utilisé par tous les équilibreurs de charge régionaux basés sur Envoy dans la même région que le réseau VPC. Il ne peut y avoir qu'un seul sous-réseau proxy réservé actif pour une utilisation donnée, par région et par réseau.

Console

Si vous utilisez la console Google Cloud, vous pouvez créer le sous-réseau proxy réservé ultérieurement sur la page Équilibrage de charge.

Si vous souhaitez créer le sous-réseau proxy réservé maintenant, procédez comme suit :

Dans la console Google Cloud, accédez à la page Réseaux VPC.

Accéder aux réseaux VPC
Cliquez sur le nom du réseau VPC.
Dans l'onglet Sous-réseau, cliquez sur Ajouter un sous-réseau.
Saisissez un Nom pour le sous-réseau proxy réservé.
Sélectionnez une région : REGION_A.
Dans la liste Objectif, sélectionnez Proxy géré interrégional.
Dans le champ Plage d'adresses IP, saisissez 10.129.0.0/23.
Cliquez sur Ajouter.

Créez le sous-réseau proxy réservé dans REGION_B.

Dans l'onglet Sous-réseau, cliquez sur Ajouter un sous-réseau.
Saisissez un Nom pour le sous-réseau proxy réservé.
Sélectionnez une région : REGION_B.
Dans la liste Objectif, sélectionnez Proxy géré interrégional.
Dans le champ Plage d'adresses IP, saisissez 10.130.0.0/23.
Cliquez sur Ajouter.

gcloud

Créez le sous-réseau proxy réservé à l'aide de la commande gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23

    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23

Terraform

Pour créer le sous-réseau proxy réservé VPC dans le réseau lb-network-crs-reg, utilisez la ressource google_compute_subnetwork.

resource "google_compute_subnetwork" "proxy_subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.129.0.0/23"
  name          = "proxy-only-subnet1"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-west1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

resource "google_compute_subnetwork" "proxy_subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.130.0.0/23"
  name          = "proxy-only-subnet2"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-east1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

API

Créez les sous-réseaux proxy réservés avec la méthode subnetworks.insert, en remplaçant PROJECT_ID par votre ID de projet.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": " PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

Configurer des règles de pare-feu

Cet exemple utilise les règles de pare-feu suivantes :

fw-ilb-to-backends. 22 : règle d'entrée, applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise la connectivité SSH entrante sur le port TCP à partir de n'importe quelle adresse. Vous pouvez choisir une plage d'adresses IP sources plus restrictive pour cette règle. Par exemple, vous pouvez spécifier uniquement les plages d'adresses IP du système à partir duquel vous souhaitez lancer des sessions SSH. Cet exemple utilise le tag cible allow-ssh pour identifier les VM auxquelles la règle de pare-feu s'applique.
fw-healthcheck : règle d'entrée applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise tout le trafic TCP issu des systèmes de vérification d'état Google Cloud (dans 130.211.0.0/22 et 35.191.0.0/16). Cet exemple utilise le tag cible load-balanced-backend pour identifier les VM auxquelles la règle de pare-feu s'applique.
fw-backends. Règle d'entrée applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise le trafic TCP sur les ports 80, 443 et 8080 à partir des proxys gérés de l'équilibreur de charge d'application interne. Cet exemple utilise le tag cible load-balanced-backend pour identifier les VM auxquelles la règle de pare-feu s'applique.

Sans ces règles de pare-feu, la règle d'entrée interdite par défaut bloque le trafic entrant vers les instances backend.

Les tags cibles définissent les instances backend. Sans les tags cibles, les règles de pare-feu s'appliquent à toutes les instances backend du réseau VPC. Lorsque vous créez les VM de backend, veillez à inclure les tags cibles spécifiés, comme décrit dans la section Créer un groupe d'instances géré.

Console

Dans la console Google Cloud, accédez à la page Règles d'administration.

Accéder à la page "Stratégies de pare-feu"
Cliquez de nouveau sur Créer une règle de pare-feu pour créer la règle autorisant les connexions SSH entrantes :
- Nom : fw-ilb-to-backends
- Réseau : NETWORK
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : Tags cibles spécifiés
- Tags cibles : allow-ssh
- Filtre source : Plages IPv4
- Plages IPv4 sources : 0.0.0.0/0
- Protocoles et ports :
  - Choisissez Protocoles et ports spécifiés.
  - Cochez la case TCP, puis saisissez 22 pour le numéro de port.
Cliquez sur Créer.
Cliquez une deuxième fois sur Créer une règle de pare-feu pour créer la règle autorisant les vérifications d'état Google Cloud :
- Nom : fw-healthcheck
- Réseau : NETWORK
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : Tags cibles spécifiés
- Tags cibles : load-balanced-backend
- Filtre source : Plages IPv4
- Plages IPv4 sources : 130.211.0.0/22 et 35.191.0.0/16
- Protocoles et ports :
  - Choisissez Protocoles et ports spécifiés.
  - Cochez la case TCP, puis saisissez 80 pour le numéro de port.
  Nous vous recommandons de limiter cette règle aux seuls protocoles et ports qui correspondent à ceux utilisés par votre vérification de l'état. Si vous utilisez tcp:80 pour le protocole et le port, Google Cloud peut contacter vos VM via HTTP sur le port 80, mais pas via HTTPS sur le port 443.
Cliquez sur Créer.
Cliquez une troisième fois sur Créer une règle de pare-feu pour créer la règle autorisant les serveurs proxy de l'équilibreur de charge à se connecter aux backends :
- Nom : fw-backends
- Réseau : NETWORK
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : Tags cibles spécifiés
- Tags cibles : load-balanced-backend
- Filtre source : Plages IPv4
- Plages IPv4 sources : 10.129.0.0/23 et 10.130.0.0/23
- Protocoles et ports :
  - Choisissez Protocoles et ports spécifiés.
  - Cochez la case TCP, puis saisissez 80, 443, 8080 pour les numéros de port.
Cliquez sur Créer.

gcloud

Créez la règle de pare-feu fw-ilb-to-backends pour autoriser la connectivité SSH aux VM avec le tag réseau allow-ssh. Lorsque vous omettez source-ranges, Google Cloud interprète la règle comme désignant n'importe quelle source.
```
gcloud compute firewall-rules create fw-ilb-to-backends \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22
```
Créez la règle fw-healthcheck pour autoriser les vérifications d'état Google Cloud. Cet exemple autorise tout le trafic TCP provenant des tests de vérification d'état. Toutefois, vous pouvez configurer un ensemble de ports plus restreint en fonction de vos besoins.
```
gcloud compute firewall-rules create fw-healthcheck \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
```
Créez la règle fw-backends pour autoriser les proxys de l'équilibreur de charge d'application interne à se connecter à vos backends. Définissez source-ranges sur les plages allouées de votre sous-réseau proxy réservé, par exemple 10.129.0.0/23 et 10.130.0.0/23.
```
gcloud compute firewall-rules create fw-backends \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --source-ranges=source-range \
    --target-tags=load-balanced-backend \
    --rules=tcp:80,tcp:443,tcp:8080
```

Terraform

Pour créer les règles de pare-feu, utilisez la ressource google_compute_firewall.

resource "google_compute_firewall" "fw_healthcheck" {
  name          = "gl7-ilb-fw-allow-hc"
  provider      = google-beta
  direction     = "INGRESS"
  network       = google_compute_network.default.id
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16", "35.235.240.0/20"]
  allow {
    protocol = "tcp"
  }
}

resource "google_compute_firewall" "fw_ilb_to_backends" {
  name          = "fw-ilb-to-fw"
  provider      = google-beta
  network       = google_compute_network.default.id
  source_ranges = ["0.0.0.0/0"]
  allow {
    protocol = "tcp"
    ports    = ["22", "80", "443", "8080"]
  }
}

resource "google_compute_firewall" "fw_backends" {
  name          = "gl7-ilb-fw-allow-ilb-to-backends"
  direction     = "INGRESS"
  network       = google_compute_network.default.id
  source_ranges = ["10.129.0.0/23", "10.130.0.0/23"]
  target_tags   = ["http-server"]
  allow {
    protocol = "tcp"
    ports    = ["80", "443", "8080"]
  }
}

API

Créez la règle de pare-feu fw-ilb-to-backends en envoyant une requête POST à la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-ilb-to-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

Créez la règle de pare-feu fw-healthcheck en envoyant une requête POST à la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-healthcheck",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   }
 ],
 "direction": "INGRESS"
}

Créez la règle de pare-feu fw-backends pour autoriser le trafic TCP dans le sous-réseau proxy pour la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "10.129.0.0/23",
   "10.130.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

Créer un groupe d'instances géré

Cette section explique comment créer un modèle et un groupe d'instances géré. Le groupe d'instances géré fournit des instances de VM exécutant les serveurs de backend d'un exemple d'équilibreur de charge d'application interne interrégional. Pour votre groupe d'instances, vous pouvez définir un service HTTP et mapper un nom de port sur le port correspondant. Le service de backend de l'équilibreur de charge transfère le trafic vers les ports nommés. Le trafic des clients fait l'objet d'un équilibrage de charge par rapport aux serveurs de backend. À des fins de démonstration, les backends diffusent leurs propres noms d'hôte.

Console

Dans la console Google Cloud, accédez à la page Modèles d'instances.

Accéder à la page Modèles d'instances
1. Cliquez sur Create instance template (Créer un modèle d'instance).
2. Dans le champ Nom, saisissez gil7-backendeast1-template.
3. Assurez-vous que le disque de démarrage est défini sur une image Debian, telle que Debian GNU/Linux 12 (bookworm). Ces instructions utilisent des commandes uniquement disponibles dans Debian, comme apt-get.
4. Cliquez sur Options avancées.
5. Cliquez sur Mise en réseau et configurez les champs suivants :
  1. Pour Tags réseau, saisissez allow-ssh et load-balanced-backend.
  2. Pour Interfaces réseau, sélectionnez l'option suivante :
    - Réseau : NETWORK
    - Sous-réseau : SUBNET_B
6. Cliquez sur Gestion. Saisissez le script suivant dans le champ Script de démarrage.
```
#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2
```
7. Cliquez sur Créer.
8. Cliquez sur Créer un modèle d'instance.
9. Dans le champ Nom, saisissez gil7-backendwest1-template.
10. Assurez-vous que le disque de démarrage est défini sur une image Debian, telle que Debian GNU/Linux 12 (bookworm). Ces instructions utilisent des commandes uniquement disponibles dans Debian, comme apt-get.
11. Cliquez sur Options avancées.
12. Cliquez sur Mise en réseau et configurez les champs suivants :
  1. Pour Tags réseau, saisissez allow-ssh et load-balanced-backend.
  2. Pour Interfaces réseau, sélectionnez l'option suivante :
    - Réseau : NETWORK
    - Sous-réseau : SUBNET_A
13. Cliquez sur Gestion. Saisissez le script suivant dans le champ Script de démarrage.
```
#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2
```
14. Cliquez sur Créer.
Dans la console Google Cloud, accédez à la page Groupes d'instances.

Accéder à la page "Groupes d'instances"
1. Cliquez sur Créer un groupe d'instances.
2. Sélectionnez Nouveau groupe d'instances géré (sans état). Pour plus d'informations, consultez la page Groupes d'instances gérés (MIG) sans état ou avec état.
3. Dans le champ Nom, saisissez gl7-ilb-mig-a.
4. Pour Emplacement, sélectionnez Zone unique.
5. Pour Région, sélectionnez REGION_A.
6. Pour Zone, sélectionnez ZONE_A.
7. Pour Modèle d'instance, sélectionnez gil7-backendwest1-template.
8. Spécifiez le nombre d'instances que vous souhaitez créer au sein du groupe.
  
  Pour cet exemple, spécifiez les options suivantes sous Autoscaling :
  - Dans le champ Mode autoscaling, sélectionnez Off:do not autoscale.
  - Dans le champ Nombre maximal d'instances, saisissez 2.
  Si vous le souhaitez, dans la section Autoscaling de l'interface utilisateur, vous pouvez configurer le groupe d'instances de manière à ajouter ou supprimer automatiquement des instances en fonction de l'utilisation du processeur.
9. Cliquez sur Créer.
10. Cliquez sur Créer un groupe d'instances.
11. Sélectionnez Nouveau groupe d'instances géré (sans état). Pour plus d'informations, consultez la page Groupes d'instances gérés (MIG) sans état ou avec état.
12. Dans le champ Nom, saisissez gl7-ilb-mig-b.
13. Pour Emplacement, sélectionnez Zone unique.
14. Pour Région, sélectionnez REGION_B.
15. Pour Zone, sélectionnez ZONE_B.
16. Pour Modèle d'instance, sélectionnez gil7-backendeast1-template.
17. Spécifiez le nombre d'instances que vous souhaitez créer au sein du groupe.
  
  Pour cet exemple, spécifiez les options suivantes sous Autoscaling :
  - Dans le champ Mode autoscaling, sélectionnez Off:do not autoscale.
  - Dans le champ Nombre maximal d'instances, saisissez 2.
  Si vous le souhaitez, dans la section Autoscaling de l'interface utilisateur, vous pouvez configurer le groupe d'instances de manière à ajouter ou supprimer automatiquement des instances en fonction de l'utilisation du processeur.
18. Cliquez sur Créer.

gcloud

Les instructions gcloud CLI de ce guide supposent que vous utilisez Cloud Shell ou un autre environnement avec bash installé.

Créez un modèle d'instance de VM avec le serveur HTTP à l'aide de la commande gcloud compute instance-templates create.

gcloud compute instance-templates create gil7-backendwest1-template \
  --region=REGION_A \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --tags=allow-ssh,load-balanced-backend \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

gcloud compute instance-templates create gil7-backendeast1-template \
    --region=REGION_B \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --metadata=startup-script='#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2'

Créez un groupe d'instances géré dans la zone à l'aide de la commande gcloud compute instance-groups managed create.

gcloud compute instance-groups managed create gl7-ilb-mig-a \
    --zone=ZONE_A \
    --size=2 \
    --template=gil7-backendwest1-template

gcloud compute instance-groups managed create gl7-ilb-mig-b \
    --zone=ZONE_B \
    --size=2 \
    --template=gil7-backendeast1-template

Terraform

Pour créer le modèle d'instance, utilisez la ressource google_compute_instance_template.

resource "google_compute_instance_template" "instance_template_a" {
  name         = "gil7-backendwest1-template"
  provider     = google-beta
  machine_type = "e2-small"
  region       = "us-west1"
  tags         = ["http-server"]

  network_interface {
    network    = google_compute_network.default.id
    subnetwork = google_compute_subnetwork.subnet_a.id
    access_config {
      # add external ip to fetch packages
    }
  }
  disk {
    source_image = "debian-cloud/debian-11"
    auto_delete  = true
    boot         = true
  }

  # install nginx and serve a simple web page
  metadata = {
    startup-script = <<-EOF1
      #! /bin/bash
      set -euo pipefail

      export DEBIAN_FRONTEND=noninteractive
      apt-get update
      apt-get install -y nginx-light jq

      NAME=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/hostname")
      IP=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip")
      METADATA=$(curl -f -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=True" | jq 'del(.["startup-script"])')

      cat <<EOF > /var/www/html/index.html
      <pre>
      Name: $NAME
      IP: $IP
      Metadata: $METADATA
      </pre>
      EOF
    EOF1
  }
  lifecycle {
    create_before_destroy = true
  }
}

resource "google_compute_instance_template" "instance_template_b" {
  name         = "gil7-backendeast1-template"
  provider     = google-beta
  machine_type = "e2-small"
  region       = "us-east1"
  tags         = ["http-server"]

  network_interface {
    network    = google_compute_network.default.id
    subnetwork = google_compute_subnetwork.subnet_b.id
    access_config {
      # add external ip to fetch packages
    }
  }
  disk {
    source_image = "debian-cloud/debian-11"
    auto_delete  = true
    boot         = true
  }

  # install nginx and serve a simple web page
  metadata = {
    startup-script = <<-EOF1
      #! /bin/bash
      set -euo pipefail

      export DEBIAN_FRONTEND=noninteractive
      apt-get update
      apt-get install -y nginx-light jq

      NAME=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/hostname")
      IP=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip")
      METADATA=$(curl -f -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=True" | jq 'del(.["startup-script"])')

      cat <<EOF > /var/www/html/index.html
      <pre>
      Name: $NAME
      IP: $IP
      Metadata: $METADATA
      </pre>
      EOF
    EOF1
  }
  lifecycle {
    create_before_destroy = true
  }
}

Pour créer le groupe d'instances géré, utilisez la ressource google_compute_instance_group_manager.

resource "google_compute_region_instance_group_manager" "mig_a" {
  name     = "gl7-ilb-miga"
  provider = google-beta
  region   = "us-west1"
  version {
    instance_template = google_compute_instance_template.instance_template_a.id
    name              = "primary"
  }
  base_instance_name = "vm"
  target_size        = 2
}

resource "google_compute_region_instance_group_manager" "mig_b" {
  name     = "gl7-ilb-migb"
  provider = google-beta
  region   = "us-east1"
  version {
    instance_template = google_compute_instance_template.instance_template_b.id
    name              = "primary"
  }
  base_instance_name = "vm"
  target_size        = 2
}

API

Créez le modèle d'instance avec la méthode instanceTemplates.insert, en remplaçant PROJECT_ID par votre ID de projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

{
  "name":"gil7-backendwest1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_A/subnetworks/SUBNET_A",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

Créez un groupe d'instances géré dans chaque zone à l'aide de la méthode instanceGroupManagers.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl7-ilb-mig-a",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil7-backendwest1-template",
  "baseInstanceName": "gl7-ilb-mig-b",
  "targetSize": 2
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

{
  "name":"gil7-backendeast1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_B/subnetworks/SUBNET_B",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

Créez un groupe d'instances géré dans chaque zone à l'aide de la méthode instanceGroupManagers.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl7-ilb-mig-b",
  "zone": "projects/PROJECT_ID/zones/ZONE_B",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil7-backendwest1-template",
  "baseInstanceName": "gl7-ilb-mig-b",
  "targetSize": 2
}

Configurer l'équilibreur de charge

Cet exemple vous explique comment créer les ressources suivantes pour l'équilibreur de charge d'application interne interrégional :

Une vérification d'état HTTP globale.
Un service de backend global avec les groupes d'instances gérés en tant que backend.
Un mappage d'URL. Veillez à faire référence à un mappage d'URL global pour le proxy HTTP(S) cible. Un mappage d'URL global achemine les requêtes vers un service de backend global en fonction des règles que vous définissez pour l'hôte et le chemin d'une URL entrante. Un mappage d'URL global peut être référencé par une règle de proxy cible globale.
Un certificat SSL global (pour HTTPS).
Un proxy cible mondial.
Deux règles de transfert globales avec des adresses IP régionales. Pour l'adresse IP de la règle de transfert, utilisez la plage d'adresses IP SUBNET_A ou SUBNET_B. Si vous essayez d'utiliser le sous-réseau proxy réservé, la création de la règle de transfert échoue.

Console

Démarrer la configuration

Dans Google Cloud Console, accédez à la page Équilibrage de charge.

Accéder à la page "Équilibrage de charge"
Cliquez sur Créer un équilibreur de charge.
Dans le champ Type d'équilibreur de charge, sélectionnez Équilibreur de charge d'application (HTTP/HTTPS), puis cliquez sur Suivant.
Pour Public ou interne, sélectionnez Interne, puis cliquez sur Suivant.
Pour Déploiement interrégional ou régional, sélectionnez Recommandé pour les charges de travail interrégionales, puis cliquez sur Suivant.
Cliquez sur Configurer.

Configuration de base

Saisissez un Nom pour l'équilibreur de charge.
Pour Réseau, sélectionnez NETWORK.

Configurer l'interface avec deux règles de transfert

Pour HTTP :

Cliquez sur Configuration de l'interface.

Saisissez un Nom pour la règle de transfert.
Dans la liste Région du sous-réseau, sélectionnez REGION_A.
Réserver un sous-réseau proxy réservé

Dans la liste Sous-réseau, sélectionnez SUBNET_A.
Dans la liste Adresse IP, cliquez sur Créer une adresse IP. La page Réserver une adresse IP statique interne s'affiche.

Saisissez un Nom pour l'adresse IP statique.
Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
Dans le champ Adresse IP personnalisée, saisissez 10.1.2.99.
Sélectionnez Réserver.

Cliquez sur OK.
Pour ajouter la deuxième règle de transfert, cliquez sur Ajouter une adresse IP et un port d'interface.

Saisissez un Nom pour la règle de transfert.
Dans la liste Région du sous-réseau, sélectionnez REGION_B.
Réserver un sous-réseau proxy réservé

Dans la liste Sous-réseau, sélectionnez SUBNET_B.
Dans la liste Adresse IP, cliquez sur Créer une adresse IP. La page Réserver une adresse IP statique interne s'affiche.

Saisissez un Nom pour l'adresse IP statique.
Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
Dans le champ Adresse IP personnalisée, saisissez 10.1.3.99.
Sélectionnez Réserver.

Cliquez sur OK.

Pour HTTPS :

Si vous utilisez HTTPS entre le client et l'équilibreur de charge, vous devez disposer d'une ou de plusieurs ressources de certificat SSL pour configurer le proxy. Pour créer un certificat all-regions géré par Google, consultez la documentation suivante :

Après avoir créé le certificat géré par Google, associez-le directement au proxy cible. Les mappages de certificats ne sont pas compatibles avec les équilibreurs de charge d'application internes interrégionaux.

Pour créer un certificat autogéré all-regions, consultez la documentation suivante : Déployer un certificat régional autogéré.

Cliquez sur Configuration de l'interface.

Saisissez un Nom pour la règle de transfert.
Dans le champ Protocole, sélectionnez HTTPS (includes HTTP/2).
Assurez-vous que le Port est défini sur la valeur 443.
Dans la liste Région du sous-réseau, sélectionnez REGION_A.
Réserver un sous-réseau proxy réservé

Dans la liste Sous-réseau, sélectionnez SUBNET_A.
Dans la liste Adresse IP, cliquez sur Créer une adresse IP. La page Réserver une adresse IP statique interne s'affiche.

Saisissez un Nom pour l'adresse IP statique.
Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
Dans le champ Adresse IP personnalisée, saisissez 10.1.3.99.
Sélectionnez Réserver.

Dans la section Add certificate (Ajouter un certificat), sélectionnez le certificat.
Facultatif : Pour ajouter des certificats en plus du certificat SSL principal :

Cliquez sur Ajouter un certificat.
Sélectionnez le certificat dans la liste.

Sélectionnez une règle SSL dans la liste Règle SSL. Si vous n'avez pas créé de règle SSL, une règle SSL Google Cloud par défaut est appliquée.
Cliquez sur OK.

Ajoutez la deuxième configuration d'interface :

Indiquez un nom pour la configuration de l'interface.
Dans le champ Protocole, sélectionnez HTTPS (includes HTTP/2).
Assurez-vous que le Port est défini sur la valeur 443.
Dans la liste Région du sous-réseau, sélectionnez REGION_B.
Réserver un sous-réseau proxy réservé

Dans la liste Sous-réseau, sélectionnez SUBNET_B.
Dans la liste Adresse IP, cliquez sur Créer une adresse IP. La page Réserver une adresse IP statique interne s'affiche.

Saisissez un Nom pour l'adresse IP statique.
Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
Dans le champ Adresse IP personnalisée, saisissez 10.1.3.99.
Sélectionnez Réserver.

Dans la section Add certificate (Ajouter un certificat), sélectionnez le certificat.
Facultatif : Pour ajouter des certificats en plus du certificat SSL principal :

Cliquez sur Ajouter un certificat.
Sélectionnez le certificat dans la liste.

Sélectionnez une règle SSL dans la liste Règle SSL. Si vous n'avez pas créé de règle SSL, une règle SSL Google Cloud par défaut est appliquée.
Cliquez sur OK.

Configurer le service de backend

Cliquez sur Configuration du backend.
Dans la liste Créer ou sélectionner des services de backend, cliquez sur Créer un service de backend.
Saisissez un Nom pour le service de backend.
Pour Protocole, sélectionnez HTTP.
Pour le Port nommé, saisissez http.
Dans la liste Type de backend, sélectionnez Groupe d'instances.
Dans la section Nouveau backend :

Dans la liste Groupe d'instances, sélectionnez gl4-ilb-miga dans REGION_A.
Définissez le paramètre Numéros de ports sur 80.
Cliquez sur OK.
Pour ajouter un autre backend, cliquez sur Ajouter un backend.
Dans la liste Groupe d'instances, sélectionnez gl4-ilb-migb dans REGION_B.
Définissez le paramètre Numéros de ports sur 80.
Cliquez sur OK.

Dans la section Vérification d'état, cliquez sur Créer une vérification d'état.

Dans le champ Nom, saisissez global-http-health-check.
Définissez le paramètre Protocole sur HTTP.
Définissez le paramètre Port sur 80.
Cliquez sur Enregistrer.

Configurer les règles de routage

Cliquez sur Règles de routage.
Sous Mode, sélectionnez Règle d'hôte et de chemin d'accès simple.
Assurez-vous qu'il n'existe qu'un seul service de backend pour tous les hôtes et chemins sans correspondance.

Vérifier la configuration

Cliquez sur Vérifier et finaliser.
Vérifiez les paramètres de configuration de votre équilibreur de charge.
Cliquez sur Créer.

gcloud

Définissez la vérification d'état HTTP à l'aide de la commande gcloud compute health-checks create http.
```
gcloud compute health-checks create http global-http-health-check \
   --use-serving-port \
   --global
```

Définissez le service de backend avec la commande gcloud compute backend-services create.

gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --enable-logging \
  --logging-sample-rate=1.0 \
  --health-checks=global-http-health-check \
  --global-health-checks \
  --global

Ajoutez des backends au service de backend à l'aide de la commande gcloud compute backend-services add-backend.

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --balancing-mode=UTILIZATION \
  --instance-group=gl7-ilb-mig-a \
  --instance-group-zone=ZONE_A \
  --global

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --balancing-mode=UTILIZATION \
  --instance-group=gl7-ilb-mig-b \
  --instance-group-zone=ZONE_B \
  --global

Créez le mappage d'URL à l'aide de la commande gcloud compute url-maps create.

gcloud compute url-maps create gl7-gilb-url-map \
  --default-service=BACKEND_SERVICE_NAME \
  --global

Créez le proxy cible.

Pour HTTP :

Créez le proxy cible à l'aide de la commande gcloud compute target-http-proxies create.
```
gcloud compute target-http-proxies create gil7-http-proxy \
  --url-map=gl7-gilb-url-map \
  --global
```
Pour HTTPS :

Pour créer un certificat géré par Google, consultez la documentation suivante :
- Créer un certificat géré par Google et émis par votre instance Certificate Authority Service.
- Créer un certificat géré par Google avec une autorisation DNS.
Après avoir créé le certificat géré par Google, associez-le directement au proxy cible. Les mappages de certificats ne sont pas compatibles avec les équilibreurs de charge d'application internes interrégionaux.

Pour créer un certificat autogéré, consultez la documentation suivante :
- Créer une clé privée et un certificat
Attribuez vos chemins de fichiers à des noms de variables.
```
export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
```
```
export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE
```
Créez un certificat SSL toutes régions à l'aide de la commande gcloud beta certificate-manager certificates create.
```
gcloud certificate-manager certificates create gilb-certificate \
  --private-key-file=$LB_PRIVATE_KEY \
  --certificate-file=$LB_CERT \
  --scope=all-regions
```
Utilisez le certificat SSL pour créer le proxy cible à l'aide de la commande gcloud compute target-https-proxies create.
```
gcloud compute target-https-proxies create gil7-https-proxy \
  --url-map=gl7-gilb-url-map \
  --certificate-manager-certificates=gilb-certificate \
  --global
```

Créez deux règles de transfert, l'une avec une adresse IP virtuelle 10.1.2.99 dans la région REGION_B et l'autre avec une adresse IP virtuelle 10.1.3.99 dans la région REGION_A. Pour plus d'informations, consultez la page Réserver une adresse IPv4 interne statique.

Pour les réseaux personnalisés, vous devez faire référence au sous-réseau dans la règle de transfert. Notez qu'il s'agit du sous-réseau de VM et non du sous-réseau proxy.

Pour HTTP :

Utilisez la commande gcloud compute forwarding-rules create avec les options appropriées.

gcloud compute forwarding-rules create FWRULE_A \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

gcloud compute forwarding-rules create FWRULE_B \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

Pour HTTPS :

Utilisez la commande gcloud compute forwarding-rules create avec les options appropriées.

gcloud compute forwarding-rules create FWRULE_A \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

gcloud compute forwarding-rules create FWRULE_B \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

Terraform

Pour créer la vérification d'état, utilisez la ressource google_compute_health_check.

resource "google_compute_health_check" "default" {
  provider = google-beta
  name     = "global-http-health-check"
  http_health_check {
    port_specification = "USE_SERVING_PORT"
  }
}

Pour créer le service de backend, utilisez la ressource google_compute_backend_service.

resource "google_compute_backend_service" "default" {
  name                  = "gl7-gilb-backend-service"
  provider              = google-beta
  protocol              = "HTTP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  timeout_sec           = 10
  health_checks         = [google_compute_health_check.default.id]
  backend {
    group           = google_compute_region_instance_group_manager.mig_a.instance_group
    balancing_mode  = "UTILIZATION"
    capacity_scaler = 1.0
  }
  backend {
    group           = google_compute_region_instance_group_manager.mig_b.instance_group
    balancing_mode  = "UTILIZATION"
    capacity_scaler = 1.0
  }
}

Pour créer le mappage d'URL, utilisez la ressource google_compute_url_map.

resource "google_compute_url_map" "default" {
  name            = "gl7-gilb-url-map"
  provider        = google-beta
  default_service = google_compute_backend_service.default.id
}

Pour créer le proxy HTTP cible, utilisez la ressource google_compute_target_http_proxy.

resource "google_compute_target_http_proxy" "default" {
  name     = "gil7target-http-proxy"
  provider = google-beta
  url_map  = google_compute_url_map.default.id
}

Pour créer la règle de transfert, utilisez la ressource google_compute_forwarding_rule.

resource "google_compute_global_forwarding_rule" "fwd_rule_a" {
  provider              = google-beta
  depends_on            = [google_compute_subnetwork.proxy_subnet_a]
  ip_address            = "10.1.2.99"
  ip_protocol           = "TCP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  name                  = "gil7forwarding-rule-a"
  network               = google_compute_network.default.id
  port_range            = "80"
  target                = google_compute_target_http_proxy.default.id
  subnetwork            = google_compute_subnetwork.subnet_a.id
}

resource "google_compute_global_forwarding_rule" "fwd_rule_b" {
  provider              = google-beta
  depends_on            = [google_compute_subnetwork.proxy_subnet_b]
  ip_address            = "10.1.3.99"
  ip_protocol           = "TCP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  name                  = "gil7forwarding-rule-b"
  network               = google_compute_network.default.id
  port_range            = "80"
  target                = google_compute_target_http_proxy.default.id
  subnetwork            = google_compute_subnetwork.subnet_b.id
}

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

API

Créez la vérification de l'état en envoyant une requête POST à la méthode healthChecks.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks

{
"name": "global-http-health-check",
"type": "HTTP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

Créez le service de backend global en envoyant une requête POST à la méthode backendServices.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

{
"name": "BACKEND_SERVICE_NAME",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7-ilb-mig-a",
    "balancingMode": "UTILIZATION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7-ilb-mig-b",
    "balancingMode": "UTILIZATION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/global/healthChecks/global-http-health-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Créez le mappage d'URL en envoyant une requête POST à la méthode urlMaps.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME"
}

Pour HTTP :

Créez le proxy HTTP cible en envoyant une requête POST à la méthode targetHttpProxies.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map"
}

Créez la règle de transfert en envoyant une requête POST à la méthode forwardingRules.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "FWRULE_A",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Pour HTTPS :

Lisez les fichiers de certificat et de clé privée, puis créez le certificat SSL. L'exemple suivant montre comment effectuer cette opération avec Python.

from pathlib import Path
from pprint import pprint
from typing import Union

from googleapiclient import discovery


def create_regional_certificate(
    project_id: str,
    region: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample.",
) -> dict:
    """
    Create a regional SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        region: name of the region you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.

        Returns:
        Dictionary with information about the new regional SSL self-signed certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.regionSslCertificates().insert(
        project=project_id, region=region, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)

    return response

Créez le proxy HTTPS cible en envoyant une requête POST à la méthode targetHttpsProxies.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"sslCertificates": /projects/PROJECT_ID/global/sslCertificates/SSL_CERT_NAME
}

Créez la règle de transfert en envoyant une requête POST à la méthode globalForwardingRules.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "FWRULE_A",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "FWRULE_B",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Tester l'équilibreur de charge

Créer une instance de VM pour tester la connectivité

Créer une VM cliente :

gcloud compute instances create l7-ilb-client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_A \
    --zone=ZONE_A \
    --tags=allow-ssh

gcloud compute instances create l7-ilb-client-b \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --zone=ZONE_B \
    --tags=allow-ssh

Utilisez SSH pour vous connecter à chaque instance cliente.

gcloud compute ssh l7-ilb-client-a --zone=ZONE_A

gcloud compute ssh l7-ilb-client-b --zone=ZONE_B

Vérifiez que l'adresse IP diffuse son nom d'hôte.
- Vérifiez que la VM cliente peut atteindre les deux adresses IP. La commande renvoie le nom de la VM de backend qui a diffusé la requête :
```
curl 10.1.2.99
```
```
curl 10.1.3.99
```
  Pour le test HTTPS, remplacez curl par la ligne de commande suivante :
```
curl -k 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443
```
```
curl -k 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443
```
  L'option -k indique à curl d'ignorer l'étape de validation du certificat.
- Facultatif : Utilisez l'enregistrement DNS configuré pour résoudre l'adresse IP la plus proche de la VM cliente. Par exemple, DNS_NAME peut être service.example.com.
```
curl DNS_NAME
```

Exécuter 100 requêtes et vérifier que leur charge est équilibrée

Pour HTTP :

  {
    RESULTS=
    for i in {1..100}
    do
        RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.3.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

Pour HTTPS :

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

  {
    RESULTS=
    for i in {1..100}
    do
       RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

Tester le basculement

Vérifiez le basculement vers les backends de la région REGION_A lorsque les backends de REGION_B sont non opérationnels ou inaccessibles. Pour simuler un basculement, supprimez tous les backends de REGION_B :
```
gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \
   --balancing-mode=UTILIZATION \
   --instance-group=gl7-ilb-mig-b \
   --instance-group-zone=ZONE_B
```
Connectez-vous à une VM cliente dans REGION_B en utilisant SSH.
```
gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B
```

Envoyez des requêtes à l'adresse IP faisant l'objet d'un équilibrage de charge dans la région REGION_B. Le résultat de la commande affiche les réponses des VM de backend dans REGION_A :

{
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.3.99: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Options de configuration supplémentaires

Cette section développe l'exemple de configuration et propose d'autres options de configuration. Toutes les tâches décrites ici sont facultatives. Vous pouvez les exécuter dans n'importe quel ordre.

Activer l'affinité de session

Ces procédures vous montrent comment mettre à jour un service de backend pour l'exemple d'équilibreur de charge d'application interne régional ou l'équilibreur de charge d'application interne interrégional afin que le service de backend utilise l'affinité basée sur les cookies générés, l'affinité de champ d'en-tête ou l'affinité de cookie HTTP.

Lorsque l'affinité basée sur les cookies générés est activée, l'équilibreur de charge émet un cookie lors de la première requête. Pour chaque requête suivante présentant le même cookie, l'équilibreur de charge dirige celle-ci vers les mêmes instances de machine virtuelle (VM) ou point de terminaison de backend. Dans cet exemple, le cookie est nommé GCILB.

Lorsque l'affinité du champ d'en-tête est activée, l'équilibreur de charge achemine les requêtes vers les VM ou les points de terminaison de backend dans un groupe de points de terminaison du réseau (NEG) en fonction de la valeur de l'en-tête HTTP nommé dans l'option --custom-request-header. L'affinité du champ d'en-tête n'est valide que si la stratégie de localité d'équilibrage de charge est RING_HASH ou MAGLEV et que le hachage cohérent du service de backend spécifie le nom de l'en-tête HTTP.

Lorsque l'affinité basée sur les cookies HTTP est activée, l'équilibreur de charge achemine les requêtes vers les VM ou les points de terminaison de backend dans un NEG, en fonction d'un cookie HTTP nommé dans l'option HTTP_COOKIE avec l'option --affinity-cookie-ttl facultative. Si le client ne fournit pas le cookie dans sa requête HTTP, le proxy génère le cookie et le renvoie au client dans un en-tête Set-Cookie. L'affinité basée sur les cookies HTTP n'est valide que si la règle de localité d'équilibrage de charge est RING_HASH ou MAGLEV et que le hachage cohérent du service de backend spécifie le cookie HTTP.

Console

Pour activer ou modifier l'affinité de session pour un service de backend :

Dans Google Cloud Console, accédez à la page Équilibrage de charge.

Accéder à la page "Équilibrage de charge"
Cliquez sur Backends.
Cliquez sur gil7-backend-service (le nom du service de backend que vous avez créé pour cet exemple), puis sur Modifier.
Sur la page Détails du service backend, cliquez sur Configuration avancée.
Sous Affinité de session, sélectionnez le type d'affinité de session souhaité.
Cliquez sur Mettre à jour.

gcloud

Utilisez les commandes Google Cloud CLI suivantes pour mettre à jour le service de backend vers différents types d'affinité de session :

    gcloud compute backend-services update gil7-backend-service \
        --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP] \
        --global

API

Pour définir l'affinité de session, envoyez une requête `PATCH` à la méthode backendServices/patch.

    PATCH https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/gil7-backend-service
    {
    "sessionAffinity": ["GENERATED_COOKIE" | "HEADER_FIELD" | "HTTP_COOKIE" | "CLIENT_IP" ]
    }

Restreindre les clients autorisés à envoyer du trafic vers l'équilibreur de charge

Vous pouvez empêcher les clients de se connecter à une adresse IP virtuelle de règle de transfert d'équilibreur de charge d'application interne en configurant des règles de pare-feu de sortie sur ces clients. Définissez ces règles de pare-feu sur des VM clientes spécifiques en fonction de comptes de service ou de tags.

Vous ne pouvez pas utiliser de règles de pare-feu pour limiter le trafic entrant à certaines adresses IP virtuelles de règle de transfert de l'équilibreur de charge d'application interne. Tout client situé sur le même réseau VPC et dans la même région que l'adresse IP virtuelle de règle de transfert peut généralement envoyer du trafic à celle-ci.

De plus, toutes les requêtes adressées aux backends proviennent de proxys qui utilisent des adresses IP comprises dans la plage de sous-réseau proxy réservé. Il est impossible de créer des règles de pare-feu qui autorisent ou interdisent le trafic entrant sur ces backends en fonction de l'adresse IP virtuelle de la règle de transfert utilisée par un client.

Voici quelques exemples d'utilisation des règles de pare-feu de sortie pour limiter le trafic à l'adresse IP virtuelle de la règle de transfert de l'équilibreur de charge.

Console

Pour identifier les VM clientes, ajoutez un tag aux VM spécifiques que vous souhaitez restreindre. Ces tags sont utilisés pour associer les règles de pare-feu aux VM clientes taguées. Ajoutez ensuite le tag au champ TARGET_TAG dans les étapes suivantes.

Pour cela, vous pouvez utiliser une seule règle de pare-feu ou plusieurs règles.

Une seule règle de pare-feu de sortie

Vous pouvez configurer une règle de pare-feu de sortie pour refuser tout le trafic sortant des VM clientes taguées à destination de l'adresse IP virtuelle d'un équilibreur de charge.

Dans Google Cloud Console, accédez à la page Règles de pare-feu.

Accéder aux règles de pare-feu
Cliquez sur Créer une règle de pare-feu pour créer la règle permettant de refuser le trafic sortant des VM clientes taguées à destination de l'adresse IP virtuelle d'un équilibreur de charge.
- Nom : fr-deny-access
- Réseau : lb-network
- Priorité : 100
- Sens du trafic : Sortie
- Action en cas de correspondance : Refuser
- Cibles : Tags cibles spécifiés
- Tags cibles : TARGET_TAG
- Filtre de destination : Plages d'adresses IP
- Plages d'adresses IP de destination : 10.1.2.99
- Protocoles et ports :
  - Choisissez Protocoles et ports spécifiés.
  - Cochez la case tcp, puis saisissez 80 pour le numéro de port.
Cliquez sur Créer.

Plusieurs règles de pare-feu de sortie

Une approche plus adaptable repose sur la définition de deux règles. Une règle par défaut et à faible priorité, qui empêche tous les clients d'accéder à l'adresse IP virtuelle de l'équilibreur de charge. Une seconde règle de priorité plus élevée, qui permet à un sous-ensemble de clients tagués d'accéder à l'adresse IP virtuelle de l'équilibreur de charge. Seules les VM taguées peuvent accéder à l'adresse IP virtuelle.

Dans Google Cloud Console, accédez à la page Règles de pare-feu.

Accéder aux règles de pare-feu
Cliquez sur Créer une règle de pare-feu pour créer la règle de faible priorité servant à refuser l'accès par défaut :
- Nom : fr-deny-all-access-low-priority
- Réseau : lb-network
- Priorité : 200
- Sens du trafic : Sortie
- Action en cas de correspondance : Refuser
- Cibles : Tags cibles spécifiés
- Tags cibles : TARGET_TAG
- Filtre de destination : Plages d'adresses IP
- Plages d'adresses IP de destination : 10.1.2.99
- Protocoles et ports :
  - Choisissez Protocoles et ports spécifiés.
  - Cochez la case TCP, puis saisissez 80 pour le numéro de port.
Cliquez sur Créer.
Cliquez sur Créer une règle de pare-feu pour créer la règle de priorité supérieure servant à autoriser le trafic en provenance de certaines instances taguées.
- Nom : fr-allow-some-access-high-priority
- Réseau : lb-network
- Priorité : 100
- Sens du trafic : Sortie
- Action en cas de correspondance : autoriser
- Cibles : Tags cibles spécifiés
- Tags cibles : TARGET_TAG
- Filtre de destination : Plages d'adresses IP
- Plages d'adresses IP de destination : 10.1.2.99
- Protocoles et ports :
  - Choisissez Protocoles et ports spécifiés.
  - Cochez la case TCP, puis saisissez 80 pour le numéro de port.
Cliquez sur Créer.

gcloud

Pour identifier les VM clientes, ajoutez un tag aux VM spécifiques que vous souhaitez restreindre. Ensuite, ajoutez le tag au champ TARGET_TAG dans les étapes requises.

Pour cela, vous pouvez utiliser une seule règle de pare-feu ou plusieurs règles.

Une seule règle de pare-feu de sortie

Vous pouvez configurer une règle de pare-feu de sortie pour refuser tout le trafic sortant des VM clientes taguées à destination de l'adresse IP virtuelle d'un équilibreur de charge.

gcloud compute firewall-rules create fr-deny-access \
  --network=lb-network \
  --action=deny \
  --direction=egress \
  --rules=tcp \
  --priority=100 \
  --destination-ranges=10.1.2.99 \
  --target-tags=TARGET_TAG

Plusieurs règles de pare-feu de sortie

Une approche plus évolutive consiste à définir deux règles : une règle par défaut et à faible priorité qui empêche tous les clients d'accéder à l'adresse IP virtuelle de l'équilibreur de charge, et une seconde règle de priorité plus élevée qui permet à un sous-ensemble de clients tagués d'accéder à l'adresse IP virtuelle de l'équilibreur de charge. Seules les VM taguées peuvent accéder à l'adresse IP virtuelle.

Créez la règle de faible priorité :

gcloud compute firewall-rules create fr-deny-all-access-low-priority \
  --network=lb-network \
  --action=deny \
  --direction=egress \
  --rules=tcp \
  --priority=200 \
  --destination-ranges=10.1.2.99

Créez la règle de priorité supérieure :

gcloud compute firewall-rules create fr-allow-some-access-high-priority \
  --network=lb-network \
  --action=allow \
  --direction=egress \
  --rules=tcp \
  --priority=100 \
  --destination-ranges=10.1.2.99 \
  --target-tags=TARGET_TAG

Pour contrôler l'accès à l'aide de comptes de service au lieu de tags, utilisez l'option --target-service-accounts au lieu de l'option --target-tags lorsque vous créez les règles de pare-feu.

Adaptez l'accès restreint aux backends d'équilibreur de charge d'application internes en fonction des sous-réseaux.

Gérer des règles de pare-feu distinctes ou ajouter aux règles existantes de nouvelles adresses IP à équilibrage de charge, comme décrit dans la section précédente, devient peu pratique à mesure que le nombre de règles de transfert augmente. Un moyen d'éviter cela consiste à allouer des adresses IP de règle de transfert à partir d'un sous-réseau réservé. Le trafic provenant d'instances ou de comptes de service avec tag peut être autorisé ou bloqué en utilisant le sous-réseau réservé comme plage de destination pour les règles de pare-feu. Cela vous permet de contrôler efficacement l'accès à un groupe d'adresses IP virtuelles de règles de transfert sans avoir à maintenir des règles de sortie de pare-feu par adresse IP virtuelle.

Voici les principales étapes à suivre pour configurer cela, en supposant que vous créez séparément toutes les autres ressources d'équilibreur de charge requises.

gcloud

Créez un sous-réseau régional qui servira à allouer des adresses IP à équilibrage de charge pour les règles de transfert :

gcloud compute networks subnets create l7-ilb-restricted-subnet \
  --network=lb-network \
  --region=us-west1 \
  --range=10.127.0.0/24

Créez une règle de transfert qui utilise une adresse provenant du sous-réseau. L'exemple suivant utilise l'adresse 10.127.0.1 du sous-réseau créé à l'étape précédente.

gcloud compute forwarding-rules create l7-ilb-forwarding-rule-restricted \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=lb-network \
  --subnet=l7-ilb-restricted-subnet \
  --address=10.127.0.1 \
  --ports=80 \
  --global \
  --target-http-proxy=gil7-http-proxy

Créez une règle de pare-feu pour limiter le trafic destiné aux adresses IP des plages du sous-réseau de la règle de transfert (l7-ilb-restricted-subnet) :

gcloud compute firewall-rules create restrict-traffic-to-subnet \
  --network=lb-network \
  --action=deny \
  --direction=egress \
  --rules=tcp:80 \
  --priority=100 \
  --destination-ranges=10.127.0.0/24 \
  --target-tags=TARGET_TAG

Utiliser la même adresse IP entre plusieurs règles de transfert internes

Pour que plusieurs règles de transfert internes partagent la même adresse IP interne, vous devez réserver l'adresse IP et définir son option --purpose sur SHARED_LOADBALANCER_VIP.

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP

Si vous devez rediriger le trafic HTTP vers HTTPS, vous pouvez créer deux règles de transfert avec une adresse IP commune. Pour en savoir plus, consultez la page Configurer la redirection HTTP vers HTTPS pour les équilibreurs de charge d'application internes.

Configurer des règles de routage DNS

Si vos clients se trouvent dans plusieurs régions, vous pouvez rendre votre équilibreur de charge d'application interne interrégional accessible par des adresses IP virtuelles dans ces régions. Cette configuration multirégionale minimise la latence et les coûts liés au transit sur le réseau. En outre, il vous permet de configurer une solution d'équilibrage de charge mondiale, basée sur DNS, qui offre une résilience en cas de pannes régionales. Pour en savoir plus, consultez la page Gérer les règles de routage DNS et les vérifications d'état.

gcloud

Pour créer une entrée DNS avec une valeur TTL de 30 secondes, utilisez la commande gcloud dns record-sets create.

gcloud dns record-sets create DNS_ENTRY --ttl="30" \
  --type="A" --zone="service-zone" \
  --routing-policy-type="GEO" \
  --routing-policy-data="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \
  --enable-health-checking

Remplacez les éléments suivants :

DNS_ENTRY : nom DNS ou nom de domaine du jeu d'enregistrements
Par exemple : service.example.com
REGION_A et REGION_B : régions dans lesquelles vous avez configuré l'équilibreur de charge.

API

Créez l'enregistrement DNS en envoyant une requête POST à la méthode ResourceRecordSets.create. Remplacez PROJECT_ID par l'ID du projet.

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets
{
  "name": "DNS_ENTRY",
  "type": "A",
  "ttl": 30,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "REGION_A",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION_B",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS_B",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}

Mettre à jour le délai d'expiration du message keepalive HTTP client

L'équilibreur de charge créé lors des étapes précédentes a été configuré avec une valeur par défaut pour le délai d'expiration du message keepalive HTTP du client.

Pour mettre à jour le délai d'expiration du message HTTP du client, suivez les instructions ci-dessous.

Console

Dans la console Google Cloud, accédez à la page Équilibrage de charge.

Accédez à la page "Équilibrage de charge".
Cliquez sur le nom de l'équilibreur de charge que vous souhaitez modifier.
Cliquez sur Modifier ().
Cliquez sur Configuration de l'interface.
Développez Fonctionnalités avancées. Dans le champ Délai avant expiration du message keepalive HTTP, saisissez une valeur de délai avant expiration.
Cliquez sur Mettre à jour.
Pour vérifier vos modifications, cliquez sur Vérification et finalisation, puis sur Mettre à jour.

gcloud

Pour un équilibreur de charge HTTP, mettez à jour le proxy HTTP cible à l'aide de la commande gcloud compute target-http-proxies update :

    gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global

Pour un équilibreur de charge HTTPS, mettez à jour le proxy HTTPS cible à l'aide de la commande gcloud compute target-https-proxies update :

    gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global

Remplacez les éléments suivants :

TARGET_HTTP_PROXY_NAME: nom du proxy HTTP cible.
TARGET_HTTPS_PROXY_NAME : nom du proxy HTTPS cible.
HTTP_KEEP_ALIVE_TIMEOUT_SEC: valeur du délai avant expiration du message keepalive HTTP comprise entre 5 et 600 secondes.

Activer la détection des anomalies

Vous pouvez activer la détection des anomalies sur les services de backend globaux pour identifier les NEG sans serveur non opérationnels et réduire le nombre de requêtes envoyées aux NEG sans serveur non opérationnels.

La détection des anomalies est activée sur le service de backend à l'aide de l'une des méthodes suivantes :

La méthode consecutiveErrors (outlierDetection.consecutiveErrors), dans laquelle un code d'état HTTP de la série 5xx est considéré comme une erreur.
La méthode consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), dans laquelle seuls les codes d'état HTTP 502, 503 et 504 sont considérés comme des erreurs.

Procédez comme suit pour activer la détection des anomalies pour un service de backend existant. Sachez que même après l'activation de la détection des anomalies, certaines requêtes peuvent être envoyées au service non opérationnel et renvoyer un code d'état 5xx aux clients. Pour réduire davantage le taux d'erreur, vous pouvez configurer des valeurs plus agressives pour les paramètres de détection des anomalies. Pour en savoir plus, consultez le champ outlierDetection.

Console

Dans Google Cloud Console, accédez à la page Équilibrage de charge.

Accéder à la page "Équilibrage de charge"
Cliquez sur le nom de l'équilibreur de charge dont vous souhaitez modifier le service de backend.
Sur la page Détails de l'équilibreur de charge, cliquez sur Modifier.
Sur la page Modifier l'équilibreur de charge d'application interne interrégional, cliquez sur Configuration du backend.
Sur la page Configuration du backend, cliquez sur le bouton Modifier correspondant au service de backend que vous souhaitez modifier.
Faites défiler la page vers le bas et développez la section Configurations avancées.
Dans la section Détection des anomalies, cochez la case Activer.

Cliquez sur Modifier pour configurer la détection des anomalies.

Vérifiez que les options suivantes sont configurées avec ces valeurs :

Propriété	Valeur
Erreurs consécutives	5
Intervalle	1000
Durée d'éjection de base	30000
Pourcentage maximal d'éjection	50
Éjection pour erreurs consécutives	100

Dans cet exemple, l'analyse de détection des anomalies s'exécute toutes les secondes. Si le nombre de codes d'état HTTP 5xx consécutifs reçus par un proxy Envoy est supérieur ou égal à cinq, le point de terminaison de backend est exclu du pool d'équilibrage de charge de ce proxy Envoy pendant 30 secondes. Lorsque le pourcentage d'application est défini sur 100 %, le service de backend exclut les points de terminaison non opérationnels des pools d'équilibrage de charge de ces proxys Envoy spécifiques à chaque exécution de l'analyse de détection des anomalies. Si les conditions d'exclusion sont remplies, jusqu'à 50 % des points de terminaison de backend du pool d'équilibrage de charge peuvent être exclus.

Cliquez sur Enregistrer.
Pour mettre à jour le service de backend, cliquez sur Mettre à jour.
Pour mettre à jour l'équilibreur de charge, cliquez sur Mettre à jour sur la page Modifier l'équilibreur de charge d'application interne interrégional.

gcloud

Exportez le service de backend dans un fichier YAML.

gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME.yaml --global

Remplacez BACKEND_SERVICE_NAME par le nom du service de backend.

Modifiez la configuration YAML du service de backend pour ajouter les champs de détection des anomalies, comme indiqué dans la configuration YAML suivante, dans la section outlierDetection :

Dans cet exemple, l'analyse de détection des anomalies s'exécute toutes les secondes. Si le nombre de codes d'état HTTP 5xx consécutifs reçus par un proxy Envoy est supérieur ou égal à cinq, le point de terminaison de backend est exclu du pool d'équilibrage de charge de ce proxy Envoy pendant 30 secondes. Lorsque le pourcentage d'application est défini sur 100 %, le service de backend exclut les points de terminaison non opérationnels des pools d'équilibrage de charge de ces proxys Envoy spécifiques à chaque exécution de l'analyse de détection des anomalies. Si les conditions d'exclusion sont remplies, jusqu'à 50 % des points de terminaison de backend du pool d'équilibrage de charge peuvent être exclus.
```
name: BACKEND_SERVICE_NAME
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
outlierDetection:
  baseEjectionTime:
    nanos: 0
    seconds: 30
  consecutiveErrors: 5
  enforcingConsecutiveErrors: 100
  interval:
    nanos: 0
    seconds: 1
  maxEjectionPercent: 50
port: 80
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
sessionAffinity: NONE
timeoutSec: 30
...
```
Remplacez les éléments suivants :
- BACKEND_SERVICE_NAME : nom du service de backend.
- PROJECT_ID : ID de votre projet
- REGION_A et REGION_B : régions dans lesquelles l'équilibreur de charge a été configuré.
- SERVERLESS_NEG_NAME : nom du premier NEG sans serveur.
- SERVERLESS_NEG_NAME_2 : nom du deuxième NEG sans serveur.
Mettez à jour le service de backend en important la dernière configuration.
```
gcloud compute backend-services import BACKEND_SERVICE_NAME \
  --source=BACKEND_SERVICE_NAME.yaml --global
```
La détection des anomalies est désormais activée sur le service de backend.

Configurez un équilibreur de charge d'application interne interrégional avec des backends de groupes d'instances de VM.

Avant de commencer

Configurer une ressource de certificat SSL

Autorisations

Vue d'ensemble de la configuration

Configurer le réseau et les sous-réseaux

Configurer les sous-réseaux backend

Console

gcloud

Terraform

API

Configurer le sous-réseau proxy réservé

Console

gcloud

Terraform

API

Configurer des règles de pare-feu

Console

gcloud

Terraform

API

Créer un groupe d'instances géré

Console

gcloud

Terraform

API

Configurer l'équilibreur de charge

Console

Démarrer la configuration

gcloud

Terraform

API

Tester l'équilibreur de charge

Créer une instance de VM pour tester la connectivité

Exécuter 100 requêtes et vérifier que leur charge est équilibrée

Tester le basculement

Options de configuration supplémentaires

Activer l'affinité de session

Console

gcloud

API

Restreindre les clients autorisés à envoyer du trafic vers l'équilibreur de charge

Console

Une seule règle de pare-feu de sortie

Plusieurs règles de pare-feu de sortie

gcloud

Une seule règle de pare-feu de sortie

Plusieurs règles de pare-feu de sortie

Adaptez l'accès restreint aux backends d'équilibreur de charge d'application internes en fonction des sous-réseaux.

gcloud

Utiliser la même adresse IP entre plusieurs règles de transfert internes

gcloud

Configurer des règles de routage DNS

gcloud

API

Mettre à jour le délai d'expiration du message keepalive HTTP client

Console

gcloud

Activer la détection des anomalies

Console

gcloud

Étape suivante