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

Atelier de programmation sur l'équilibreur de charge HTTP externe avec gestion avancée du trafic (Envoy)

1. Introduction

Bienvenue dans l'atelier de programmation sur l'équilibrage de charge HTTPs externe avec gestion avancée du trafic (Envoy).

La dernière version de l'équilibreur de charge HTTP(S) externe avec gestion avancée du trafic contient toutes les fonctionnalités de notre équilibreur de charge HTTP(S) externe global classique existant, mais elle comporte une liste de fonctionnalités de gestion avancée du trafic qui ne cesse de s'allonger. Certaines de ces fonctionnalités sont nouvelles pour nos équilibreurs de charge, tandis que d'autres fournissent des fonctionnalités améliorées à des fonctionnalités existantes. Voici une liste partielle de ces fonctionnalités:

Points abordés

Configurer un groupe d'instances géré, ainsi que les règles de VPC et de pare-feu associées
Utiliser les fonctionnalités avancées de gestion du trafic du nouvel équilibreur de charge
Comment vérifier que les fonctionnalités avancées de gestion du trafic fonctionnent comme prévu

Prérequis

Connaissances de base sur la mise en réseau et le protocole HTTP
Connaissances de base de la ligne de commande Unix/Linux

Topologie des ateliers de programmation et cas d'utilisation

Figure 1 : Topologie de routage de l'équilibreur de charge HTTP

Au cours de cet atelier de programmation, vous allez configurer trois groupes d'instances gérés, à savoir "Est", "Ouest" et "Centre". Vous allez créer un équilibreur de charge HTTPS externe global. L'équilibreur de charge utilisera plusieurs fonctionnalités de la liste des capacités avancées compatibles avec l'équilibreur de charge basé sur Envoy. Une fois le déploiement terminé, vous générerez une charge simulée et vérifierez que les configurations que vous avez définies fonctionnent correctement.

2. Préparation

Configuration de l'environnement au rythme de chacun

Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)

Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères qui n'est pas utilisée par les API Google, et que vous pouvez modifier à tout moment.
L'ID du projet doit être unique sur l'ensemble des projets Google Cloud et doit être immuable (vous ne pouvez pas le modifier une fois que vous l'avez défini). Cloud Console génère automatiquement une chaîne unique dont la composition importe peu, en général. Dans la plupart des ateliers de programmation, vous devrez référencer l'ID du projet (généralement identifié comme PROJECT_ID), donc s'il ne vous convient pas, générez-en un autre au hasard ou définissez le vôtre, puis vérifiez s'il est disponible. Il est ensuite "gelé" une fois le projet créé.
La troisième valeur est le numéro de projet, utilisé par certaines API. Pour en savoir plus sur ces trois valeurs, consultez la documentation.

Vous devez ensuite activer la facturation dans Cloud Console afin d'utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour arrêter les ressources afin d'éviter qu'elles ne vous soient facturées après ce tutoriel, suivez les instructions de nettoyage indiquées à la fin de l'atelier. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai gratuit pour bénéficier d'un crédit de 300 $.

Démarrer Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Depuis la console GCP, cliquez sur l'icône Cloud Shell de la barre d'outils située dans l'angle supérieur droit :

Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez réaliser toutes les activités de cet atelier dans un simple navigateur.

Avant de commencer

Dans Cloud Shell, assurez-vous que l'ID de votre projet est configuré.

gcloud config list project

gcloud config set project [NOM-DE-VOTRE-PROJET]

PROJECT_ID=[YOUR-PROJECT-NAME]

echo $PROJECT_ID

Activer les API

Activer tous les services nécessaires

gcloud services enable compute.googleapis.com
gcloud services enable logging.googleapis.com
gcloud services enable monitoring.googleapis.com

3. Créer le réseau VPC

Créer un réseau VPC

Depuis Cloud Shell

gcloud compute networks create httplbs --subnet-mode=auto

Sortie

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/httplbs].
NAME: httplbs
SUBNET_MODE: AUTO
BGP_ROUTING_MODE: REGIONAL
IPV4_RANGE:
GATEWAY_IPV4:

Créer des règles de pare-feu VPC

Après avoir créé le VPC, vous allez maintenant créer des règles de pare-feu. La règle de pare-feu permettra d'autoriser toutes les adresses IP à accéder à l'adresse IP externe du site Web de l'application de test sur le port 80 pour le trafic HTTP.

Depuis Cloud Shell

gcloud compute firewall-rules create httplb-allow-http-rule \
--allow tcp:80 \
--network httplbs \
--source-ranges 0.0.0.0/0 \
--priority 700

Sortie

Creating firewall...working..Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls/httplb-allow-http-rule].
Creating firewall...done.
NAME: httplb-allow-http-rule
NETWORK: httplbs
DIRECTION: INGRESS
PRIORITY: 700
ALLOW: tcp:80
DENY:
DISABLED: False

4. Configurer les groupes d'instances gérés

Vous devez configurer des groupes d'instances gérés incluant les formats des ressources backend utilisées par l'équilibreur de charge HTTP. Nous allons commencer par créer des modèles d'instances qui définissent la configuration des VM à créer pour chaque région. Ensuite, pour un backend dans chaque région, nous allons créer un groupe d'instances géré qui référence un modèle d'instance.

Les groupes d'instances gérés peuvent avoir un niveau d'accès zonal ou régional. Dans cet atelier, nous allons créer trois groupes d'instances gérés régionaux, un dans us-east1, un dans us-west1 et un dans us-central1.

Dans cette section, vous pouvez voir un script de démarrage précréé qui sera référencé lors de la création de l'instance. Ce script de démarrage installe et active des fonctionnalités de serveur Web que nous allons utiliser pour simuler une application Web. N'hésitez pas à consulter ce script.

Créer les modèles d'instance Est, Ouest et Centre

La première étape consiste à créer le modèle d'instance us-east-1.

Depuis Cloud Shell

gcloud compute instance-templates create us-east1-template \
   --region=us-east1 \
   --network=httplbs \
   --tags=http-server, \
   --image-family=debian-9 \
   --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'

Sortie

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-east1-template].
NAME: us-east1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:02:37.511-08:00

L'étape suivante consiste à créer le modèle d'instance us-west-1.

Depuis Cloud Shell

gcloud compute instance-templates create us-west1-template \
   --region=us-west1 \
   --network=httplbs \
   --tags=http-server, \
   --image-family=debian-9 \
   --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'

Sortie

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-west1-template].
NAME: us-west1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:03:08.577-08:00

L'étape suivante consiste à créer le modèle d'instance us-central-1.

Depuis Cloud Shell

gcloud compute instance-templates create us-central1-template \
   --region=us-central1 \
   --network=httplbs \
   --tags=http-server, \
   --image-family=debian-9 \
   --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'

Sortie

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-central1-template].
NAME: us-central1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:03:44.179-08:00

Vous pouvez maintenant vérifier que nos modèles d'instance ont bien été créés à l'aide de la commande gcloud suivante:

Depuis Cloud Shell

gcloud compute instance-templates list

Sortie

NAME                  MACHINE_TYPE   PREEMPTIBLE  CREATION_TIMESTAMP
us-central1-template   n1-standard-1         2021-11-09T09:25:37.263-08:00
us-east1-template      n1-standard-1         2021-11-09T09:24:35.275-08:00
us-west1-template      n1-standard-1         2021-11-09T09:25:08.016-08:00

Créer les groupes d'instances gérés par l'est, l'ouest et le centre

Nous devons maintenant créer un groupe d'instances géré à partir des modèles d'instance que nous avons créés précédemment.

Depuis Cloud Shell

gcloud compute instance-groups managed create us-east1-mig \
--base-instance-name=us-east1-mig \
--size=1 \
--template=us-east1-template \
--zone=us-east1-b

Sortie

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-east1-b/instanceGroupManagers/us-east1-mig].
NAME: us-east1-mig
LOCATION: us-east1-b
SCOPE: zone
BASE_INSTANCE_NAME: us-east1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-east1-template
AUTOSCALED: no

Depuis Cloud Shell

gcloud compute instance-groups managed create us-west1-mig \
--base-instance-name=us-west1-mig \
--size=1 \
--template=us-west1-template \
--zone=us-west1-a

Sortie

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroupManagers/us-west1-mig].
NAME: us-west1-mig
LOCATION: us-west1-a
SCOPE: zone
BASE_INSTANCE_NAME: us-west1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-west1-template
AUTOSCALED: no

Depuis Cloud Shell

gcloud compute instance-groups managed create us-central1-mig \
--base-instance-name=us-central1-mig \
--size=1 \
--template=us-central1-template \
--zone=us-central1-a

Sortie

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-central1-a/instanceGroupManagers/us-central1-mig].
NAME: us-central1-mig
LOCATION: us-central1-a
SCOPE: zone
BASE_INSTANCE_NAME: us-central1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-central1-template
AUTOSCALED: no

Nous pouvons vérifier que nos groupes d'instances ont bien été créés à l'aide de la commande gcloud suivante:

Depuis Cloud Shell

gcloud compute instance-groups list

Sortie

NAME                  LOCATION      SCOPE   NETWORK         MANAGED INSTANCES
us-central1-mig       us-central1   zone    httplbs          Yes      1
us-west1-mig          us-west1      zone    httplbs          Yes      1
us-east1-mig          us-east1      zone    httplbs          Yes      1

Vérifier le fonctionnement du serveur Web

Chaque instance est configurée pour exécuter un serveur Web Apache avec un simple script PHP qui affiche:

Pour vous assurer que vos serveurs Web fonctionnent correctement, accédez à Compute Engine -> d'instances de VM. Assurez-vous que vos nouvelles instances (par exemple, us-east1-mig-xxx) ont été créées conformément à leurs définitions de groupe d'instances.

À présent, envoyez une requête Web dans votre navigateur pour vous assurer que le serveur Web est en cours d'exécution (le démarrage peut prendre une minute). Sur la page "Instances de VM", sous Compute Engine, sélectionnez une instance créée par votre groupe d'instances, puis cliquez sur son adresse IP externe (publique).

Ou, dans votre navigateur, accédez à http://<IP_Address>

5. Configurer l'équilibreur de charge

Créer une vérification d'état

Nous devons d'abord créer une vérification d'état de base pour nous assurer que nos services sont opérationnels correctement. Nous allons créer une vérification d'état de base. De nombreuses autres personnalisations avancées sont disponibles.

Depuis Cloud Shell

gcloud compute health-checks create http http-basic-check \
    --port 80

Réserver une adresse IP externe

Pour cette étape, vous devez réserver une adresse IP statique disponible dans le monde entier qui sera associée ultérieurement à l'équilibreur de charge.

Depuis Cloud Shell

gcloud compute addresses create lb-ipv4-2 \
    --ip-version=IPV4 \
    --global

Veillez à noter l'adresse IP réservée.

gcloud compute addresses describe lb-ipv4-2 \
    --format="get(address)" \
    --global

Créer des services de backend

Nous devons maintenant créer un service de backend pour chacun des groupes d'instances gérés que nous avons créés précédemment. une pour l'est, l'ouest et le centre.

Créer un service de backend pour le groupe d'instances géré East

Depuis Cloud Shell

gcloud beta compute backend-services create east-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

Créer un service de backend pour le groupe d'instances géré par West

Depuis Cloud Shell

gcloud beta compute backend-services create west-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

Créer un service de backend pour le groupe d'instances géré par le centre d'administration

Depuis Cloud Shell

gcloud beta compute backend-services create central-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

Ajouter des MIG aux services de backend

Maintenant que nous avons créé les services de backend respectifs pour chaque cluster d'application, nous devons ajouter les groupes d'instances gérés que nous avons créés précédemment à chaque service de backend.

Ajout du MIG East au service de backend

Depuis Cloud Shell

gcloud beta compute backend-services add-backend east-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-east1-mig \
    --instance-group-zone=us-east1-b \
    --global

Ajout du MIG West au service de backend.

Depuis Cloud Shell

gcloud beta compute backend-services add-backend west-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-west1-mig \
    --instance-group-zone=us-west1-a \
    --global

Ajout du MIG West au service de backend.

Depuis Cloud Shell

gcloud beta compute backend-services add-backend central-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-central1-mig \
    --instance-group-zone=us-central1-a \
    --global

Créer un mappage d'URL

C'est dans le mappage d'URL que seront disponibles les fonctionnalités avancées de gestion du trafic de cet atelier. Nous devons créer un fichier .yaml qui contiendra la configuration. Dans le fichier .yaml, nous avons créé une correspondance de préfixe sur /roundrobbin. Ainsi, seule la correspondance de trafic /roundrobbin sera affectée par ces configurations. Nous avons spécifié que 50% du trafic devrait être dirigé vers east-backend-service et 50% vers west-backend-service. Nous avons également ajouté une valeur d'en-tête de réponse:{test}, qui sera présente dans toutes les réponses. Enfin, nous avons ajouté que l'ensemble du trafic doit être mis en miroir sur "central-backend-service". Le trafic est dupliqué et envoyé ici à des fins de test uniquement.

Enregistrez l'exemple sur votre ordinateur au format .yaml.

defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
kind: compute #urlMap
name: web-map-http
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /roundrobbin
    priority: 2
    headerAction:
        responseHeadersToAdd:
          - headerName: test
            headerValue: value
            replace: True
    routeAction:
        weightedBackendServices:
        - backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
          weight: 50
        - backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/west-backend-service
          weight: 50
        retryPolicy:
            retryConditions: ['502', '504']
            numRetries: 3
            perTryTimeout:
                seconds: 1
                nanos: 50
        requestMirrorPolicy:
          backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/central-backend-service

Créez le mappage d'URL en important le document depuis votre ordinateur. Notez que le chemin d'accès à la source varie en fonction de l'emplacement d'enregistrement du fichier .yaml.

Depuis Cloud Shell

gcloud beta compute url-maps import web-map-http \
   --source /Users/[USERNAME]/Documents/Codelab/lbconfig.yaml \
   --global

Créer une interface HTTP

La dernière étape de la création de l'équilibreur de charge consiste à créer l'interface. L'adresse IP que vous avez réservée précédemment sera mappée avec le mappage d'URL de l'équilibreur de charge que vous avez créé.

Depuis Cloud Shell

gcloud beta compute target-http-proxies create http-lb-proxy-adv \
    --url-map=web-map-http

Vous devez ensuite créer une règle de transfert globale qui mappera l'adresse IP réservée précédemment au proxy HTTP.

Depuis Cloud Shell

gcloud beta compute forwarding-rules create http-content-rule \
    --load-balancing-scheme EXTERNAL_MANAGED \
    --address=lb-ipv4-2 \
    --global \
    --target-http-proxy=http-lb-proxy-adv \
    --ports=80

6. Vérifiez que les fonctionnalités avancées liées au trafic fonctionnent

Pour vérifier que la fonctionnalité de répartition du trafic mise en œuvre fonctionne, vous devez générer une charge. Pour ce faire, nous allons créer une VM afin de simuler la charge.

Créer une règle d'autorisation de pare-feu SSH

Pour vous connecter en SSH à la VM à partir de laquelle nous allons générer du trafic, vous devez d'abord créer une règle de pare-feu qui autorise le trafic SSH vers la VM.

Depuis Cloud Shell

gcloud compute firewall-rules create fw-allow-ssh \
    --network=httplbs \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

Sortie

NAME          NETWORK  DIRECTION  PRIORITY  ALLOW   DENY  DISABLED
fw-allow-ssh  httplbs  INGRESS    1000      tcp:22        False

Créer Siege-vm

Vous allez maintenant créer l'instance siege-vm que vous utiliserez pour générer la charge

Depuis Cloud Shell

gcloud compute instances create siege-vm \
    --network=httplbs \
    --zone=us-east4-c \
    --machine-type=e2-medium \
    --tags=allow-ssh,http-server \
    --metadata=startup-script='sudo apt-get -y install siege'

Sortie

NAME     ZONE        MACHINE_TYPE INTERNAL_IP  EXTERNAL_IP    STATUS
siege-vm us-east4-c  e2-medium    10.150.0.3   34.85.218.119  RUNNING

Vous pouvez ensuite vous connecter en SSH à la VM que vous avez créée. Une fois le terminal créé, cliquez sur SSH pour ouvrir un terminal et vous y connecter.

Une fois connecté, exécutez la commande suivante pour générer une charge. Utilisez l'adresse IP que vous avez réservée précédemment pour l'équilibreur de charge HTTP externe.

Depuis Cloud Shell

siege -c 250 http://$lb-ipv4-2/roundrobbin

Sortie

New configuration template added to /home/cloudcurriculumdeveloper/.siege
Run siege -C to view the current settings in that file
[alert] Zip encoding disabled; siege requires zlib support to enable it: No such file or directory
** SIEGE 4.0.2
** Preparing 250 concurrent users for battle.
The server is now under siege...

Vérifier la répartition de la charge

Maintenant que Siege est en cours d'exécution, vous devez vérifier que le trafic est bien réparti entre les groupes d'instances gérés "Est" et "Ouest". Vous pouvez également vérifier que la mise en miroir du trafic fonctionne et que le trafic est envoyé au groupe d'instances géré central.

Dans le menu de navigation de la console Cloud, cliquez sur Services réseau > Équilibrage de charge Cliquez sur "Backends". Cliquez sur le menu avancé, comme illustré dans la capture d'écran ci-dessous.

Accédez à l'onglet "Services de backend", puis sélectionnez l'instance "east-backend-service".

Vous pourrez voir la répartition du trafic en temps réel vers ce MIG. Notez le taux. Vous pourrez le comparer dans un instant à celui du backend "west-backend-service".

De même, accédez à "west-backend-service". Vous devriez également voir du trafic circuler vers ce service. Le taux devrait être semblable à celui que vous avez vu dans east-backend-service, puisque vous avez configuré une répartition du trafic à tour de rôle 50/50.

Pour vous assurer que la règle de mise en miroir du trafic que vous avez créée fonctionne, vous devez vérifier l'utilisation du groupe d'instances géré "central-backend-service". Pour ce faire, accédez à "compute", "Compute Engine" et "Groupes d'instances", puis sélectionnez "us-central1-mig". Accédez ensuite à l'onglet "Monitoring".

Les graphiques qui s'affichent indiquent que le trafic a été mis en miroir sur ce groupe d'instances géré.

Arrête le siège

Maintenant que vous avez démontré que la répartition avancée du trafic fonctionne, il est temps d'arrêter le siege. Pour ce faire, revenez au terminal SSH de siege-vm et appuyez sur CTRL+C pour arrêter l'exécution de siege.

Valider l'envoi de l'en-tête de la réponse

Avant d'effectuer le nettoyage, vous pouvez vérifier rapidement que l'équilibreur de charge HTTP envoie l'en-tête de réponse approprié. Vous l'avez configurée pour envoyer le test d'en-tête avec la valeur de contenu. L'exécution de la commande curl à partir de Cloud Shell donne la réponse attendue.

Depuis Cloud Shell

curl -svo /dev/null http://lb-ipv4-2/roundrobbin

Sortie

*   Trying lb-ipv4-2..
* TCP_NODELAY set
* Connected to  lb-ipv4-2 ( lb-ipv4-2) port 80 (#0)
> GET /roundrobbin HTTP/1.1
> Host:  lb-ipv4-2
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< date: Wed, 10 Nov 2021 17:05:27 GMT
< server: envoy
< Content-Length: 273
< content-type: text/html; charset=iso-8859-1
< via: 1.1 google
< test: value
<
{ [273 bytes data]
* Connection #0 to host 34.149.2.26 left intact
* Closing connection 0

7. Nettoyage de l'atelier

Maintenant que nous en avons terminé avec l'environnement de l'atelier, il est temps de le démonter. Veuillez exécuter les commandes suivantes pour supprimer l'environnement de test.

Depuis Cloud Shell

gcloud compute instances delete siege-vm

gcloud alpha compute forwarding-rules delete http-content-rule --global
gcloud alpha compute target-http-proxies delete http-lb-proxy-adv
gcloud alpha compute url-maps delete web-map-http
gcloud alpha compute backend-services delete east-backend-service --global
gcloud alpha compute backend-services delete west-backend-service --global
gcloud alpha compute backend-services delete central-backend-service --global

gcloud compute addresses delete lb-ipv4-2 --global
gcloud compute health-checks delete http-basic-check 

gcloud compute instance-groups managed delete us-east1-mig --zone us-east1-b
gcloud compute instance-groups managed delete us-west1-mig --zone us-west1-a
gcloud compute instance-groups managed delete us-central1-mig --zone us-central1-a

gcloud compute instance-templates delete "us-east1-template" 
gcloud compute instance-templates delete "us-west1-template" 
gcloud compute instance-templates delete "us-central1-template" 

gcloud compute firewall-rules delete httplb-allow-http-rule
gcloud compute firewall-rules delete fw-allow-ssh

gcloud compute networks delete httplbs

8. Félicitations !

Vous avez terminé l'atelier de programmation sur l'équilibrage de charge HTTPs externe avec la gestion avancée du trafic (Envoy).

Points abordés

Configurer un groupe d'instances géré, ainsi que les règles de VPC et de pare-feu associées
Utiliser les fonctionnalités avancées de gestion du trafic du nouvel équilibreur de charge
Comment vérifier que les fonctionnalités avancées de gestion du trafic fonctionnent comme prévu

Étapes suivantes

Essayez certaines des autres fonctionnalités de routage avancées, telles que la réécriture d'URL, l'ajout d'en-têtes CORS et bien d'autres ( lien).