Déployer un serveur Web tiède récupérable à l'aide de Cloud DNS avec Compute Engine et Cloud Storage

Last reviewed 2021-06-28 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, Cloud DNS 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 zone Cloud DNS 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 devez mettre à jour la configuration Cloud DNS 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 région différente que celle utilisée en cas de défaillance de la région principale. Le coût d'un site statique utilisant Cloud Storage est inférieur à celui de l'exécution d'un autre groupe d'instances géré. Toutefois, il existe un court délai lorsque vous mettez à jour Cloud DNS entre les options d'hébergement. L'expérience limitée sur les sites Web dans Cloud Storage est préférable à un site Web entièrement indisponible et à une mauvaise expérience client.

Pour découvrir une autre approche qui utilise l'équilibreur de charge d'application externe au lieu de Cloud DNS pour contrôler le basculement, consultez la page Déploiement d'un serveur Web tiède récupérable avec Compute Engine et Cloud Storage. Ce modèle est utile si vous n'avez pas ou ne souhaitez pas 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éez un bucket Cloud Storage.
• Créez et configurez une zone Cloud DNS.
• Testez le basculement du serveur Web tiède avec les enregistrements Cloud DNS mis à jour.
• Testez la récupération et la restauration après avoir mis à jour les enregistrements Cloud DNS.

Coûts

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

• Compute Engine
• Mise en réseau
• Cloud DNS
• 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

Les contraintes de sécurité définies par votre organisation peuvent vous empêcher d'effectuer les étapes suivantes. Pour obtenir des informations de dépannage, consultez la page Développer des applications dans un environnement Google Cloud limité.

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 déploiement, 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 vers 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 les 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 HTTPS externe avec un service de backend pour le trafic HTTP sur le port 80, utiliser la vérification d'état créée aux étapes précédentes, et mapper une adresse IP externe au 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é à partir de Cloud Storage s'affiche jusqu'à ce que les groupes d'instances gérés récupèrent et puissent diffuser le trafic pour l'expérience complète 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
   

Créer une zone et un enregistrement DNS

Pour permettre au trafic d'être dirigé vers le site statique tiède sur Cloud Storage en cas de panne avec les groupes d'instances gérés, créez une zone Cloud DNS. Dans des conditions normales, cette zone DNS dirige le trafic via l'équilibreur de charge externe vers les groupes d'instances gérés créés dans les sections précédentes.

Remarque : Avec une approche de basculement basée sur DNS, les utilisateurs continuent de résoudre l'ancienne adresse de l'équilibreur de charge jusqu'à l'expiration de leur enregistrement DNS mis en cache. La durée pendant laquelle l'enregistrement DNS mis en cache est défini pour un utilisateur est définie avec la valeur TTL (Time To Live) lorsque vous créez les enregistrements Cloud DNS. Comme ce document décrit un modèle de basculement tiède, un certain temps d'arrêt doit être attendu venant d'un modèle de basculement à chaud avec des coûts et une complexité de configuration supplémentaires.

1. Créer une zone Cloud DNS

   gcloud dns managed-zones create zone-$NAME_SUFFIX \
       --dns-name=$DOMAIN \
       --description="DNS zone for warm site failover"
   

   La variable DOMAIN définie au début de ce document est utilisée, par exemple example.com

2. Obtenez les détails de la zone Cloud DNS :

   gcloud dns managed-zones describe zone-$NAME_SUFFIX
   

   L'exemple de résultat suivant affiche le nameServers de la zone, tel que ns-cloud-b1.googledomains.com.

   [...]
   kind: dns#managedZone
   name: zone-app
   nameServers:
   - ns-cloud-b1.googledomains.com.
   - ns-cloud-b2.googledomains.com.
   - ns-cloud-b3.googledomains.com.
   - ns-cloud-b4.googledomains.com.
   

3. Cloud DNS doit être primaire pour votre domaine. Créez des enregistrements de serveur de noms (nameserver, NS) avec votre service d'enregistrement de noms de domaine qui pointent vers votre zone Cloud DNS. Utilisez les adresses de serveur de noms renvoyées à l'étape précédente.

   Pour en savoir plus et obtenir un exemple d'utilisation de Google Domains, consultez la page Mettre à jour des serveurs de noms.

4. Dans votre zone Cloud DNS, ajoutez un enregistrement pour www à l'aide de l'adresse IP de l'équilibreur de charge obtenue dans une section précédente :

   gcloud dns record-sets transaction start \
       --zone=zone-$NAME_SUFFIX
   
   gcloud dns record-sets transaction add $IP_ADDRESS \
       --name=www.$DOMAIN \
       --ttl=300 \
       --type=A \
       --zone=zone-$NAME_SUFFIX
   

   Cet enregistrement dirige les requêtes des utilisateurs du site Web via l'équilibreur de charge vers les groupes d'instances gérés. Une valeur TTL de 300 secondes est définie pour réduire la durée pendant laquelle un enregistrement DNS mis en cache existe pour un utilisateur.

5. Créez un enregistrement que le bucket Cloud Storage doit utiliser pour le site Web statique :

   gcloud dns record-sets transaction add c.storage.googleapis.com. \
       --name=static-web.$DOMAIN \
       --ttl=300 \
       --type=CNAME \
       --zone=zone-$NAME_SUFFIX
   

   Cet exemple utilise static-web comme sous-domaine. Laissez la valeur c.storage.googleapis.com. de nouveau : une valeur TTL de 300 secondes est définie pour réduire la durée pendant laquelle l'enregistrement DNS mis en cache existe pour un utilisateur.

6. Enfin, validez les ajouts d'enregistrements DNS à la zone :

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

Vérifier et tester la zone et les enregistrements DNS

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

• Les enregistrements de zone Cloud DNS dirigent les utilisateurs vers l'équilibreur de charge pour une distribution sur les VM du groupe d'instances géré.
• Un bucket Cloud Storage est configuré pour héberger des pages Web statiques en cas de panne des groupes d'instances gérés.
• La zone Cloud DNS est configurée pour utiliser le site statique dans Cloud Storage, mais elle ne résout pas les requêtes adressées au bucket de stockage pour le moment.

Pour afficher les enregistrements DNS et tester la résolution, vous devez résoudre les adresses par rapport aux serveurs Cloud DNS. Dans les déploiements de production, veillez à tester les adresses et vérifier qu'elles résolvent correctement, puis mettez à jour vos propres serveurs DNS pour qu'ils résolvent correctement. Ce document ne décrit pas la procédure à suivre pour mettre à jour vos propres serveurs DNS, mais explique comment vérifier correctement les flux de trafic dans des conditions normales et de basculement.

1. Obtenez à nouveau les détails de la zone Cloud DNS :

   gcloud dns managed-zones describe zone-$NAME_SUFFIX
   

   L'exemple de résultat suivant affiche le nameServers de la zone, tel que ns-cloud-b1.googledomains.com.

   [...]
   kind: dns#managedZone
   name: zone-app
   nameServers:
   - ns-cloud-b1.googledomains.com.
   - ns-cloud-b2.googledomains.com.
   - ns-cloud-b3.googledomains.com.
   - ns-cloud-b4.googledomains.com.
   

2. Pour résoudre l'enregistrement www de votre zone Cloud DNS sur l'un de ces serveurs de noms, utilisez la commande dig :

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   Cet exemple utilise l'adresse de serveur de noms ns-cloud-b1.googledomains.com renvoyée par la commande describe précédente. Indiquez votre propre adresse de serveur de noms affichée dans le résultat de la commande précédente.

   L'exemple de résultat suivant montre que l'enregistrement est associé à l'adresse IP de l'équilibreur de charge. Si vous avez utilisé ce serveur de noms pour accéder à l'adresse, en utilisant par exemple curl et le paramètre --resolve avec le serveur de noms Cloud DNS, la page par défaut s'affiche à partir de l'un des groupes d'instances gérés derrière l'équilibreur de charge.

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;www.example.com.           IN      A
   
   ;; ANSWER SECTION:
   www.example.com.    300     IN      A       35.227.253.90
   

3. Exécutez à nouveau la commande dig pour valider l'enregistrement DNS du site Web statique dans Cloud Storage :

   dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN
   

   L'exemple de résultat suivant montre que l'enregistrement est associé à Cloud Storage qui peut diffuser le contenu statique à partir du bucket de stockage :

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com static-web.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;static-web.example.com.    IN      A
   
   ;; ANSWER SECTION:
   static-web.example.com. 300 IN      CNAME   c.storage.googleapis.com.
   

Basculer vers le bucket Cloud Storage

Dans un environnement de production, 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 l'échec avant de mettre à jour les enregistrements Cloud DNS afin de rediriger le trafic vers le site Web statique hébergé par Cloud Storage. Une autre approche consiste à utiliser votre solution de surveillance pour répondre automatiquement aux interruptions avec les groupes d'instances gérés.

Lorsque vous basculez, Cloud DNS résout le trafic vers le site Web statique hébergé par Cloud Storage, comme illustré dans l'image suivante :

Lorsque vous ou votre solution de surveillance déterminez l'action la plus appropriée pour mettre à jour les enregistrements Cloud DNS pour diriger le trafic vers Cloud Storage, mettez à jour l'enregistrement A DNS existant. Dans ce document, vous mettez à jour manuellement les enregistrements Cloud DNS pour rediriger le trafic vers le site Web statique hébergé par Cloud Storage.

1. Pour basculer vers les enregistrements Cloud DNS, supprimez l'enregistrement A existant qui résout l'équilibreur de charge :

   gcloud dns record-sets transaction start \
       --zone=zone-$NAME_SUFFIX
   
   gcloud dns record-sets transaction remove $IP_ADDRESS \
       --name=www.$DOMAIN \
       --ttl=300 \
       --type=A \
       --zone=zone-$NAME_SUFFIX
   

2. Créez un enregistrement CNAME pour www qui pointe vers le contenu hébergé sur Cloud Storage :

   gcloud dns record-sets transaction add static-web.$DOMAIN \
       --name=www.$DOMAIN. \
       --ttl=30 \
       --type=CNAME \
       --zone=zone-$NAME_SUFFIX
   

3. Validez les mises à jour dans la zone Cloud DNS :

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

4. Utilisez la commande dig pour vérifier que l'enregistrement www résout maintenant l'adresse du site Web statique Cloud Storage :

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   L'exemple de résultat suivant montre que l'enregistrement www.example.com résout l'enregistrement CNAME du site Web statique Cloud Storage. Les requêtes d'accès à www.example.com sont redirigées vers le bucket Cloud Storage, qui affiche le site Web statique :

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;www.example.com.           IN      A
   
   ;; ANSWER SECTION:
   www.example.com.    30      IN      CNAME   static-web.example.com.
   static-web.example.com. 300 IN      CNAME   c.storage.googleapis.com.
   

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 à la diffusion du contenu des groupes d'instances gérés à équilibrage de charge en mettant de nouveau à jour les enregistrements Cloud DNS. Là encore, un humain peut prendre cette décision à l'aide des insights 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 les enregistrements Cloud DNS.

Lorsque vous effectuez une restauration, Cloud DNS résout à nouveau le trafic vers les groupes d'instances gérés, comme illustré dans l'image suivante :

1. Supprimez l'enregistrement CNAME www qui redirige le trafic vers le contenu hébergé par Cloud Storage :

   gcloud dns record-sets transaction start \
       --zone=zone-$NAME_SUFFIX
   
   gcloud dns record-sets transaction remove static-web.$DOMAIN \
       --name=www.$DOMAIN \
       --ttl=30 \
       --type=CNAME \
       --zone=zone-$NAME_SUFFIX
   

2. Ajoutez à nouveau un enregistrement A pour pointer vers l'équilibreur de charge devant les groupes d'instances gérés :

   gcloud dns record-sets transaction add $IP_ADDRESS \
       --name=www.$DOMAIN \
       --ttl=300 \
       --type=A \
       --zone=zone-$NAME_SUFFIX
   

3. Validez les mises à jour dans la zone Cloud DNS :

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

4. Utilisez à nouveau la commande dig pour vérifier que l'enregistrement www résout l'adresse de l'équilibreur de charge devant les groupes d'instances gérés :

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   L'exemple de résultat suivant montre que l'enregistrement est associé à l'adresse IP de l'équilibreur de charge et que le trafic est diffusé à partir de l'un des groupes d'instances gérés :

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;www.example.com.           IN      A
   
   ;; ANSWER SECTION:
   www.example.com.    300     IN      A       35.227.253.90
   

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 la zone et les enregistrements DNS :

   touch empty-file
   gcloud dns record-sets import -z zone-$NAME_SUFFIX \
       --delete-all-existing \
       empty-file
   rm empty-file
   
   gcloud dns managed-zones delete zone-$NAME_SUFFIX
   

2. Supprimez le bucket Cloud Storage :

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

3. 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 backend-services delete \
       web-backend-service-$NAME_SUFFIX --global --quiet
   

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

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

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

7. 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 l'équilibreur de charge d'application externe au lieu de Cloud DNS pour contrôler le basculement, consultez la page Déploiement d'un serveur Web tiède récupérable avec Compute Engine et Cloud Storage. Ce modèle est utile si vous n'avez pas ou ne souhaitez pas 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.