Déployer un serveur Web de récupération tiède avec Compute Engine et Cloud Storage

Last reviewed 2021-06-23 UTC

---

Ce document est destiné aux architectes et aux personnes travaillant dans les équipes opérationnelles et administratives. Ce document décrit un exemple de modèle que vous pouvez utiliser pour vos propres déploiements dans Google Cloud.

Dans cette architecture, un équilibreur de charge dirige le trafic vers des instances Compute Engine dans des groupes d'instances gérés qui diffusent le contenu. En cas de panne, vous mettez à jour la configuration de l'équilibreur de charge d'application externe et basculez vers un site statique dans Cloud Storage.

Pour déployer cette solution, vous avez besoin d'un nom de domaine enregistré que vous contrôlez et souhaitez utiliser avec ce document.

Dans les déploiements de production, votre site Web inclut probablement beaucoup plus de fichiers et de code d'application supplémentaire sur vos machines virtuelles (VM) de groupes d'instances gérés que ce qui est indiqué dans ce document. Cloud Storage héberge ensuite une version statique plus limitée qui offre un minimum de fonctionnalités. Dans un scénario de basculement tiède, les utilisateurs voient ce site Web limité jusqu'à ce que les groupes d'instances gérés puissent récupérer et peuvent diffuser le trafic vers l'ensemble de l'interface.

Architecture

Dans cette architecture, vous allez déployer des ressources pour créer un environnement, comme indiqué dans l'image suivante :

Lorsque vous devez basculer, vous mettez à jour la configuration de l'équilibreur de charge pour diriger le trafic vers Cloud Storage, comme indiqué dans l'image suivante :

Ce modèle de basculement tiède équilibre le coût d'exécution d'un autre groupe d'instances géré dans une autre région que celle utilisée en cas de défaillance des régions principales. Le coût d'un site statique utilisant Cloud Storage est inférieur à l'exécution d'un autre groupe d'instances géré, mais il existe un court délai lorsque vous mettez à jour la configuration de l'équilibreur de charge entre les options d'hébergement. L'expérience limitée sur le site Web dans Cloud Storage est préférable à un site Web non disponible et une expérience client médiocre.

Pour découvrir une autre approche qui utilise Cloud DNS au lieu de l'équilibreur de charge d'application externe pour contrôler le basculement, consultez la page Déployer un serveur Web tiède récupérable à l'aide de Cloud DNS avec Compute Engine et Cloud Storage. Ce modèle est utile si vous avez ou souhaitez utiliser Cloud DNS.

Pour exécuter des applications fiables dans Google Cloud, nous vous recommandons de concevoir votre infrastructure d'application de façon à gérer les interruptions. En fonction des besoins de votre application et de votre activité, vous aurez peut-être besoin d'un modèle de basculement à froid, tiède ou à chaud. Pour déterminer la meilleure approche pour vos propres applications, consultez le Guide de planification de reprise après sinistre.

Ce document utilise un serveur Web Apache de base, mais la même approche de déploiement d'infrastructure s'applique aux autres environnements d'application que vous devez créer.

Objectifs

• Créez des groupes d'instances gérés régionaux avec une image de VM personnalisée.
• Créer un bucket Cloud Storage
• Créer et configurer un équilibreur de charge d'application externe
• Tester le basculement tiède du serveur Web avec une configuration d'équilibreur de charge mise à jour.
• Tester la récupération et la restauration après avoir mis à jour la configuration d'un équilibreur de charge.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

• Compute Engine
• Mise en réseau
• Cloud Storage

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Avant de commencer

1. Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

2. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

   Remarque : Si vous ne comptez pas conserver les ressources créées dans cette procédure, créez un projet au lieu de sélectionner un projet existant. Après avoir suivi ces étapes, vous pouvez supprimer le projet. Cela entraîne la suppression de toutes les ressources qui lui sont associées.

   Accéder au sélecteur de projet

3. Vérifiez que la facturation est activée pour votre projet Google Cloud.

4. Activez l'API Compute Engine

   Activer l'API

5. Installez Google Cloud CLI.

6. Pour initialiser gcloudCLI, exécutez la commande suivante :

   gcloud init

7. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

   Remarque : Si vous ne comptez pas conserver les ressources créées dans cette procédure, créez un projet au lieu de sélectionner un projet existant. Après avoir suivi ces étapes, vous pouvez supprimer le projet. Cela entraîne la suppression de toutes les ressources qui lui sont associées.

   Accéder au sélecteur de projet

8. Vérifiez que la facturation est activée pour votre projet Google Cloud.

9. Activez l'API Compute Engine

   Activer l'API

10. Installez Google Cloud CLI.

11. Pour initialiser gcloudCLI, exécutez la commande suivante :

    gcloud init

Vous pouvez exécuter Google Cloud CLI dans la console Google Cloud sans avoir à installer Google Cloud CLI. Pour exécuter gcloud CLI dans la console Google Cloud, utilisez Cloud Shell.

Préparer l'environnement

Dans cette section, vous allez définir des variables pour les noms et les emplacements de vos ressources. Ces variables sont utilisées par les commandes de Google Cloud CLI lors du déploiement des ressources.

Tout au long de ce tutoriel, sauf indication contraire, vous devez saisir les commandes dans Cloud Shell ou dans votre environnement de développement local.

1. Remplacez PROJECT_ID par votre ID de projet : Si vous le souhaitez, fournissez votre propre suffixe de nom pour les ressources permettant de les rechercher et de les identifier, par exemple app.

   Spécifiez deux régions, telles que us-west1 et us-west2, et une zone de l'une de ces régions, telle que us-west1-a. Cette zone définit l'endroit où la VM de base initiale est créée, utilisée pour créer une image pour le groupe d'instances géré.

   Enfin, définissez un domaine utilisé pour votre site Web statique, tel que example.com.

   PROJECT_ID=PROJECT_ID
   NAME_SUFFIX=app
   REGION1=us-west1
   REGION2=us-west2
   ZONE=us-west1-a
   DOMAIN=example.com
   

Créer un VPC et un sous-réseau

Pour fournir un accès réseau aux VM, créez des clouds privés virtuels (VPC) et des sous-réseaux. Étant donné que vous avez besoin de groupes d'instances gérés dans deux régions, vous créez un sous-réseau dans chaque région. Pour en savoir plus sur les avantages du mode de sous-réseau personnalisé afin de gérer les plages d'adresses IP utilisées dans votre environnement, consultez la section Utiliser des réseaux VPC en mode personnalisé.

1. Créez le VPC avec un mode de sous-réseau personnalisé :

   gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
   

2. Créez maintenant deux sous-réseaux dans le nouveau VPC, un pour chaque région. Définissez vos propres plages d'adresses, telles que 10.1.0.0/20 et 10.2.0.0/20, qui correspondent à votre plage réseau :

   gcloud compute networks subnets create \
       subnet-$NAME_SUFFIX-$REGION1 \
       --network=network-$NAME_SUFFIX \
       --range=10.1.0.0/20 \
       --region=$REGION1
   
   gcloud compute networks subnets create \
       subnet-$NAME_SUFFIX-$REGION2 \
       --network=network-$NAME_SUFFIX \
       --range=10.2.0.0/20 \
       --region=$REGION2
   

Créer des règles de pare-feu

Pour que le trafic réseau circule correctement dans le VPC, utilisez des règles de pare-feu.

1. Créez des règles de pare-feu pour autoriser le trafic Web et les vérifications d'état pour l'équilibreur de charge et les groupes d'instances gérés :

   gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:80 \
       --source-ranges=0.0.0.0/0 \
       --target-tags=http-server
   
   gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=allow-health-check \
       --rules=tcp:80
   

   La règle HTTP suivante autorise le trafic vers toutes les VM sur lesquelles l'option http-server est appliquée, et depuis n'importe quelle source utilisant la plage 0.0.0.0/0. Concernant la règle de vérification de l'état, les plages par défaut de Google Cloud sont définies pour permettre à la plate-forme de vérifier correctement l'état des ressources.

2. Afin d'autoriser le trafic SSH pour la configuration initiale d'une image de VM de base, définissez le champ d'application de la règle de pare-feu dans votre environnement à l'aide du paramètre --source-range. Vous devrez peut-être collaborer avec votre équipe réseau pour déterminer les plages sources utilisées par votre organisation.

   Important : Nous vous déconseillons d'utiliser une large plage de 0.0.0.0/0 qui pourrait autoriser tout le trafic. Pour acheminer le trafic vers une seule adresse IP, utilisez un masque de réseau /32, tel que 35.230.62.163/32.

   Remplacez IP_ADDRESS_SCOPE par vos propres champs d'application d'adresses IP :

   gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:22 \
       --source-ranges=IP_ADDRESS_SCOPE
   

3. Après avoir créé les règles de pare-feu, vérifiez que les trois règles ont bien été ajoutées :

   gcloud compute firewall-rules list \
       --project=$PROJECT_ID \
       --filter="NETWORK=network-$NAME_SUFFIX"
   

   L'exemple de résultat suivant montre que les trois règles ont été correctement créées :

   NAME                    NETWORK      DIRECTION  PRIORITY  ALLOW
   allow-health-check-app  network-app  INGRESS    1000      tcp:80
   allow-http-app          network-app  INGRESS    1000      tcp:80
   allow-ssh-app           network-app  INGRESS    1000      tcp:22
   

Créer et configurer une image de VM de base

Pour créer des VM identiques que vous déployez sans configuration supplémentaire, utilisez une image de VM personnalisée. Cette image capture la configuration du système d'exploitation et d'Apache et permet de créer chaque VM dans le groupe d'instances géré lors des étapes suivantes.

Remarque : Dans ce document, vous créez et configurez manuellement la VM de base et les images. Dans les déploiements de production, utilisez vos outils et pipelines de déploiement existants pour automatiser ce processus autant que possible. Pour en savoir plus, consultez la page Gérer une Infrastructure as Code avec Terraform, Cloud Build et GitOps.

Sur la VM, créez un fichier index.html de base sur le disque persistant et installez-le sur /var/www/example.com. Un fichier de configuration Apache sous /etc/apache2/sites-available/example.com.conf diffuse le contenu Web à partir de l'emplacement de disque persistant installé.

Le schéma suivant illustre la page HTML de base diffusée par Apache, stockée sur le disque persistant.

Pour créer cet environnement, procédez comme suit :

1. Créez une VM de base à laquelle un disque persistant est associé :

   gcloud compute instances create vm-base-$NAME_SUFFIX \
       --zone=$ZONE \
       --machine-type=n1-standard-1 \
       --subnet=subnet-$NAME_SUFFIX-$REGION1 \
       --tags=http-server \
       --image=debian-10-buster-v20210420 \
       --image-project=debian-cloud \
       --boot-disk-size=10GB \
       --boot-disk-type=pd-balanced \
       --boot-disk-device-name=vm-base-$NAME_SUFFIX \
       --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
   

   Vous utilisez les paramètres définis au début de ce document pour nommer la VM et vous connecter au sous-réseau approprié. Les noms sont également attribués à partir des paramètres du disque de démarrage et du disque de données.

2. Pour installer et configurer le site Web simple, connectez-vous d'abord à la VM de base via SSH :

   gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
   

3. Dans votre session SSH sur la VM, créez un script pour configurer la VM dans l'éditeur de votre choix. L'exemple suivant utilise Nano en tant qu'éditeur :

   nano configure-vm.sh
   

   Collez le script de configuration suivant dans le fichier.

   #!/bin/bash
   
   NAME_SUFFIX=app
   
   # Create directory for the basic website files
   sudo mkdir -p /var/www/example.com
   sudo chmod a+w /var/www/example.com
   sudo chown -R www-data: /var/www/example.com
   
   # Find the disk name, then format and mount it
   DISK_NAME="google-disk-base-$NAME_SUFFIX"
   DISK_PATH="$(find /dev/disk/by-id -name "${DISK_NAME}" | xargs -I '{}' readlink -f '{}')"
   
   sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH
   sudo mount -o discard,defaults $DISK_PATH /var/www/example.com
   
   # Install Apache
   sudo apt-get update && sudo apt-get -y install apache2
   
   # Write out a basic HTML file to the mounted persistent disk
   sudo tee -a /var/www/example.com/index.html >/dev/null <<'EOF'
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   EOF
   
   # Write out an Apache configuration file
   sudo tee -a /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF'
   <VirtualHost *:80>
           ServerName www.example.com
   
           ServerAdmin webmaster@localhost
           DocumentRoot /var/www/example.com
   
           ErrorLog ${APACHE_LOG_DIR}/error.log
           CustomLog ${APACHE_LOG_DIR}/access.log combined
   </VirtualHost>
   EOF
   
   # Enable the Apache configuration file and reload service
   sudo a2dissite 000-default
   sudo a2ensite example.com.conf
   sudo systemctl reload apache2
   

   Mettez à jour la variable NAME_SUFFIX pour qu'elle corresponde à la valeur définie au début de ce document, par exemple app.

4. Écrivez le fichier et quittez votre éditeur. Par exemple, dans Nano, vous utilisez Ctrl-O pour écrire le fichier, puis vous quittez avec Ctrl-X.

5. Rendez le script de configuration exécutable, puis exécutez-le :

   chmod +x configure-vm.sh
   ./configure-vm.sh
   

6. Quittez la session SSH sur la VM :

   exit
   

7. Obtenez l'adresse IP de la VM et utilisez curl pour afficher la page Web de base :

   curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \
       --zone $ZONE \
       --format="value(networkInterfaces.accessConfigs.[0].natIP)")
   

   Le site Web de base est renvoyé, comme illustré dans l'exemple de résultat suivant :

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

   Cette étape confirme qu'Apache est configuré correctement et que la page est chargée à partir du disque persistant associé. Au cours des étapes suivantes, vous allez créer une image à l'aide de cette VM de base et configurer un modèle d'instance avec un script de démarrage.

Déployer les ressources Compute Engine

Ce modèle de basculement tiède utilise des groupes d'instances gérés pour exécuter les VM. Les groupes d'instances gérés s'exécutent dans deux régions, et chaque groupe surveille l'état des VM. En cas de panne et l'une des VM échoue, le groupe d'instances géré recrée la VM. Cette configuration crée une application à haute disponibilité, même sans basculement tiède vers un site statique dans Cloud Storage.

1. Avant de pouvoir créer une image, vous devez arrêter la VM :

   gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE
   

2. Exécutez l'ensemble de commandes suivant pour créer les images de VM, les modèles d'instance et les groupes d'instances gérés :

   # Create the base VM images
   gcloud compute images create image-$NAME_SUFFIX \
       --source-disk=vm-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE
   
   gcloud compute images create image-disk-$NAME_SUFFIX \
       --source-disk=disk-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE
   
   # Create instance templates
   gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \
       --region=$REGION1 \
       --tags=http-server \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \
       --image=image-$NAME_SUFFIX \
       --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes
   
   gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \
       --region=$REGION2 \
       --tags=http-server \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \
       --image=image-$NAME_SUFFIX \
       --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes
   
   # Create a health check for VM instances
   gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \
       --port 80
   
   # Create the managed instance groups
   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION1 \
       --template=template-$NAME_SUFFIX-$REGION1 \
       --size=2 \
       --region=$REGION1 \
       --health-check=http-basic-check-$NAME_SUFFIX
   
   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION2 \
       --template=template-$NAME_SUFFIX-$REGION2 \
       --size=2 \
       --region=$REGION2 \
       --health-check=http-basic-check-$NAME_SUFFIX
   

Créer et configurer un équilibreur de charge

Pour que les utilisateurs puissent accéder à votre site Web, vous devez autoriser le trafic vers les VM exécutées dans les groupes d'instances gérés. Vous souhaitez également rediriger automatiquement le trafic vers de nouvelles VM en cas de défaillance d'une zone dans un groupe d'instances géré.

Dans la section suivante, vous allez créer un équilibreur de charge externe avec un service de backend pour le trafic HTTP sur le port 80, utiliser la vérification d'état créée lors des étapes précédentes et effectuer le mappage d'une adresse IP externe vers le service de backend.

Pour en savoir plus, consultez la section Configurer un simple équilibreur de charge HTTP externe.

1. Créez et configurez l'équilibreur de charge de votre application :

   # Configure port rules for HTTP port 80
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$REGION1 \
       --named-ports http:80 \
       --region $REGION1
   
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$REGION2 \
       --named-ports http:80 \
       --region $REGION2
   
   # Create a backend service and add the managed instance groups to it
   gcloud compute backend-services create \
       web-backend-service-$NAME_SUFFIX \
       --protocol=HTTP \
       --port-name=http \
       --health-checks=http-basic-check-$NAME_SUFFIX \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \
       --instance-group-region=$REGION1 \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \
       --instance-group-region=$REGION2 \
       --global
   
   # Create a URL map for the backend service
   gcloud compute url-maps create web-map-http-$NAME_SUFFIX \
       --default-service web-backend-service-$NAME_SUFFIX
   
   # Configure forwarding for the HTTP traffic
   gcloud compute target-http-proxies create \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map web-map-http-$NAME_SUFFIX
   
   gcloud compute forwarding-rules create \
       http-content-rule-$NAME_SUFFIX \
       --global \
       --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \
       --ports=80
   

2. Obtenez l'adresse IP de la règle de transfert pour le trafic Web :

   IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \
       --global \
       --format="value(IPAddress)")
   

3. Utilisez curl ou ouvrez votre navigateur Web pour afficher le site Web à l'aide de l'adresse IP de l'équilibreur de charge de l'étape précédente :

   curl $IP_ADDRESS
   

   Quelques minutes sont nécessaires pour que le déploiement de l'équilibreur de charge s'achève et que le trafic soit correctement dirigé vers votre backend. Une erreur HTTP 404 est renvoyée si l'équilibreur de charge est toujours en cours de déploiement. Si nécessaire, attendez quelques minutes et réessayez d'accéder au site Web.

   Le site Web de base est renvoyé, comme illustré dans l'exemple de résultat suivant :

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

Créer et configurer un bucket de stockage

Cloud Storage est utilisé pour stocker les fichiers de sites Web statiques. Dans cet exemple de base, vous créez un seul fichier avec un texte légèrement différent de celui des VM.

Dans les déploiements de production, votre site Web inclut probablement beaucoup plus de fichiers et de code d'application supplémentaire sur vos VM de groupe d'instances géré que ce qui est indiqué dans ce document. La version statique hébergée dans Cloud Storage est souvent une version plus limitée qui offre un minimum de fonctionnalités. Dans un scénario de basculement tiède, ce site Web limité de Cloud Storage s'affiche jusqu'à ce que les groupes d'instances gérés soient récupérés et qu'ils puissent diffuser du trafic pour l'ensemble de l'expérience du site Web.

1. Validez le domaine que vous souhaitez utiliser avec le bucket Cloud Storage.

2. Créez un bucket Cloud Storage correspondant au nom du domaine que vous souhaitez utiliser :

   gsutil mb gs://static-web.$DOMAIN
   

   La variable DOMAIN définie au début de ce document, par exemple example.com, est utilisée. Cet exemple stocke les fichiers statiques dans static-web.example.com.

3. Créez un fichier local que vous copiez dans le bucket Cloud Storage à l'étape suivante :

   cat <<EOF > index.html
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test static web server with warm failover from Cloud Storage!</p>
   </body>
   </html>
   EOF
   

4. Importez le fichier HTML de base dans le bucket Cloud Storage :

   gsutil cp index.html gs://static-web.$DOMAIN
   

5. Pour permettre aux utilisateurs d'afficher le contenu Web statique, définissez les autorisations appropriées sur le bucket Cloud Storage :

   gsutil iam ch allUsers:objectViewer gs://static-web.$DOMAIN
   

6. Configurez le bucket Cloud Storage pour diffuser le fichier index.html en tant que page Web par défaut :

   gsutil web set -m index.html gs://static-web.$DOMAIN
   

Ajouter le bucket Cloud Storage à l'équilibreur de charge

Une fois le bucket Cloud Storage créé et configuré pour héberger du contenu Web statique, l'équilibreur de charge a besoin d'informations sur la manière de diriger le trafic vers celui-ci.

Dans la section Créer et configurer un équilibreur de charge, vous avez créé un service de backend pour les groupes d'instances gérés. Le service de backend dispose d'un mappage d'URL, et un proxy cible HTTP permet de diriger les utilisateurs via l'équilibreur de charge vers les VM.

Pour être prêt à diriger le trafic vers le bucket Cloud Storage, configurez l'équilibreur de charge avec un nouveau backend et un nouveau mappage d'URL pour le bucket de stockage. Lorsque vous devez effectuer un basculement, vous mettez à jour l'équilibreur de charge pour utiliser cette configuration.

1. Ajoutez un backend pour le bucket Cloud Storage :

   gcloud compute backend-buckets create \
       web-bucket-$NAME_SUFFIX \
       --gcs-bucket-name=static-web.$DOMAIN
   

2. Créez un mappage d'URL qui permet au trafic de circuler vers le backend :

   gcloud compute url-maps create \
       web-map-http-bucket-$NAME_SUFFIX \
       --default-backend-bucket=web-bucket-$NAME_SUFFIX
   

3. Examinez les déploiements de ressources avant de simuler une défaillance de zone. Toutes les ressources ont été créées pour prendre en charge l'environnement, comme illustré dans l'image suivante :

   

   • Un équilibreur de charge dirige le trafic vers deux groupes d'instances gérés. Les groupes d'instances gérés contiennent chacun deux VM qui exécutent un site Web de base.
   • Un bucket Cloud Storage est configuré pour héberger des pages statiques en cas de panne avec les groupes d'instances gérés.
   • L'équilibreur de charge est configuré pour utiliser le site statique dans Cloud Storage, mais ne dirige actuellement pas le trafic vers le bucket de stockage.

Basculer vers le bucket Cloud Storage

Dans un environnement réel, vous pouvez recevoir une alerte à l'aide de Cloud Monitoring ou d'une autre solution de surveillance en cas de problème avec les groupes d'instances gérés. Cette alerte invite l'utilisateur à comprendre l'étendue de la défaillance avant de mettre à jour l'équilibreur de charge afin de rediriger le trafic vers le site Web statique hébergé par Cloud Storage. Vous pouvez également utiliser votre solution de surveillance pour répondre automatiquement aux pannes avec les groupes d'instances gérés.

Lorsque vous effectuez le basculement, l'équilibreur de charge d'application externe dirige le trafic vers le site Web statique hébergé par Cloud Storage, comme indiqué dans l'image suivante :

Lorsque vous ou votre solution de surveillance déterminez que l'action la plus appropriée consiste à mettre à jour l'équilibreur de charge pour diriger le trafic vers le bucket de stockage, mettez à jour la cible du proxy HTTP pour utiliser le mappage d'URL que vous avez créé dans la section précédente. Dans ce document, vous mettez à jour manuellement l'équilibreur de charge pour rediriger le trafic vers le site Web statique hébergé par Cloud Storage.

1. Mettez à jour la cible HTTP pour utiliser le mappage d'URL pour le bucket Cloud Storage :

   gcloud compute target-http-proxies update \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map=web-map-http-bucket-$NAME_SUFFIX
   

2. Utilisez maintenant curl ou ouvrez votre navigateur Web pour accéder à l'adresse IP de l'équilibreur de charge :

   curl $IP_ADDRESS
   

   Le site Web statique de Cloud Storage est renvoyé, comme illustré dans l'exemple de résultat suivant :

   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test static web server with warm failover from Cloud Storage!</p>
   </body>
   </html>
   

   La mise à jour de la configuration et le transfert correct du trafic vers votre bucket Cloud Storage peuvent prendre quelques minutes. Si nécessaire, attendez quelques minutes et réessayez d'accéder au site Web.

Revenir aux groupes d'instances gérés

Une fois les problèmes liés aux groupes d'instances gérés résolus, vous pouvez revenir au contenu des groupes d'instances gérés à équilibrage de charge en effectuant à nouveau la mise à jour de la configuration de mappage d'URL. Là encore, l'opération doit être effectuée manuellement à l'aide des informations de Cloud Monitoring sur l'état des groupes d'instances gérés. Vous pouvez également utiliser l'automatisation pour répondre à l'état restauré du groupe d'instances géré. Dans ce document, vous allez mettre à jour manuellement la configuration de l'équilibreur de charge.

1. Mettez à jour la cible du proxy HTTP pour utiliser à nouveau le mappage d'URL pour les groupes d'instances gérés :

   gcloud compute target-http-proxies update \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map=web-map-http-$NAME_SUFFIX
   

2. Utilisez à nouveau curl ou ouvrez votre navigateur Web pour accéder à l'adresse IP de l'équilibreur de charge :

   curl $IP_ADDRESS
   

   La mise à jour de la configuration et la redirection correcte du trafic vers vos groupes d'instances gérés peuvent prendre quelques minutes. Si nécessaire, attendez quelques minutes et réessayez d'accéder au site Web.

   Le site Web principal des groupes d'instances gérés est renvoyé, comme indiqué dans l'exemple de résultat suivant :

   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

Nettoyer

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Pour supprimer les ressources individuelles créées dans ce document, procédez comme suit :

1. Supprimez le bucket Cloud Storage :

   gsutil rm -r gs://static-web.$DOMAIN
   

2. Supprimez la configuration de l'équilibreur de charge :

   gcloud compute forwarding-rules delete \
       http-content-rule-$NAME_SUFFIX --global --quiet
   
   gcloud compute target-http-proxies delete \
       http-lb-proxy-$NAME_SUFFIX --quiet
   
   gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet
   
   gcloud compute url-maps delete web-map-http-bucket-$NAME_SUFFIX --quiet
   
   gcloud compute backend-services delete \
       web-backend-service-$NAME_SUFFIX --global --quiet
   
   gcloud compute backend-buckets delete web-bucket-$NAME_SUFFIX --quiet
   

3. Supprimez le groupe d'instances géré et la vérification d'état :

   gcloud compute instance-groups managed delete \
       instance-group-$NAME_SUFFIX-$REGION1 \
       --region=$REGION1 --quiet
   
   gcloud compute instance-groups managed delete \
       instance-group-$NAME_SUFFIX-$REGION2 \
       --region=$REGION2 --quiet
   
   gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
   

4. Supprimez les modèles d'instance, les images, la VM de base et les disques persistants :

   gcloud compute instance-templates delete \
       template-$NAME_SUFFIX-$REGION1 --quiet
   
   gcloud compute instance-templates delete \
       template-$NAME_SUFFIX-$REGION2 --quiet
   
   gcloud compute images delete image-$NAME_SUFFIX --quiet
   
   gcloud compute images delete image-disk-$NAME_SUFFIX --quiet
   
   gcloud compute instances delete vm-base-$NAME_SUFFIX \
       --zone=$ZONE --quiet
   

5. Supprimez les règles de pare-feu.

   gcloud compute firewall-rules delete \
       allow-health-check-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete \
       allow-ssh-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete \
       allow-http-$NAME_SUFFIX --quiet
   

6. Supprimez le sous-réseau et le réseau VPC :

   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet
   
   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet
   
   gcloud compute networks delete network-$NAME_SUFFIX --quiet
   

Étapes suivantes

• Pour découvrir une autre approche qui utilise Cloud DNS au lieu de l'équilibreur de charge d'application externe pour contrôler le basculement, consultez la page Déployer un serveur Web tiède récupérable à l'aide de Cloud DNS avec Compute Engine et Cloud Storage. Ce modèle est utile si vous avez ou souhaitez utiliser Cloud DNS.
• Pour apprendre à déterminer la meilleure approche pour vos propres applications et la méthode de récupération à utiliser, consultez le guide de planification de reprise après sinistre.
• Pour découvrir d'autres modèles d'applications, tels que le basculement à froid et à chaud, consultez la section Scénarios de reprise après sinistre pour les applications.
• Pour découvrir d'autres façons de gérer l'évolutivité et la disponibilité, consultez la page Modèles d'applications évolutives et résilientes.
• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.