Hébergez et faites évoluer une application Web dans Google Cloud avec Compute Engine

1. Introduction

Il existe de nombreuses manières de déployer des sites Web dans Google Cloud, chacune d'elles offrant des fonctionnalités, possibilités et niveaux de contrôle spécifiques. 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, 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, l'équilibreur de charge, etc. Aujourd'hui, vous allez déployer un exemple d'application, le site Web d'e-commerce Fancy Store, pour découvrir comment effectuer le déploiement et le scaling d'un site Web en toute facilité avec Compute Engine.

Points abordés

• 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
• Configurer les vérifications d'état et l'autoréparation
• Créer un équilibreur de charge HTTP(S)
• Créer des vérifications de l'état pour les équilibreurs de charge
• Utiliser un réseau de diffusion de contenu 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érequis

• Pour obtenir une présentation des concepts que nous utiliserons dans cet atelier, veuillez consulter les ressources ci-dessous :
• Bienvenue sur Google Cloud Platform : les bases de GCP
• Premiers pas avec Google Cloud Compute Engine
• Premiers pas avec Google Cloud Storage
• Premiers pas : Cloud Shell

2. Configuration de l'environnement

Configuration de l'environnement au rythme de chacun

1. Connectez-vous à la console 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.)

Remarque : Vous pouvez facilement accéder à la console Cloud en mémorisant son URL, à savoir console.cloud.google.com.

Mémorisez l'ID du projet. Il s'agit d'un nom unique permettant de différencier chaque projet Google Cloud (le nom ci-dessus est déjà pris ; vous devez en trouver un autre). Il sera désigné par le nom PROJECT_ID tout au long de cet atelier de programmation.

Remarque : Si vous utilisez un compte Gmail, vous pouvez conserver l'emplacement par défaut défini sur Aucune organisation. Si vous utilisez un compte Google Workspace, choisissez un emplacement pertinent pour votre organisation.

2. Vous devez ensuite activer la facturation dans Cloud Console pour pouvoir utiliser les ressources Google Cloud.

L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Veillez à suivre les instructions de la section "Nettoyer" qui indique comment désactiver les ressources afin d'éviter les frais une fois ce tutoriel terminé. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300$.

Remarque : Il est important de créer un projet et de ne pas en réutiliser un existant, car vous supprimerez le projet pour effacer toutes les activités effectuées dans l'atelier de programmation.

Activer l'API Compute Engine

Vous devez ensuite activer l'API Compute Engine. Pour activer une API, vous devez accepter les conditions d'utilisation et la responsabilité de la facturation de cette API.

Dans Cloud Shell, exécutez la commande suivante pour activer l'API Compute Engine :

gcloud services enable compute.googleapis.com

Cloud Shell

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

Cette machine virtuelle basée sur Debian contient tous les outils de développement dont vous aurez besoin. Elle intègre 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. Cela signifie que tout ce dont vous avez besoin pour cet atelier de programmation est un navigateur (oui, tout fonctionne sur un Chromebook).

1. Pour activer Cloud Shell à partir de Cloud Console, cliquez simplement sur Activer Cloud Shell (l'opération de provisionnement et la connexion à l'environnement ne devraient prendre que quelques minutes).

Une fois connecté à Cloud Shell, vous êtes normalement déjà authentifié et le projet PROJECT_ID est sélectionné :

gcloud auth list

Résultat de la commande

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)

Remarque : L'outil de ligne de commande gcloud est préinstallé dans Cloud Shell. Vous en apprécierez certainement les fonctionnalités de saisie semi-automatique accessibles via la touche de tabulation. Pour en savoir plus, consultez la section présentation de l'outil de ligne de commande gcloud.

gcloud config list project

Résultat de la commande

[core]
project = <PROJECT_ID>

Si, pour une raison quelconque, le projet n'est pas défini, exécutez simplement la commande suivante :

gcloud config set project <PROJECT_ID>

Vous recherchez votre PROJECT_ID ? Vérifiez l'ID que vous avez utilisé pendant les étapes de configuration ou recherchez-le dans le tableau de bord Cloud Console :

Par défaut, Cloud Shell définit certaines variables d'environnement qui pourront s'avérer utiles pour exécuter certaines commandes dans le futur.

echo $GOOGLE_CLOUD_PROJECT

Résultat de la commande

<PROJECT_ID>

2. Pour finir, définissez la configuration du projet et de la zone par défaut :

gcloud config set compute/zone us-central1-f

Vous pouvez choisir parmi différentes zones. Pour en savoir plus, consultez la page Régions et zones.

Remarque : Lorsque vous exécutez gcloud sur votre propre machine, les paramètres de configuration sont conservés d'une session à l'autre. Toutefois, dans Cloud Shell, vous devrez définir ce paramètre à chaque nouvelle session ou reconnexion.

Créer un bucket Cloud Storage

Nous allons utiliser un bucket Cloud Storage pour héberger notre code compilé et nos scripts de démarrage. Dans Cloud Shell, exécutez la commande suivante pour créer un bucket Cloud Storage :

gsutil mb gs://fancy-store-$DEVSHELL_PROJECT_ID

Remarque : Vous utiliserez la variable d'environnement $DEVSHELL_PROJECT_ID dans Cloud Shell pour vous assurer que les noms des objets sont uniques. Étant donné que tous les ID de projet Google Cloud doivent être uniques, ajouter l'ID devrait garantir l'unicité des autres noms.

3. Cloner le dépôt source

Vous allez baser votre site Web sur le site Web d'e-commerce Fancy Store existant, qui repose sur le dépôt monolith-to-microservices. Vous allez cloner le code source de votre dépôt, ce qui vous permettra de vous concentrer sur les différents aspects du déploiement sur Compute Engine. Vous modifierez légèrement le code pour expérimenter la simplicité du processus de mise à jour dans Compute Engine.

Vous pouvez cloner automatiquement le dépôt de code dans le projet, ainsi qu'ouvrir Cloud Shell et l'éditeur de code intégré, en cliquant sur le lien suivant : Ouvrir dans Cloud Shell.

Vous pouvez également cloner manuellement le dépôt à l'aide des commandes ci-dessous dans Cloud Shell :

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

À l'invite de commande Cloud Shell, exécutez la compilation initiale du code pour permettre à l'application de s'exécuter localement. L'exécution du script peut prendre quelques minutes.

./setup.sh

Faites preuve de diligence raisonnable et testez votre application. Exécutez la commande suivante pour démarrer votre serveur Web :

cd microservices
npm start

Résultat :

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

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.

Vous pouvez fermer cette fenêtre après avoir consulté le site Web. Pour arrêter le processus du serveur Web, appuyez sur Control+C (Command+C sur Macintosh) dans la fenêtre de terminal.

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

4. Créer des instances Compute Engine

Maintenant que votre environnement de développement est opérationnel, vous pouvez déployer des instances Compute Engine. Au cours des étapes suivantes, vous allez :

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

Dans le ruban Cloud Shell, cliquez sur l'icône en forme de crayon pour ouvrir l'éditeur de code.

Accédez au dossier "monolith-to-microservices". Cliquez sur Fichier > Nouveau fichier, puis créez un fichier nommé startup-script.sh.

Dans le nouveau fichier, collez le code suivant (vous en modifierez une partie après l'avoir collé) :

#!/bin/bash

# Install logging monitor. The monitor will automatically pick up logs sent to
# syslog.
curl -s "https://storage.googleapis.com/signals-agents/logging/google-fluentd-install.sh" | bash
service google-fluentd restart &

# Install dependencies from apt
apt-get update
apt-get install -yq ca-certificates git build-essential supervisor psmisc

# Install nodejs
mkdir /opt/nodejs
curl https://nodejs.org/dist/v8.12.0/node-v8.12.0-linux-x64.tar.gz | tar xvzf - -C /opt/nodejs --strip-components=1
ln -s /opt/nodejs/bin/node /usr/bin/node
ln -s /opt/nodejs/bin/npm /usr/bin/npm

# Get the application source code from the Google Cloud Storage bucket.
mkdir /fancy-store
gsutil -m cp -r gs://fancy-store-[DEVSHELL_PROJECT_ID]/monolith-to-microservices/microservices/* /fancy-store/

# Install app dependencies.
cd /fancy-store/
npm install

# Create a nodeapp user. The application will run as this user.
useradd -m -d /home/nodeapp nodeapp
chown -R nodeapp:nodeapp /opt/app

# Configure supervisor to run the node app.
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

Dans l'éditeur de code, recherchez le texte [DEVSHELL_PROJECT_ID] et remplacez-le par le résultat de la commande suivante :

echo $DEVSHELL_PROJECT_ID

Exemple de résultat :

my-gce-codelab-253520

La ligne de code dans startup-script.sh doit maintenant être semblable à celle-ci :

gs://fancy-store-my-gce-codelab-253520/monolith-to-microservices/microservices/* /fancy-store/

Remarque : Si vous utilisez l'éditeur de code dans 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). Vous pouvez vérifier ce point en bas à droite de l'éditeur de code :

Si cette option est définie sur "CRLF", cliquez sur "CRLF", puis sélectionnez "LF" dans le menu déroulant.

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

• Installation de l'agent Logging, qui collecte automatiquement les journaux de syslog
• Installation de Node.js et de Supervisor, qui exécute l'application en tant que daemon
• Clonage du code source de l'application à partir du bucket Cloud Storage et installation des dépendances
• Configuration de Supervisor, qui exécute l'application, 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, et envoie les fichiers stdout et stderr de l'application à syslog pour qu'ils soient collectés par l'agent Logging.

Copiez maintenant le fichier startup-script.sh créé dans le bucket Cloud Storage que vous avez créé précédemment :

gsutil cp ~/monolith-to-microservices/startup-script.sh gs://fancy-store-$DEVSHELL_PROJECT_ID

Il est à présent accessible à l'adresse https://storage.googleapis.com/[BUCKET_NAME]/startup-script.sh. [BUCKET_NAME] représente le nom du bucket Cloud Storage. Cet emplacement est uniquement visible par les utilisateurs autorisés et par les comptes de service par défaut. Il est donc inaccessible par l'intermédiaire d'un navigateur Web. Les instances Compute Engine y auront automatiquement accès via leur compte de service.

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, la méthode mentionnée constitue un moyen simple de gérer la configuration. En production, les variables d'environnement seraient probablement stockées à l'extérieur du code.

Copiez le code cloné dans le bucket Cloud Storage :

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

Remarque : Supprimez les répertoires de dépendances "node_modules" pour que le code soit le plus rapide et efficace possible. Ils sont recréés sur les instances lorsqu'elles démarrent.

Déployer l'instance backend

La première instance que vous déployez 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 de backend (commandes et produits) résideront dans la même instance et le même groupe d'instances.

Exécutez la commande suivante dans Cloud Shell pour créer une instance f1-micro configurée pour utiliser le script de démarrage que vous avez créé précédemment et taguée en tant qu'instance de backend afin de pouvoir lui appliquer des règles de pare-feu spécifiques ultérieurement :

gcloud compute instances create backend \
    --machine-type=f1-micro \
    --image=debian-9-stretch-v20190905 \
    --image-project=debian-cloud \
    --tags=backend \
    --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh

Remarque : Si l'API Compute Engine n'a pas été activée lors des étapes précédentes, l'outil de ligne de commande gcloud vous demandera si vous souhaitez l'activer et réessayer (cela prendra quelques minutes). Veuillez sélectionner "y" pour activer l'API Compute Engine.

Remarque : Si vous êtes invité à spécifier une zone, assurez-vous qu'une zone par défaut a été configurée précédemment dans la section "Configuration de l'environnement".

Configurer la 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 avez déployé.

Récupérez l'adresse IP externe du backend, qui peut être consultée à partir de la commande suivante sous l'onglet EXTERNAL_IP de l'instance backend :

gcloud compute instances list

Exemple de résultat :

NAME     ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP   STATUS
backend  us-central1-a  f1-micro                   10.128.0.2   34.68.223.88  RUNNING

Dans l'éditeur de code Cloud Shell, accédez au dossier monolith-to-microservices > react-app. Dans le menu de l'éditeur de code, sélectionnez Affichage > Activer/Désactiver les fichiers cachés pour afficher le fichier .env.

Modifiez le fichier .env pour qu'il pointe vers l'adresse IP externe du backend. [BACKEND_ADDRESS] ci-dessous représente l'adresse IP externe de l'instance backend déterminée à partir de la commande précédente dans l'outil gcloud.

REACT_APP_ORDERS_URL=http://[BACKEND_ADDRESS]:8081/api/orders
REACT_APP_PRODUCTS_URL=http://[BACKEND_ADDRESS]:8082/api/products

Enregistrez le fichier.

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

Copiez le code de l'application dans le bucket Cloud Storage :

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

Déployer l'instance frontend

Maintenant que le code est configuré, vous pouvez 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), mais cette instance est dotée du tag "frontend" pour les besoins du pare-feu.

gcloud compute instances create frontend \
    --machine-type=f1-micro \
    --image=debian-9-stretch-v20190905 \
    --image-project=debian-cloud \
    --tags=frontend \
    --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh 

Remarque : Vous utilisez une commande de déploiement et un script de démarrage similaires pour les instances frontend et backend. C'est 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 l'exemple. Toutefois, dans un environnement de production, vous exécuteriez uniquement les microservices dont vous avez besoin sur chaque composant.

Configurer le réseau

Créez des règles de pare-feu afin d'autoriser l'accès au port 8080 pour le frontend, et aux ports 8081 et 8082 pour le backend. Les 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 devrait maintenant être fonctionnel. Déterminez l'adresse IP externe du frontend. Vous pouvez déterminer l'adresse en recherchant l'adresse IP externe de l'instance frontend :

gcloud compute instances list

Exemple de résultat :

NAME      ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP      STATUS
backend   us-central1-a  f1-micro                   10.128.0.2   104.198.235.171  RUNNING
frontend  us-central1-a  f1-micro                   10.128.0.3   34.69.141.9      RUNNING

Le démarrage et la configuration de l'instance peuvent prendre quelques minutes. Exécutez la commande suivante pour surveiller l'état de préparation de l'application :

watch -n 5 curl http://[EXTERNAL_IP]:8080 

Une fois que vous obtenez un résultat semblable à celui qui suit, le site Web est prêt. Appuyez sur Control+C (Command+C sur Macintosh) à l'invite de commande pour annuler la commande watch.

Accédez à http://[FRONTEND_ADDRESS]:8080 dans un nouvel onglet de navigateur pour accéder au site Web, où [FRONTEND_ADDRESS] correspond à l'adresse IP externe déterminée ci-dessus.

Essayez d'accéder aux pages "Produits" et "Commandes", qui devraient également fonctionner.

Remarque : Si vous vous arrêtez à ce stade et choisissez de ne pas mettre à l'échelle l'environnement, les instances doivent être configurées pour utiliser des adresses IP statiques. Vous devez continuer à créer des groupes d'instances gérés et un équilibreur de charge, même si une grande échelle n'est pas nécessaire, afin de pouvoir implémenter la redondance et l'autoréparation.

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

Pour permettre le scaling de votre 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é 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 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 de conteneur, le réseau, ainsi que d'autres propriétés d'instance à utiliser lors de la création d'instances de machines virtuelles (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.

Vous devez d'abord arrêter les deux instances.

gcloud compute instances stop frontend

gcloud compute instances stop backend

Créez ensuite le modèle d'instance à partir des instances sources.

gcloud compute instance-templates create fancy-fe \
    --source-instance=frontend

gcloud compute instance-templates create fancy-be \
    --source-instance=backend

Vérifiez que les modèles d'instance ont été créés :

gcloud compute instance-templates list

Exemple de résultat :

NAME      MACHINE_TYPE  PREEMPTIBLE  CREATION_TIMESTAMP
fancy-be  f1-micro                   2019-09-12T07:52:57.544-07:00
fancy-fe  f1-micro                   2019-09-12T07:52:48.238-07:00

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

Vous allez créer deux groupes d'instances gérés, l'un pour le frontend et l'autre pour le backend. Ces groupes d'instances gérés utiliseront les modèles d'instance créés précédemment et seront configurés pour démarrer deux instances chacun. Les instances seront 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.

gcloud compute instance-groups managed create fancy-fe-mig \
    --base-instance-name fancy-fe \
    --size 2 \
    --template fancy-fe

gcloud compute instance-groups managed create fancy-be-mig \
    --base-instance-name fancy-be \
    --size 2 \
    --template fancy-be

Dans le cas de votre application, le microservice frontend s'exécute sur le port 8080, tandis que les microservices backend s'exécutent sur le port 8081 pour les commandes et sur le port 8082 pour les produits. É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 l'équilibreur de charge, que vous configurerez ultérieurement.

gcloud compute instance-groups set-named-ports fancy-fe-mig \ 
    --named-ports frontend:8080

gcloud compute instance-groups set-named-ports fancy-be-mig \
    --named-ports orders:8081,products:8082

Configurer l'autoréparation

Pour améliorer la disponibilité de l'application proprement dite et vérifier qu'elle répond, vous pouvez configurer 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 : Vous utiliserez des vérifications d'état distinctes pour l'équilibreur de charge et l'autoréparation. Les vérifications de l'état qui s'appliquent à l'équilibreur 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.

Créez une vérification d'état qui répare l'instance si elle renvoie la valeur "unhealthy" (non opérationnelle) trois fois de suite pour le frontend et le 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

Créez une règle de pare-feu pour autoriser les vérifications d'état à se connecter aux microservices sur les ports 8080 et 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

Appliquez les vérifications d'état à leurs services respectifs :

gcloud compute instance-groups managed update fancy-fe-mig \
    --health-check fancy-fe-hc \
    --initial-delay 300

gcloud compute instance-groups managed update fancy-be-mig \
    --health-check fancy-be-hc \
    --initial-delay 300

Remarque : L'autoréparation peut mettre 15 minutes avant de commencer à surveiller les instances du groupe.

Poursuivez l'atelier de programmation 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.

6. Créer un équilibreur de charge

Pour compléter nos groupes d'instances gérés, vous allez utiliser l'équilibrage de charge HTTP(S) afin d'acheminer le trafic vers les microservices frontend et backend. Vous aurez également recours à des mappages pour envoyer le trafic aux services de backend appropriés en fonction des règles de chemin d'accès. Cela exposera une seule adresse IP à équilibrage de charge pour tous les services.

Pour en savoir plus sur les options d'équilibrage de charge disponibles dans Google Cloud, consultez la page Présentation de Cloud Load Balancing.

Créer un équilibreur de charge HTTP(S)

Google Cloud propose de nombreux types d'équilibrage de charge, mais vous utiliserez l'équilibrage de charge HTTP(S) pour votre trafic. L'équilibrage de charge HTTP(S) est structuré de la manière suivante :

1. Une règle de transfert dirige les requêtes entrantes vers un proxy HTTP cible.
2. 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.
3. 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.
4. 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 éviter les certificats SSL complexes, vous utiliserez HTTP plutôt que HTTPS. Dans un environnement de production, il est recommandé d'utiliser HTTPS pour le chiffrement chaque fois que cela est possible.

Créez des vérifications d'état qui serviront à déterminer les instances capables d'acheminer le trafic pour chaque service.

gcloud compute http-health-checks create fancy-fe-frontend-hc \
  --request-path / \
  --port 8080

gcloud compute http-health-checks create fancy-be-orders-hc \
  --request-path /api/orders \
  --port 8081

gcloud compute http-health-checks create fancy-be-products-hc \
  --request-path /api/products \
  --port 8082

Remarque : Les vérifications de l'é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.

Créez les services de backend qui constituent la cible du trafic à équilibrage de charge. Les services de backend utiliseront les vérifications d'état et les ports nommés que vous avez créés.

gcloud compute backend-services create fancy-fe-frontend \
  --http-health-checks fancy-fe-frontend-hc \
  --port-name frontend \
  --global

gcloud compute backend-services create fancy-be-orders \
  --http-health-checks fancy-be-orders-hc \
  --port-name orders \
  --global

gcloud compute backend-services create fancy-be-products \
  --http-health-checks fancy-be-products-hc \
  --port-name products \
  --global

Ajoutez les services de backend.

gcloud compute backend-services add-backend fancy-fe-frontend \
  --instance-group fancy-fe-mig \
  --instance-group-zone us-central1-f \
  --global

gcloud compute backend-services add-backend fancy-be-orders \
  --instance-group fancy-be-mig \
  --instance-group-zone us-central1-f \
  --global

gcloud compute backend-services add-backend fancy-be-products \
  --instance-group fancy-be-mig \
  --instance-group-zone us-central1-f \
  --global

Créez un mappage d'URL. Le mappage d'URL définit les URL à diriger vers des services de backend spécifiques.

gcloud compute url-maps create fancy-map \
  --default-service fancy-fe-frontend

Créez un outil de mise en correspondance des chemins d'accès pour autoriser 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"

Créez le proxy associé au mappage d'URL créé.

gcloud compute target-http-proxies create fancy-proxy \
  --url-map fancy-map

Créez 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

Mettre à jour la configuration

Maintenant que vous disposez d'une nouvelle adresse IP statique, vous devez modifier 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.

Dans Cloud Shell, accédez au dossier "react-app" qui héberge le fichier .env contenant la configuration.

cd ~/monolith-to-microservices/react-app/

Recherchez l'adresse IP de l'équilibreur de charge :

gcloud compute forwarding-rules list --global

Exemple de résultat :

NAME                    REGION  IP_ADDRESS     IP_PROTOCOL  TARGET
fancy-http-rule          34.102.237.51  TCP          fancy-proxy

Modifiez le fichier .env avec l'éditeur de texte de votre choix (GNU nano, par exemple) 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.

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 le transfert à votre place.

Recompilez react-app, ce qui mettra à jour le code du frontend.

cd ~/monolith-to-microservices/react-app
npm install && npm run-script build

Copiez le code d'application dans le bucket GCS.

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

Mettre à jour les instances frontend

Maintenant, vous voulez que les instances frontend du groupe d'instances géré récupèrent le nouveau code. Vos instances récupèrent le code au démarrage. Vous pouvez donc exécuter une commande de redémarrage progressif.

gcloud compute instance-groups managed rolling-action restart fancy-fe-mig \
    --max-unavailable 100%

Remarque : Dans cet exemple de redémarrage progressif, vous indiquez spécifiquement que toutes les machines peuvent être redémarré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. Pour accélérer le test, demandez le redémarrage immédiat de toutes les instances.

Tester le site Web

Après avoir exécuté la commande rolling-action restart, attendez environ 30 secondes le temps que les instances soient traitées. Vérifiez ensuite l'état du groupe d'instances géré jusqu'à ce que les instances apparaissent dans la liste.

watch -n 5 gcloud compute instance-groups list-instances fancy-fe-mig

Une fois les éléments visibles dans la liste, quittez la commande watch en appuyant sur Control+C (Command+C sur Macintosh).

Vérifiez que le service est indiqué comme étant opérationnel.

watch -n 5 gcloud compute backend-services get-health fancy-fe-frontend --global

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

Une fois ces éléments visibles dans la liste, quittez la commande watch en appuyant sur Control+C (Command+C sur Macintosh).

L'application sera alors accessible via http://[IP_D'ÉQUILIBREUR], où [IP_D'ÉQUILIBREUR] correspond à l'adresse IP spécifiée pour l'équilibreur de charge dans la sortie de la commande suivante :

gcloud compute forwarding-rules list --global

7. Procéder au scaling 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 les commandes suivantes dans Cloud Shell. Il créera un autoscaler sur les groupes d'instances gérés qui ajoutera automatiquement des instances lorsque l'utilisation de l'équilibreur de charge sera supérieure à 60 %, et qui supprimera des instances quand cette utilisation sera inférieure à 60 %.

gcloud compute instance-groups managed set-autoscaling \
  fancy-fe-mig \
  --max-num-replicas 5 \
  --target-load-balancing-utilization 0.60

gcloud compute instance-groups managed set-autoscaling \
  fancy-be-mig \
  --max-num-replicas 5 \
  --target-load-balancing-utilization 0.60

Activer le réseau de diffusion de contenu

Une autre fonctionnalité pouvant faciliter le scaling consiste à activer Cloud CDN, un service de réseau de diffusion de contenu, afin d'assurer la mise en cache pour le service frontend. Pour ce faire, vous pouvez exécuter la commande suivante sur votre service de frontend :

gcloud compute backend-services update fancy-fe-frontend \
    --enable-cdn --global

Désormais, lorsqu'un utilisateur demande du contenu à l'équilibreur de charge, la requête aboutit à un service Google Front End, qui commence par rechercher une réponse à la requête dans le cache Cloud CDN. Si le frontend trouve une réponse mise en cache, il l'envoie à l'utilisateur. C'est ce qu'on appelle un succès de cache.

Dans le cas contraire, si l'interface ne trouve aucune réponse à la requête dans le cache, elle adresse une requête directement au backend. Si la réponse à cette requête peut être mise en cache, l'interface la stocke dans le cache Cloud CDN, qui pourra servir pour les requêtes ultérieures.

8. Mettre à jour le site Web

Mettre à jour le modèle d'instance

Il n'est pas possible de modifier les modèles d'instance existants. Toutefois, étant donné que vos instances sont sans état et que l'intégralité de la configuration est effectuée via le script de démarrage, il vous suffit de modifier le modèle d'instance si vous voulez changer ses paramètres ou l'image de base elle-même. Dans cette section, vous allez effectuer une modification simple en vue d'utiliser un type de machine plus performant, puis vous déploierez cette modification.

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

Vous allez remplacer le type de machine standard f1-micro de votre modèle d'instance par un type de machine personnalisé comportant quatre vCPU et 3 840 Mio de RAM.

Dans Cloud Shell, exécutez la commande suivante pour modifier le type de machine de l'instance frontend :

gcloud compute instances set-machine-type frontend --machine-type custom-4-3840

Créez le modèle d'instance :

gcloud compute instance-templates create fancy-fe-new \
    --source-instance=frontend \
    --source-instance-zone=us-central1-a

Déployez le modèle d'instance modifié sur le groupe d'instances géré :

gcloud compute instance-groups managed rolling-action start-update fancy-fe-mig \
    --version template=fancy-fe-new

Surveillez l'état de la mise à jour :

watch -n 2 gcloud compute instance-groups managed list-instances fancy-fe-mig

Une fois qu'au moins l'une des instances présente l'état RUNNING, que l'ACTION est définie sur None et que INSTANCE_TEMPLATE est défini sur le nouveau nom de modèle (fancy-fe-new), copiez le nom de l'une des machines listées pour l'utiliser dans la commande suivante.

Control+S (Command+S sur Macintosh) pour quitter le processus de visionnage.

Exécutez la commande suivante pour voir si la machine virtuelle utilise le nouveau type de machine (custom-4-3840), où [NOM_DE_VM] est l'instance que vous venez de créer :

gcloud compute instances describe [VM_NAME] | grep machineType

Exemple de résultat attendu :

machineType: https://www.googleapis.com/compute/v1/projects/project-name/zones/us-central1-f/machineTypes/custom-4-3840

Apporter des modifications au site Web

Votre équipe marketing vous demande de modifier la page d'accueil de votre site. Elle estime en effet que cette page doit fournir plus d'informations sur votre 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 de vos développeurs a déjà spécifié les modifications souhaitées dans le fichier index.js.new. Vous pouvez copier le fichier dans index.js pour que vos modifications soient prises en compte. Suivez les instructions ci-dessous pour apporter les changements appropriés.

Exécutez les commandes suivantes pour copier le fichier mis à jour sous le nom de fichier correct, puis affichez le contenu de ce fichier pour vérifier les modifications :

cd ~/monolith-to-microservices/react-app/src/pages/Home
mv index.js.new index.js
cat ~/monolith-to-microservices/react-app/src/pages/Home/index.js

Le code obtenu doit se présenter comme suit :

/*
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 { makeStyles } from "@material-ui/core/styles";
import Paper from "@material-ui/core/Paper";
import Typography from "@material-ui/core/Typography";
const useStyles = makeStyles(theme => ({
  root: {
    flexGrow: 1
  },
  paper: {
    width: "800px",
    margin: "0 auto",
    padding: theme.spacing(3, 2)
  }
}));
export default function Home() {
  const classes = useStyles();
  return (
    <div className={classes.root}>
      <Paper className={classes.paper}>
        <Typography variant="h5">
          Fancy Fashion &amp; Style Online
        </Typography>
        <br />
        <Typography variant="body1">
          Tired of mainstream fashion ideas, popular trends and societal norms?
          This line of lifestyle products will help you catch up with the Fancy trend and express your personal style.
          Start shopping Fancy items now!
        </Typography>
      </Paper>
    </div>
  );
}

Vous avez mis à jour les composants React, mais vous devez compiler l'application React pour générer les fichiers statiques. 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

Ensuite, transférez à nouveau le code vers votre bucket Cloud Storage.

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

Déployer les modifications à l'aide de mises à jour progressives

Vous pouvez maintenant forcer le redémarrage de toutes les instances pour récupérer la mise à jour.

gcloud compute instance-groups managed rolling-action restart fancy-fe-mig \
    --max-unavailable=100%

Remarque : Dans cet exemple de redémarrage progressif, vous indiquez spécifiquement que toutes les machines peuvent être redémarré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. Pour accélérer le test, vous demandez le redémarrage 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.

Après avoir exécuté la commande rolling-action restart, attendez environ 30 secondes le temps que les instances soient traitées, puis vérifiez l'état du groupe d'instances géré jusqu'à ce que les instances apparaissent dans la liste.

watch -n 5 gcloud compute instance-groups list-instances fancy-fe-mig

Une fois ces éléments visibles dans la liste, quittez la commande watch en appuyant sur Control+S (Command+S sur Macintosh).

Exécutez la commande suivante pour vérifier que le service est répertorié comme opérationnel :

watch -n 5 gcloud compute backend-services get-health fancy-fe-frontend --global

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

Une fois les éléments visibles dans la liste, quittez la commande watch en appuyant sur Control+S (Command+S sur Macintosh).

Pour invalider le contenu mis en cache dans le réseau de diffusion de contenu et vous assurer que le contenu actualisé s'affiche, exécutez la commande suivante :

gcloud compute url-maps invalidate-cdn-cache fancy-map \
    --path "/*"

Accédez au site Web via 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.

Remarque : Si le nouveau contenu ne s'affiche pas, actualisez la page Web avec Control+F5 (Command+Shift+R sur Macintosh) dans Google Chrome pour vous assurer que le contenu mis en cache est téléchargé à nouveau.

Simuler une défaillance

Pour vous assurer que la vérification de l'état fonctionne, connectez-vous à une instance et arrêtez les services. Pour rechercher un nom d'instance, exécutez la commande suivante :

gcloud compute instance-groups list-instances fancy-fe-mig

À partir de là, accédez à l'une des instances à l'aide du protocole Secure Shell, où INSTANCE_NAME désigne l'une des instances de la liste :

gcloud compute ssh [INSTANCE_NAME]

Dans l'instance, utilisez supervisorctl pour arrêter l'application.

sudo supervisorctl stop nodeapp; sudo killall node

Quittez l'instance.

exit

Surveillez les opérations de réparation.

watch -n 5 gcloud compute operations list \
--filter='operationType~compute.instances.repair.*'

Recherchez l'exemple de résultat suivant :

NAME                                                  TYPE                                       TARGET                                 HTTP_STATUS  STATUS  TIMESTAMP
repair-1568314034627-5925f90ee238d-fe645bf0-7becce15  compute.instances.repair.recreateInstance  us-central1-a/instances/fancy-fe-1vqq  200          DONE    2019-09-12T11:47:14.627-07:00

Une fois la réparation constatée, appuyez sur Control+C (Command+S sur Macintosh) pour quitter la commande watch. À ce stade, le groupe d'instances géré recrée l'instance pour la réparer.

9. Effectuer un nettoyage

Une fois que vous êtes prêt, le moyen le plus simple de nettoyer toutes les activités effectuées consiste à supprimer le projet. La suppression du projet supprime l'équilibreur de charge, les instances, les modèles et plus encore créés pendant l'atelier de programmation pour éviter toute facturation récurrente inattendue. Exécutez la commande suivante dans Cloud Shell, où PROJECT_ID correspond à l'ID complet du projet, et non uniquement à son nom.

gcloud projects delete [PROJECT_ID]

Pour confirmer la suppression, saisissez "Y" lorsque vous y êtes invité.

Si vous n'êtes pas sûr de l'ID du projet, vous pouvez l'obtenir en exécutant gcloud config list | grep project dans Cloud Shell.

10. Félicitations !

Vous avez déployé, mis à l'échelle et mis à jour votre site Web sur Compute Engine. Vous savez maintenant utiliser Compute Engine, les groupes d'instances gérés, l'équilibrage de charge et les vérifications d'état.