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

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.

Avec ce modèle, 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 suivre ce tutoriel, 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.

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

Cloud DNS dirige les utilisateurs vers des groupes d'instances gérés derrière un équilibreur de charge externe et affiche l'expérience complète du site Web.

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:

Cloud DNS redirige désormais les utilisateurs vers un site Web statique hébergé dans Cloud Storage, et affiche une expérience plus limitée.

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'équilibrage de charge HTTP(S) 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

Ce tutoriel utilise les composants facturables suivants de Google Cloud :

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

Certaines étapes de ce document risquent de ne pas fonctionner correctement si votre organisation applique des contraintes à votre environnement Google Cloud. Dans ce cas, vous ne pourrez peut-être pas effectuer des tâches telles que la création d'adresses IP publiques ou de clés de compte de service. Si vous effectuez une requête qui renvoie une erreur concernant des contraintes, consultez la section 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.

    Accéder au sélecteur de projet

  3. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

  4. Activez l'API Compute Engine .

    Activer l'API

  5. Installez et initialisez le SDK Cloud.
  6. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  7. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

  8. Activez l'API Compute Engine .

    Activer l'API

  9. Installez et initialisez le SDK Cloud.
  10. Vous pouvez exécuter l'outil de ligne de commande gcloud dans Cloud Console sans installer le SDK Cloud. Pour exécuter l'outil gcloud dans Cloud Console, 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 l'outil de ligne de commande gcloud 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.

    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.

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.

La VM dispose d'une page HTML de base stockée sur le disque persistant avec un fichier de configuration Apache à charger à partir de l'emplacement où est installé le disque.

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.

  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:

Cloud DNS dirige les utilisateurs vers des groupes d&#39;instances gérés derrière un équilibreur de charge externe et affiche l&#39;expérience complète du site Web.

  • 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:

Cloud DNS redirige désormais les utilisateurs vers un site Web statique hébergé dans Cloud Storage, et affiche une expérience plus limitée.

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:

Cloud DNS dirige à nouveau les utilisateurs vers des groupes d&#39;instances gérés derrière un équilibreur de charge externe et affiche l&#39;expérience complète du site Web.

  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
    

Étape suivante