GSP662

Présentation

Il existe de nombreuses façons de déployer des sites Web dans Google Cloud, et chacune d'elles offre des fonctionnalités, des capacités et des niveaux de contrôle différents. Compute Engine procure un haut niveau de contrôle sur l'infrastructure utilisée pour exécuter un site Web. Toutefois, ce composant nécessite aussi une gestion des opérations un peu plus conséquente que Google Kubernetes Engine (GKE), App Engine ou d'autres solutions. Avec Compute Engine, vous disposez d'un contrôle précis des différents aspects de l'infrastructure, comme les machines virtuelles, les équilibreurs de charge, etc.

Dans cet atelier, vous allez déployer un exemple d'application, le site Web d'e-commerce "Fancy Store", pour apprendre comment effectuer le déploiement et le scaling d'un site Web en toute facilité avec Compute Engine.

Points abordés

Dans cet atelier, vous allez apprendre à effectuer les tâches suivantes :

• Créer des instances Compute Engine
• Créer des modèles d'instance à partir d'instances sources
• Créer des groupes d'instances gérés
• Créer et tester des vérifications d'état pour les groupes d'instances gérés
• Créer des équilibreurs de charge HTTP(S)
• Créer des vérifications d'état pour les équilibreurs de charge
• Utiliser un réseau de diffusion de contenu (CDN) pour la mise en cache

À la fin de cet atelier, vous disposerez d'instances dans des groupes d'instances gérés qui assureront l'autoréparation, l'équilibrage de charge, l'autoscaling et les mises à jour progressives de votre site Web.

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Des identifiants temporaires vous sont fournis pour vous permettre de vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

• Vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome).

Remarque : Ouvrez une fenêtre de navigateur en mode incognito (recommandé) ou de navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le compte temporaire de participant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

• Vous disposez d'un temps limité. N'oubliez pas qu'une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.

Remarque : Utilisez uniquement le compte de participant pour cet atelier. Si vous utilisez un autre compte Google Cloud, des frais peuvent être facturés à ce compte.

Démarrer l'atelier et se connecter à la console Google Cloud

1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, une boîte de dialogue s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la droite, vous trouverez le panneau Préparation et accès à l'atelier, qui contient les éléments suivants :

   • Le bouton Ouvrir la console Google Cloud
   • Les identifiants temporaires (nom d'utilisateur et mot de passe) que vous devez utiliser pour cet atelier
   • Des informations complémentaires vous permettant d'effectuer l'atelier, si nécessaire

   Notez que le minuteur de l'atelier se trouve en haut de la page et indique le temps restant.

2. Cliquez sur Ouvrir la console Google Cloud (ou effectuez un clic droit et sélectionnez Ouvrir le lien dans une fenêtre en navigation privée si vous utilisez Chrome).

   L'atelier lance les ressources, puis ouvre la page "Se connecter" dans un nouvel onglet.

   Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

   Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.

3. Si nécessaire, copiez le nom d'utilisateur ci-dessous et collez-le dans la boîte de dialogue Se connecter.

   {{{user_0.username | "Username"}}}

   Vous trouverez également le nom d'utilisateur dans le panneau Préparation et accès à l'atelier.

4. Cliquez sur Suivant.

5. Copiez le mot de passe ci-dessous et collez-le dans la boîte de dialogue Bienvenue.

   {{{user_0.password | "Password"}}}

   Vous trouverez également le mot de passe dans le panneau Préparation et accès à l'atelier.

6. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis pour l'atelier. N'utilisez pas les identifiants de votre compte Google Cloud. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires pourront vous être facturés.

7. Accédez aux pages suivantes :

   • Acceptez les conditions d'utilisation.
   • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
   • Ne vous inscrivez pas à des essais sans frais.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Pour accéder aux produits et services Google Cloud, cliquez sur le menu de navigation ou saisissez le nom du service ou du produit dans le champ Recherche.

Activer Cloud Shell

Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

1. Cliquez sur Activer Cloud Shell  en haut de la console Google Cloud.

2. Passez les fenêtres suivantes :

   • Accédez à la fenêtre d'informations de Cloud Shell.
   • Autorisez Cloud Shell à utiliser vos identifiants pour effectuer des appels d'API Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET : . Le résultat contient une ligne qui déclare l'ID_PROJET pour cette session :

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

3. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

4. Cliquez sur Autoriser.

Résultat :

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Définir votre région et votre zone

Certaines ressources Compute Engine sont hébergées dans des régions et des zones. Une région est un emplacement géographique spécifique où vous pouvez exécuter vos ressources. Chaque région se compose d'une ou plusieurs zones.

Exécutez les commandes gcloud suivantes dans Cloud Shell pour définir la région et la zone par défaut de votre atelier :

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

Tâche 1 : Activer l'API Compute Engine

• Activez l'API Compute Engine en exécutant la commande suivante :

gcloud services enable compute.googleapis.com

Tâche 2 : Créer un bucket Cloud Storage

Vous allez utiliser un bucket Cloud Storage pour héberger votre code compilé et vos scripts de démarrage.

• Dans Cloud Shell, exécutez la commande suivante pour créer un bucket Cloud Storage :

gcloud storage buckets create gs://fancy-store-{{{project_0.project_id | Project ID}}}

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer un bucket Cloud Storage

Tâche 3 : Cloner un dépôt source

Vous allez baser votre site sur le site Web d'e-commerce Fancy Store existant, qui repose sur le dépôt monolith-to-microservices.

Dans cette tâche, vous allez cloner le code source, ce qui vous permettra de vous concentrer sur les différents aspects du déploiement sur Compute Engine. Dans la suite de cet atelier, vous modifierez légèrement le code pour expérimenter la simplicité du processus de mise à jour dans Compute Engine.

1. Exécutez les commandes suivantes pour cloner le code source, puis accédez au répertoire monolith-to-microservices :

git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices

2. Exécutez la compilation initiale du code pour autoriser l'application à s'exécuter localement avec la commande suivante :

./setup.sh

L'exécution de ce script prend quelques minutes.

3. Une fois cette opération terminée, vérifiez que Cloud Shell exécute une version NodeJS compatible à l'aide de la commande suivante :

nvm install --lts

4. Maintenant, exécutez la commande suivante pour tester l'application, accéder au répertoire microservices et démarrer le serveur Web :

cd microservices npm start

Vous devez obtenir le résultat suivant.

Résultat :

Products microservice listening on port 8082! Frontend microservice listening on port 8080! Orders microservice listening on port 8081!

5. Prévisualisez votre application en cliquant sur l'icône d'aperçu sur le Web, puis en sélectionnant Prévisualiser sur le port 8080.

Une nouvelle fenêtre présentant l'interface de Fancy Store s'affiche.

Remarque : L'option d'aperçu vous permet d'observer le microservice "Frontend" (Interface), mais les fonctions "Products" (Produits) et "Orders" (Commandes) ne fonctionnent pas, car ces services ne sont pas encore exposés.

6. Fermez cette fenêtre après avoir visualisé le site Web, puis appuyez sur Ctrl+C dans la fenêtre de terminal pour arrêter le processus du serveur Web.

Tâche 4 : Créer les instances Compute Engine

Le moment est venu de commencer à déployer des instances Compute Engine.

Dans les sections suivantes, vous allez effectuer les actions ci-dessous :

1. Créer un script de démarrage pour configurer les instances
2. Cloner le code source et l'importer dans Cloud Storage
3. Déployer une instance Compute Engine pour héberger les microservices backend
4. Reconfigurer le code de l'interface (frontend) pour qu'il utilise l'instance des microservices backend
5. Déployer une instance Compute Engine pour héberger le microservice frontend
6. Configurer le réseau pour autoriser la communication

Créer le script de démarrage

Nous allons utiliser un script de démarrage pour indiquer à l'instance les opérations à effectuer à chaque démarrage. De cette manière, les instances sont automatiquement configurées.

1. Dans le terminal Cloud Shell, exécutez la commande suivante pour créer un fichier nommé startup-script.sh :

touch ~/monolith-to-microservices/startup-script.sh

2. Cliquez sur Ouvrir l'éditeur dans la barre d'outils Cloud Shell pour ouvrir l'éditeur de code.

3. Accédez au dossier monolith-to-microservices.

4. Ajoutez le code suivant au fichier startup-script.sh. Par la suite, vous modifierez une partie de ce code :

#!/bin/bash # Installer le moniteur de journalisation. Le moniteur récupère automatiquement les journaux envoyés à # syslog. curl -s "https://storage.googleapis.com/signals-agents/logging/google-fluentd-install.sh" | bash service google-fluentd restart & # Installer les dépendances depuis apt. apt-get update apt-get install -yq ca-certificates git build-essential supervisor psmisc # Installer nodejs. apt-get install -y nodejs npm # Obtenir le code source de l'application depuis le bucket Google Cloud Storage. mkdir /fancy-store gcloud storage cp -r gs://fancy-store-[DEVSHELL_PROJECT_ID]/monolith-to-microservices/microservices/* /fancy-store/ # Installer les dépendances de l'application. cd /fancy-store/ npm install # Créer un utilisateur nodeapp. L'application s'exécutera en tant que cet utilisateur. useradd -m -d /home/nodeapp nodeapp chown -R nodeapp:nodeapp /fancy-store # Configurer Supervisor pour exécuter l'application de nœud. cat >/etc/supervisor/conf.d/node-app.conf << EOF [program:nodeapp] directory=/fancy-store command=npm start autostart=true autorestart=true user=nodeapp environment=HOME="/home/nodeapp",USER="nodeapp",NODE_ENV="production" stdout_logfile=syslog stderr_logfile=syslog EOF supervisorctl reread supervisorctl update

5. Remplacez [DEVSHELL_PROJECT_ID] par l'ID de votre projet ({{{project_0.project_id | Project ID}}}).
6. Cliquez sur Fichier > Enregistrer ou appuyez sur CTRL+S pour enregistrer le fichier startup-script.sh, mais ne le fermez pas encore.

7. Cliquez sur Enregistrer ou appuyez sur Ctrl+S pour enregistrer le fichier startup-script.sh, mais ne le fermez pas pour le moment.

8. En bas à droite de l'éditeur de code Cloud Shell, assurez-vous que l'option "End of Line Sequence" (Séquence de fin de ligne) est définie sur "LF" (Saut de ligne) et non sur "CRLF" (Retour chariot et saut de ligne).



• Si cette option est définie sur "CRLF", cliquez sur CRLF, puis sélectionnez LF dans la liste déroulante.
• Si elle est déjà définie sur LF, ne la modifiez pas.

Retournez dans le terminal Cloud Shell et exécutez la commande suivante pour copier le fichier startup-script.sh dans votre bucket :

gcloud storage cp ~/monolith-to-microservices/startup-script.sh gs://fancy-store-{{{project_0.project_id | Project ID}}}

Le fichier est à présent accessible à l'adresse suivante : https://storage.googleapis.com/[BUCKET_NAME]/startup-script.sh.

[BUCKET_NAME] représente le nom du bucket Cloud Storage. Il n'est visible que par les utilisateurs autorisés et les comptes de service par défaut. Il est inaccessible dans un navigateur Web. Les instances Compute Engine y ont automatiquement accès avec leur compte de service.

Le script de démarrage effectue les tâches suivantes :

• Il installe l'agent Logging qui collecte automatiquement les journaux de syslog.
• Il installe Node.js et Supervisor. Supervisor exécute l'application en tant que daemon.
• Il clone le code source de l'application à partir du bucket Cloud Storage et installe les dépendances.
• Il configure Supervisor pour exécuter l'application. Supervisor s'assure que l'application redémarre si elle se ferme de façon inattendue ou si elle est arrêtée par un administrateur ou par un processus. Il envoie également les fichiers "stdout" et "stderr" de l'application à syslog pour qu'ils soient collectés par l'agent Logging.

Copier le code dans le bucket Cloud Storage

Lorsque les instances démarrent, elles récupèrent le code du bucket Cloud Storage. Vous pouvez donc stocker certaines variables de configuration dans le fichier .env du code.

Remarque : Vous pourriez également adapter le code de manière à récupérer les variables d'environnement à un autre emplacement. Toutefois, pour les besoins de notre démonstration, cette méthode constitue un moyen simple de gérer la configuration. En production, les variables d'environnement seraient probablement stockées à l'extérieur du code.
• Exécutez la commande suivante pour copier le code cloné dans votre bucket :
cd ~ rm -rf monolith-to-microservices/*/node_modules gcloud storage cp -r monolith-to-microservices gs://fancy-store-{{{project_0.project_id | Project ID}}}/ Remarque : Les répertoires de dépendances node_modules sont supprimés pour que la copie puisse s'effectuer le plus rapidement et efficacement possible. Ces répertoires sont recréés sur les instances lorsqu'elles démarrent.

Cliquez sur Vérifier ma progression pour valider l'objectif. Copier le script de démarrage et le code dans un bucket Cloud Storage

Déployer l'instance backend

La première instance à déployer est l'instance backend, qui héberge les microservices "Orders" (Commandes) et "Products" (Produits).

Remarque : Dans un environnement de production, vous pouvez placer chaque microservice dans une instance et un groupe d'instances qui lui sont propres pour être en mesure d'effectuer leur scaling de manière indépendante. Pour les besoins de cette démonstration, les deux microservices backend, "Orders" (Commandes) et "Products" (Produits), résident sur la même instance et dans le même groupe d'instances.
• Exécutez la commande suivante pour créer une instance e2-standard-2 configurée pour utiliser le script de démarrage. Cette instance est dotée du tag backend, ce qui vous permettra de lui appliquer des règles de pare-feu spécifiques par la suite :
gcloud compute instances create backend \ --zone={{{project_0.default_zone | zone}}} \ --machine-type=e2-standard-2 \ --tags=backend \ --image-family={{{project_0.startup_script.debian_image_id_short | nom de l'image Debian}}} \ --image-project=debian-cloud \ --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-{{{project_0.project_id | ID du projet}}}/startup-script.sh

Configurer une connexion au backend

Avant de déployer l'interface de l'application, vous devez modifier la configuration pour qu'elle pointe vers le backend que vous venez de déployer.

1. Exécutez la commande suivante pour récupérer l'adresse IP externe du backend, indiquée sous le libellé EXTERNAL_IP de l'instance backend :
gcloud compute instances list

Exemple de résultat :

NAME: backend ZONE: {{{project_0.default_zone | zone}}} MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: INTERNAL_IP: 10.142.0.2 EXTERNAL_IP: 35.237.245.193 STATUS: RUNNING

2. Copiez l'adresse IP externe du backend.

3. Dans l'explorateur Cloud Shell, accédez à monolith-to-microservices > react-app.

4. Dans l'éditeur de code, sélectionnez View > Toggle Hidden Files (Afficher > Activer/Désactiver les fichiers cachés) pour voir le fichier .env.

L'étape suivante consiste à modifier le fichier .env pour qu'il pointe vers l'adresse IP externe du backend. [BACKEND_ADDRESS] représente l'adresse IP externe de l'instance backend déterminée au moyen de la commande gcloud exécutée précédemment.

5. Dans le fichier .env, remplacez localhost par votre [BACKEND_ADDRESS] :
REACT_APP_ORDERS_URL=http://[BACKEND_ADDRESS]:8081/api/orders REACT_APP_PRODUCTS_URL=http://[BACKEND_ADDRESS]:8082/api/products

6. Enregistrez le fichier.

7. Dans Cloud Shell, exécutez la commande suivante pour recompiler react-app, ce qui mettra à jour le code du frontend :

cd ~/monolith-to-microservices/react-app npm install && npm run-script build
8. Ensuite, copiez le code d'application dans le bucket Cloud Storage :
cd ~ rm -rf monolith-to-microservices/*/node_modules gcloud storage cp -r monolith-to-microservices gs://fancy-store-{{{project_0.project_id | Project ID}}}/

Déployer l'instance frontend

Maintenant que le code est configuré, vous êtes prêt à déployer l'instance frontend.

• Exécutez la commande suivante pour déployer l'instance frontend (la commande est semblable à celle utilisée pour l'instance backend). Cette instance est dotée du tag frontend pour les besoins du pare-feu :
gcloud compute instances create frontend \ --zone={{{project_0.default_zone | zone}}} \ --machine-type=e2-standard-2 \ --tags=frontend \ --image-family={{{project_0.startup_script.debian_image_id_short | nom de l'image Debian}}} \ --image-project=debian-cloud \ --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-{{{project_0.project_id | ID du projet}}}/startup-script.sh Remarque : La commande de déploiement et le script de démarrage sont utilisés avec les instances frontend et backend pour plus de simplicité, et parce que le code est configuré pour lancer tous les microservices par défaut. En conséquence, tous les microservices s'exécutent à la fois sur les instances frontend et backend dans cet exemple. Dans un environnement de production, vous exécuteriez uniquement les microservices dont vous avez besoin sur chaque composant.

Configurer le réseau

1. Exécutez la commande suivante pour créer des règles de pare-feu afin d'autoriser l'accès au port 8080 pour le frontend, et aux ports 8081-8082 pour le backend. Ces commandes de pare-feu utilisent les tags attribués lors de la création des instances pour l'application :
gcloud compute firewall-rules create fw-fe \ --allow tcp:8080 \ --target-tags=frontend gcloud compute firewall-rules create fw-be \ --allow tcp:8081-8082 \ --target-tags=backend

Le site Web doit maintenant être totalement fonctionnel.

2. Pour accéder à l'adresse IP externe du frontend, vous devez connaître cette adresse. Exécutez la commande suivante et recherchez l'adresse IP externe sous le libellé "EXTERNAL_IP" de l'instance frontend :
gcloud compute instances list

Exemple de résultat :

NAME: backend ZONE: us-central1-f MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: INTERNAL_IP: 10.128.0.2 EXTERNAL_IP: 34.27.178.79 STATUS: RUNNING NAME: frontend ZONE: us-central1-f MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: INTERNAL_IP: 10.128.0.3 EXTERNAL_IP: 34.172.241.242 STATUS: RUNNING

Le démarrage et la configuration de l'instance peuvent prendre plusieurs minutes.

3. Patientez trois minutes, puis ouvrez un nouvel onglet de navigateur et accédez au site Web en vous connectant à l'adresse http://[FRONTEND_ADDRESS]:8080, où [FRONTEND_ADDRESS] correspond à l'adresse IP externe de l'instance frontend déterminée ci-dessus (libellé "EXTERNAL_IP").

4. Essayez d'accéder aux pages Products (Produits) et Orders (Commandes), lesquelles doivent à présent fonctionner.



Cliquez sur Vérifier ma progression pour valider l'objectif. Déployer les instances et configurer le réseau

Tâche 5 : Créer des groupes d'instances gérés

Pour permettre le scaling de l'application, vous allez créer des groupes d'instances gérés qui utiliseront les instances frontend et backend en tant que modèles d'instance.

Un groupe d'instances géré (MIG) contient des instances identiques que vous pouvez gérer comme une seule entité dans une même zone. Les groupes d'instances gérés préservent la haute disponibilité de vos applications en s'assurant de manière proactive que vos instances restent disponibles, c'est-à-dire à l'état RUNNING (En cours d'exécution). Vous allez utiliser des groupes d'instances gérés pour vos instances frontend et backend afin d'assurer l'autoréparation, l'équilibrage de charge, l'autoscaling et les mises à jour progressives.

Créer un modèle d'instance à partir d'une instance source

Avant de créer un groupe d'instances géré, vous devez commencer par créer un modèle d'instance sur lequel reposera ce groupe. Les modèles d'instance vous permettent de définir le type de machine, l'image de disque de démarrage ou l'image de conteneur, le réseau, ainsi que d'autres propriétés d'instance à utiliser lors de la création d'instances de VM. Vous pouvez utiliser des modèles d'instance aussi bien pour créer des instances dans un groupe d'instances géré que pour créer des instances individuelles.

Pour créer le modèle d'instance, utilisez les instances que vous avez créées précédemment.

1. Commencez par exécuter la commande suivante pour arrêter les deux instances :
gcloud compute instances stop frontend --zone={{{project_0.default_zone | zone}}} gcloud compute instances stop backend --zone={{{project_0.default_zone | zone}}}
2. Ensuite, créez le modèle d'instance à partir de chacune des instances sources à l'aide des commandes suivantes :
gcloud compute instance-templates create fancy-fe \ --source-instance-zone={{{project_0.default_zone | zone}}} \ --source-instance=frontend gcloud compute instance-templates create fancy-be \ --source-instance-zone={{{project_0.default_zone | zone}}} \ --source-instance=backend
3. Exécutez la commande suivante pour vérifier que les modèles d'instance ont été créés :
gcloud compute instance-templates list

Exemple de résultat :

NAME: fancy-be MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: CREATION_TIMESTAMP: 2023-07-25T14:52:21.933-07:00 NAME: fancy-fe MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: CREATION_TIMESTAMP: 2023-07-25T14:52:15.442-07:00
4. Une fois les modèles d'instance créés, exécutez la commande suivante pour supprimer la VM backend et économiser de l'espace de ressources :
gcloud compute instances delete backend --zone={{{project_0.default_zone | zone}}}
5. Saisissez y lorsque vous y êtes invité.

Normalement, vous pourriez également supprimer la VM frontend, mais vous allez devoir l'utiliser pour mettre à jour le modèle d'instance dans la suite de l'atelier.

Créer des groupes d'instances gérés

1. Maintenant, exécutez les commandes suivantes pour créer deux groupes d'instances gérés, l'un pour le frontend, et l'autre pour le backend :
gcloud compute instance-groups managed create fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --base-instance-name fancy-fe \ --size 2 \ --template fancy-fe gcloud compute instance-groups managed create fancy-be-mig \ --zone={{{project_0.default_zone | zone}}} \ --base-instance-name fancy-be \ --size 2 \ --template fancy-be

Ces groupes d'instances gérés utilisent les modèles d'instance et sont configurés pour démarrer deux instances chacun. Les instances sont automatiquement nommées d'après la valeur spécifiée pour l'élément base-instance-name, complétée par des caractères aléatoires.

2. Exécutez la commande suivante pour vous assurer que, dans le cas de votre application, le microservice frontend s'exécute sur le port 8080, tandis que le microservice backend s'exécute sur le port 8081 pour orders (commandes) et sur le port 8082 pour products (produits) :
gcloud compute instance-groups set-named-ports fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --named-ports frontend:8080 gcloud compute instance-groups set-named-ports fancy-be-mig \ --zone={{{project_0.default_zone | zone}}} \ --named-ports orders:8081,products:8082

Étant donné qu'il s'agit de ports non standards, vous spécifiez des ports nommés pour les identifier. Les ports nommés sont des métadonnées de paire clé-valeur qui représentent le nom du service et le port sur lequel le service s'exécute. Les ports nommés peuvent être attribués à un groupe d'instances. Dans ce cas, le service est disponible sur toutes les instances du groupe. Ces informations sont utilisées par le service d'équilibrage de charge HTTP que vous configurerez par la suite.

Configurer l'autoréparation

Pour améliorer la disponibilité de l'application proprement dite et pour vérifier qu'elle répond, configurez une règle d'autoréparation pour les groupes d'instances gérés.

Une règle d'autoréparation repose sur une vérification de l'état basée sur l'application pour s'assurer qu'une application répond comme prévu. Vérifier la réactivité d'une application constitue une méthode plus précise que simplement s'assurer qu'une instance présente l'état RUNNING (En cours d'exécution), qui est le comportement par défaut.

Remarque : Des vérifications d'état distinctes sont utilisées pour l'équilibrage de charge et pour l'autoréparation. Les vérifications d'état qui s'appliquent à l'équilibrage de charge peuvent et même doivent se révéler plus agressives, car elles déterminent si une instance reçoit du trafic utilisateur ou non. Vous devez identifier rapidement les instances non réactives afin de pouvoir rediriger le trafic si nécessaire. En revanche, les vérifications d'état qui concernent l'autoréparation entraînent le remplacement proactif des instances défaillantes par Compute Engine. Ces vérifications d'état devraient donc être plus conservatrices que celles destinées à l'équilibrage de charge.
1. Exécutez la commande suivante pour créer une vérification d'état qui répare l'instance si elle renvoie la valeur "unhealthy" (non opérationnelle) trois fois de suite pour les instances frontend et backend :
gcloud compute health-checks create http fancy-fe-hc \ --port 8080 \ --check-interval 30s \ --healthy-threshold 1 \ --timeout 10s \ --unhealthy-threshold 3 gcloud compute health-checks create http fancy-be-hc \ --port 8081 \ --request-path=/api/orders \ --check-interval 30s \ --healthy-threshold 1 \ --timeout 10s \ --unhealthy-threshold 3
2. Exécutez la commande suivante pour créer une règle de pare-feu qui autorise les vérifications d'état à se connecter aux microservices sur les ports 8080-8081 :
gcloud compute firewall-rules create allow-health-check \ --allow tcp:8080-8081 \ --source-ranges 130.211.0.0/22,35.191.0.0/16 \ --network default
3. Appliquez les vérifications d'état à leurs services respectifs à l'aide des commandes suivantes :
gcloud compute instance-groups managed update fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --health-check fancy-fe-hc \ --initial-delay 300 gcloud compute instance-groups managed update fancy-be-mig \ --zone={{{project_0.default_zone | zone}}} \ --health-check fancy-be-hc \ --initial-delay 300 Remarque : L'autoréparation peut mettre jusqu'à 15 minutes avant de commencer à surveiller les instances du groupe.
4. Poursuivez l'atelier pour laisser le temps à l'autoréparation de surveiller les instances du groupe. Vous simulerez une défaillance à la fin de l'atelier pour tester l'autoréparation.

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer des groupes d'instances gérés

Tâche 6 : Créer des équilibreurs de charge

Pour compléter vos groupes d'instances gérés, utilisez des équilibreurs de charge HTTP(S) afin d'acheminer le trafic vers les microservices frontend et backend, et servez-vous de mappages pour envoyer le trafic aux services de backend appropriés en fonction des règles de chemin d'accès. Cela expose une seule adresse IP à équilibrage de charge pour la totalité des services.

Pour en savoir plus sur les options d'équilibrage de charge sur Google Cloud, consultez le guide Présentation de Cloud Load Balancing.

Créer l'équilibreur de charge HTTP(S)

Google Cloud offre de nombreux types d'équilibreurs de charge. Dans cet atelier, vous utilisez un équilibreur de charge HTTP(S) pour votre trafic. Un équilibreur de charge HTTP est structuré de la manière suivante :

• Une règle de transfert dirige les requêtes entrantes vers un proxy HTTP cible.
• Le proxy HTTP cible analyse chaque requête par rapport à un mappage d'URL afin de déterminer le service de backend approprié pour la requête.
• Le service de backend dirige chaque requête vers un backend adapté en fonction de la capacité de diffusion, de la zone et de l'état des instances des backends qui lui sont associés. L'état de chaque instance backend est contrôlé à l'aide d'une vérification d'état HTTP. Si le service de backend est configuré pour utiliser une vérification d'état HTTPS ou HTTP/2, la requête est chiffrée pour être acheminée vers l'instance backend.
• Les sessions entre l'équilibreur de charge et l'instance peuvent utiliser le protocole HTTP, HTTPS ou HTTP/2. Si vous utilisez HTTPS ou HTTP/2, chaque instance des services de backend doit posséder un certificat SSL.
Remarque : Pour les besoins de cette démonstration, vous utilisez HTTP plutôt que HTTPS afin d'éviter les certificats SSL complexes. Dans un environnement de production, il est recommandé d'utiliser HTTPS pour le chiffrement chaque fois que cela est possible.
1. Exécutez la commande suivante pour créer des vérifications d'état qui serviront à déterminer les instances capables d'acheminer le trafic pour chaque service :
gcloud compute health-checks create http fancy-fe-frontend-hc \ --request-path=/ \ --port=8080 gcloud compute health-checks create http fancy-be-orders-hc \ --request-path=/api/orders \ --port=8081 gcloud compute health-checks create http fancy-be-products-hc \ --request-path=/api/products \ --port=8082 Remarque : Ces vérifications d'état s'appliquent à l'équilibreur de charge, et gèrent uniquement l'acheminement du trafic depuis l'équilibreur. Elles n'entraînent pas la recréation des instances par les groupes d'instances gérés.
2. Exécutez la commande suivante pour créer les services de backend qui constituent la cible du trafic à équilibrage de charge. Les services de backend utilisent les vérifications d'état et les ports nommés que vous avez créés :
gcloud compute backend-services create fancy-fe-frontend \ --health-checks=fancy-fe-frontend-hc \ --port-name=frontend \ --global gcloud compute backend-services create fancy-be-orders \ --health-checks=fancy-be-orders-hc \ --port-name=orders \ --global gcloud compute backend-services create fancy-be-products \ --health-checks=fancy-be-products-hc \ --port-name=products \ --global
3. Exécutez la commande suivante pour ajouter les services de backend de l'équilibreur de charge :
gcloud compute backend-services add-backend fancy-fe-frontend \ --instance-group-zone={{{project_0.default_zone | zone}}} \ --instance-group fancy-fe-mig \ --global gcloud compute backend-services add-backend fancy-be-orders \ --instance-group-zone={{{project_0.default_zone | zone}}} \ --instance-group fancy-be-mig \ --global gcloud compute backend-services add-backend fancy-be-products \ --instance-group-zone={{{project_0.default_zone | zone}}} \ --instance-group fancy-be-mig \ --global
4. Exécutez la commande suivante pour créer un mappage d'URL qui définit quelles URL diriger vers quels services de backend :
gcloud compute url-maps create fancy-map \ --default-service fancy-fe-frontend
5. Exécutez la commande suivante pour créer un outil de mise en correspondance des chemins d'accès qui autorise le routage à partir des chemins d'accès /api/orders et /api/products vers leurs services respectifs :
gcloud compute url-maps add-path-matcher fancy-map \ --default-service fancy-fe-frontend \ --path-matcher-name orders \ --path-rules "/api/orders=fancy-be-orders,/api/products=fancy-be-products"
6. Exécutez la commande suivante pour créer le proxy lié au mappage d'URL :
gcloud compute target-http-proxies create fancy-proxy \ --url-map fancy-map
7. Exécutez la commande suivante pour créer une règle de transfert globale qui associe une adresse IP publique et un port au proxy :
gcloud compute forwarding-rules create fancy-http-rule \ --global \ --target-http-proxy fancy-proxy \ --ports 80

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer des équilibreurs de charge HTTP(S)

Mettre à jour la configuration

Maintenant que vous disposez d'une nouvelle adresse IP statique, modifiez le code du frontend pour qu'il pointe vers cette nouvelle adresse, et non plus vers l'adresse éphémère utilisée précédemment qui pointait vers l'instance backend.

1. Dans Cloud Shell, accédez au dossier react-app qui héberge le fichier .env contenant la configuration :
cd ~/monolith-to-microservices/react-app/
2. Recherchez l'adresse IP de l'équilibreur de charge en exécutant la commande suivante :
gcloud compute forwarding-rules list --global

Exemple de résultat :

NAME: fancy-http-rule REGION: IP_ADDRESS: 34.111.203.235 IP_PROTOCOL: TCP TARGET: fancy-proxy
3. Revenez dans l'éditeur Cloud Shell et modifiez de nouveau le fichier .env pour qu'il pointe vers l'adresse IP publique de l'équilibreur de charge. [LB_IP] représente l'adresse IP externe de l'instance backend déterminée précédemment.
REACT_APP_ORDERS_URL=http://[LB_IP]/api/orders REACT_APP_PRODUCTS_URL=http://[LB_IP]/api/products Remarque : Les ports sont supprimés de la nouvelle adresse, car l'équilibreur de charge est configuré pour gérer ce transfert à votre place.

4. Enregistrez le fichier.

5. Exécutez les commandes suivantes pour recompiler react-app, ce qui mettra à jour le code du frontend :

cd ~/monolith-to-microservices/react-app npm install && npm run-script build
6. Exécutez la commande suivante pour copier le code d'application dans votre bucket :
cd ~ rm -rf monolith-to-microservices/*/node_modules gcloud storage cp -r monolith-to-microservices gs://fancy-store-{{{project_0.project_id | Project ID}}}/

Mettre à jour les instances frontend

Maintenant que le code et la configuration ont été modifiés, vous voulez que les instances frontend du groupe d'instances géré récupèrent le nouveau code.

• Étant donné que vos instances récupèrent le code au démarrage, exécutez la commande suivante pour effectuer un redémarrage progressif :
gcloud compute instance-groups managed rolling-action replace fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --max-unavailable 100% Remarque : Dans cet exemple de remplacement progressif, vous indiquez spécifiquement que toutes les machines peuvent être remplacées immédiatement à l'aide du paramètre --max-unavailable. En l'absence de ce paramètre, la commande conserve une instance opérationnelle pendant que les autres instances redémarrent afin d'assurer la disponibilité. Pour accélérer le test, vous demandez le remplacement immédiat de toutes les instances.

Cliquez sur Vérifier ma progression pour valider l'objectif. Mettre à jour les instances frontend

Tester le site Web

1. Après avoir exécuté la commande rolling-action replace, attendez trois minutes le temps que les instances soient traitées, puis vérifiez l'état du groupe d'instances géré. Exécutez la commande suivante pour vérifier que l'état du service affiche HEALTHY (Opérationnel) :
watch -n 2 gcloud compute backend-services get-health fancy-fe-frontend --global
2. Attendez que les deux services affichent un état HEALTHY (Opérationnel).

Exemple de résultat :

backend: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instanceGroups/fancy-fe-mig status: healthStatus: - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-x151 ipAddress: 10.128.0.7 port: 8080 - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-cgrt ipAddress: 10.128.0.11 port: 8080 kind: compute#backendServiceGroupHealth Remarque : Si l'une des instances rencontre un problème et que son état affiche UNHEALTHY (Non opérationnel), elle doit en principe se réparer automatiquement. Attendez que ce processus s'exécute.

Si aucune des instances n'affiche l'état HEALTHY (Opérationnel) après un petit moment, c'est qu'il y a un problème avec la configuration des instances frontend, car l'accès à ces instances sur le port 8080 ne fonctionne pas. Vérifiez ce point en accédant aux instances directement sur le port 8080.
3. Une fois que l'état HEALTHY (Opérationnel) est indiqué pour les deux éléments, quittez la commande watch en appuyant sur Ctrl+C.
Remarque : L'application est accessible depuis http://[LB_IP], où [LB_IP] correspond à l'adresse IP spécifiée pour l'équilibreur de charge dans le résultat de la commande suivante :

gcloud compute forwarding-rules list --global

Vous vérifierez l'application dans la suite de cet atelier.

Tâche 7 : Configurer l'autoscaling de Compute Engine

Jusqu'à présent, vous avez créé deux groupes d'instances gérés comportant chacun deux instances. Cette configuration est totalement fonctionnelle, mais se révèle statique, quelle que soit la charge. Maintenant, vous allez créer une règle d'autoscaling basée sur l'utilisation pour procéder au scaling automatique de chaque groupe d'instances géré.

Redimensionner automatiquement selon l'utilisation

• Pour créer la règle d'autoscaling, exécutez la commande suivante :
gcloud compute instance-groups managed set-autoscaling \ fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --max-num-replicas 2 \ --target-load-balancing-utilization 0.60 gcloud compute instance-groups managed set-autoscaling \ fancy-be-mig \ --zone={{{project_0.default_zone | zone}}} \ --max-num-replicas 2 \ --target-load-balancing-utilization 0.60

Ces commandes créent sur les groupes d'instances gérés un autoscaler qui ajoute automatiquement des instances lorsque l'utilisation de l'équilibreur de charge est supérieure à 60 %, et qui supprime des instances quand cette utilisation est inférieure à 60 %.

Activer le réseau de diffusion de contenu

Une autre fonctionnalité pouvant faciliter le scaling consiste à activer un service de réseau de diffusion de contenu afin d'assurer la mise en cache pour l'instance frontend.

• Exécutez la commande suivante sur le service de frontend :
gcloud compute backend-services update fancy-fe-frontend \ --enable-cdn --global

Lorsqu'un utilisateur demande un contenu à l'équilibreur de charge HTTP(S), la requête aboutit à un service Google Front End (GFE), qui commence par rechercher une réponse à la requête dans le cache Cloud CDN. Si le GFE trouve une réponse mise en cache, il l'envoie à l'utilisateur. C'est ce que l'on appelle un succès de cache.

Si le GFE ne trouve aucune réponse à la requête dans le cache, il adresse une requête directement au backend. S'il reçoit une réponse pouvant être mise en cache, le GFE la stocke dans le cache Cloud CDN, qui pourra alors servir pour les requêtes ultérieures.

Cliquez sur Vérifier ma progression pour valider l'objectif. Configurer l'autoscaling de Compute Engine

Tâche 8 : Mettre à jour le site Web

Mettre à jour le modèle d'instance

Les modèles d'instance existants ne sont pas modifiables. Toutefois, étant donné que vos instances sont sans état et que l'intégralité de la configuration est effectuée au moyen du script de démarrage, il vous suffit de modifier le modèle d'instance si vous voulez changer ses paramètres. Dans cette tâche, vous allez effectuer une modification simple en vue d'utiliser un type de machine plus performant, puis vous déploierez cette modification.

Suivez les étapes ci-dessous pour effectuer les actions suivantes :

• Mettez à jour l'instance frontend, qui constitue la base du modèle d'instance. Lors de la mise à jour, placez un fichier dans la version modifiée de l'image du modèle d'instance, puis mettez à jour le modèle d'instance, déployez le nouveau modèle et vérifiez l'existence du fichier sur les instances du groupe d'instances géré.

• Remplacez le type de machine e2-standard-2 de votre modèle d'instance par e2-small.

1. Exécutez la commande suivante pour modifier le type de machine de l'instance frontend :
gcloud compute instances set-machine-type frontend \ --zone={{{project_0.default_zone | zone}}} \ --machine-type e2-small
2. Exécutez la commande suivante pour créer le modèle d'instance :
gcloud compute instance-templates create fancy-fe-new \ --region=$REGION \ --source-instance=frontend \ --source-instance-zone={{{project_0.default_zone | zone}}}
3. Déployez le modèle d'instance modifié sur le groupe d'instances géré à l'aide de la commande suivante :
gcloud compute instance-groups managed rolling-action start-update fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --version template=fancy-fe-new
4. Attendez trois minutes, puis exécutez la commande suivante pour surveiller l'état de la mise à jour :
watch -n 2 gcloud compute instance-groups managed list-instances fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}}

Ce processus prend plusieurs minutes.

Avant de continuer, assurez-vous qu'au moins une instance présente l'état suivant :

• STATUS (État) : RUNNING (En cours d'exécution)
• ACTION : None (Aucune)
• INSTANCE_TEMPLATE (Modèle_d'instance) : nom du nouveau modèle (fancy-fe-new)

5. Copiez le nom de l'une des machines listées pour l'utiliser dans la commande suivante.

6. Appuyez sur Ctrl+C pour quitter le processus watch.

7. Pour vérifier si la machine virtuelle utilise le nouveau type de machine (e2-small), exécutez la commande suivante, où [VM_NAME] est l'instance que vous venez de créer :

gcloud compute instances describe [VM_NAME] --zone={{{project_0.default_zone | zone}}} | grep machineType

Exemple de résultat attendu :

machineType: https://www.googleapis.com/compute/v1/projects/project-name/zones/us-central1-f/machineTypes/e2-small

Apporter des modifications au site Web

Scénario : votre équipe marketing vous a demandé de modifier la page d'accueil de votre site. Elle estime en effet que cette page doit fournir plus d'informations sur l'entreprise et sur les produits qu'elle commercialise.

Dans cette section, vous allez ajouter du texte à la page d'accueil pour répondre aux attentes de l'équipe marketing. L'un des développeurs a déjà spécifié les modifications souhaitées dans le fichier index.js.new. Il vous suffit donc de copier le contenu de ce fichier dans le fichier index.js pour répercuter ces modifications. Suivez les instructions ci-dessous pour apporter les changements appropriés.

1. Exécutez ces commandes pour créer une copie du fichier mis à jour sous le nom de fichier correct :
cd ~/monolith-to-microservices/react-app/src/pages/Home mv index.js.new index.js
2. Affichez le contenu du fichier pour vérifier les modifications :
cat ~/monolith-to-microservices/react-app/src/pages/Home/index.js

Le code obtenu doit ressembler au résultat suivant.

Résultat :

/* Copyright 2019 Google LLC Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ import React from "react"; import { Box, Paper, Typography } from "@mui/material"; export default function Home() { return ( <Box sx={{ flexGrow: 1 }}> <Paper elevation={3} sx={{ width: "800px", margin: "0 auto", padding: (theme) => theme.spacing(3, 2), }} > <Typography variant="h5">Welcome to the Fancy Store!</Typography> <br /> <Typography variant="body1"> Take a look at our wide variety of products. </Typography> </Paper> </Box> ); }

Vous avez mis à jour les composants React, mais vous devez compiler l'application React pour générer les fichiers statiques.

3. Exécutez la commande suivante pour compiler l'application React et la copier dans le répertoire public "monolith" :
cd ~/monolith-to-microservices/react-app npm install && npm run-script build
4. Ensuite, exécutez la commande suivante pour retransférer ce code vers le bucket :
cd ~ rm -rf monolith-to-microservices/*/node_modules gcloud storage cp -r monolith-to-microservices gs://fancy-store-{{{project_0.project_id | Project ID}}}/

Déployer les modifications à l'aide de remplacements progressifs

1. Maintenant, forcez le remplacement de toutes les instances pour récupérer la mise à jour :
gcloud compute instance-groups managed rolling-action replace fancy-fe-mig \ --zone={{{project_0.default_zone | zone}}} \ --max-unavailable=100%

Remarque : Dans cet exemple de remplacement progressif, vous indiquez spécifiquement que toutes les machines peuvent être remplacées immédiatement par l'intermédiaire du paramètre --max-unavailable. En l'absence de ce paramètre, la commande conserve une instance opérationnelle pendant le remplacement des autres instances. Pour accélérer le test, vous demandez le remplacement immédiat de toutes les instances. Dans un environnement de production, conserver un tampon permet de garder le site Web opérationnel pendant la mise à jour.

Cliquez sur Vérifier ma progression pour valider l'objectif. Mettre à jour le site Web

2. Après avoir exécuté la commande rolling-action replace, attendez trois minutes le temps que les instances soient traitées, puis vérifiez l'état du groupe d'instances géré. Exécutez la commande suivante pour vérifier que l'état du service affiche HEALTHY (Opérationnel) :
watch -n 2 gcloud compute backend-services get-health fancy-fe-frontend --global
3. Attendez quelques instants que les deux services indiquent un état HEALTHY (Opérationnel).

Exemple de résultat :

backend: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instanceGroups/fancy-fe-mig status: healthStatus: - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-x151 ipAddress: 10.128.0.7 port: 8080 - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/my-gce-codelab/zones/us-central1-a/instances/fancy-fe-cgrt ipAddress: 10.128.0.11 port: 8080 kind: compute#backendServiceGroupHealth

4. Une fois que les éléments indiquent un état HEALTHY (Opérationnel), quittez la commande watch en appuyant sur Ctrl+C.

5. Accédez au site Web depuis http://[LB_IP], où [LB_IP] correspond à l'adresse IP spécifiée pour l'équilibreur de charge dans le résultat de la commande suivante :

gcloud compute forwarding-rules list --global

Les nouvelles modifications du site Web doivent maintenant être visibles.

Simuler une défaillance

Pour vous assurer que la vérification d'état fonctionne, vous décidez de vous connecter à une instance et d'arrêter les services.

1. Pour rechercher un nom d'instance, exécutez la commande suivante :
gcloud compute instance-groups list-instances fancy-fe-mig --zone={{{project_0.default_zone | zone}}}
2. Copiez un nom d'instance, puis exécutez la commande suivante pour accéder à l'instance en SSH, où "INSTANCE_NAME" désigne l'une des instances de la liste :
gcloud compute ssh [INSTANCE_NAME] --zone={{{project_0.default_zone | zone}}}

3. Saisissez "y" pour confirmer, puis appuyez deux fois sur Entrée pour ne pas utiliser de mot de passe.

4. Dans l'instance, exécutez la commande suivante pour utiliser supervisorctl afin d'arrêter l'application :

sudo supervisorctl stop nodeapp; sudo killall node
5. Exécutez la commande suivante pour quitter l'instance :
exit
6. Surveillez les opérations de réparation :
watch -n 2 gcloud compute operations list \ --filter='operationType~compute.instances.repair.*'

Cette opération prend plusieurs minutes.

Recherchez l'exemple de résultat suivant.

Résultat :

NAME: repair-1755080598062-63c3c8b99843b-eed8dabc-f1833ea3 TYPE: compute.instances.repair.recreateInstance TARGET: us-east4-c/instances/fancy-fe-tn40 HTTP_STATUS: 200 STATUS: DONE TIMESTAMP: 2025-08-13T03:23:18.062-07:00

Le groupe d'instances géré a recréé l'instance pour la réparer.

7. Vous pouvez également surveiller la réparation depuis la console en accédant au menu de navigation > Compute Engine > Instances de VM.

Félicitations !

Vous avez assuré le déploiement, le scaling et la mise à jour de votre site Web sur Compute Engine. Vous savez maintenant utiliser Compute Engine, les groupes d'instances gérés, les équilibreurs de charge et les vérifications d'état.

Étapes suivantes et informations supplémentaires

• Autoréparation et vérifications d'état dans les groupes d'instances gérés
• Vidéo d'une étude de cas portant sur l'hébergement d'applications Web évolutives sur Google Cloud

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 19 juin 2026

Dernier test de l'atelier : 19 juin 2026

Copyright 2026 Google LLC. Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.