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:
- Répartition du trafic pondéré
- Mise en miroir des requêtes
- Détection des anomalies
- Nouvelles tentatives de requête
- Injection de pannes
- Options supplémentaires d'affinité de session de backend
- Options de transformation d'en-tête supplémentaires
- Partage des ressources entre origines multiples (CORS)
- Nouveaux algorithmes d'équilibrage de charge
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 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 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 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 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 compute backend-services add-backend west-backend-service \
--balancing-mode='UTILIZATION' \
--instance-group=us-west1-mig \
--instance-group-zone=us-west1-a \
--global
Ajoutez un MIG central au service de backend.
Depuis Cloud Shell
gcloud 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 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 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 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 Sélectionnez l'équilibreur de charge web-map-http. Accédez à l'onglet "Monitoring" (Surveillance) pour afficher le graphique ci-dessous.
Vous pourrez voir la répartition du trafic en temps réel vers ce MIG. Le trafic est réparti équitablement puisque vous avez configuré une répartition 50/50 round robbin.
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 --zone=us-east4-c gcloud compute forwarding-rules delete http-content-rule --global gcloud compute target-http-proxies delete http-lb-proxy-adv gcloud compute url-maps delete web-map-http gcloud compute backend-services delete east-backend-service --global gcloud compute backend-services delete west-backend-service --global gcloud 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).