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

Dans ce modèle, Cloud DNS dirige le trafic vers les 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 didacticiel, vous avez besoin d'un nom de domaine enregistré que vous contrôlez et que vous 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 les machines virtuelles (VM) de votre groupe d'instances géré que ce qui est indiqué dans ce document. Cloud Storage héberge alors une version statique plus limitée qui fournit des fonctionnalités minimales. Dans un scénario de basculement à chaud, les utilisateurs voient ce site Web limité jusqu'à ce que les groupes d'instances gérés se rétablissent et puissent diffuser le trafic pour l'expérience complète du site Web.

Dans ce didacticiel, vous déployez des ressources pour créer un environnement, comme illustré dans l'image suivante :
Lorsque vous devez basculer, vous mettez à jour la configuration Cloud DNS pour diriger le trafic vers Cloud Storage, comme illustré dans l'image suivante :
Ce modèle de basculement à chaud équilibre le coût d'exécution d'un autre groupe d'instances géré dans une région différente que vous n'utilisez qu'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é, mais il y a un court délai lorsque vous mettez à jour Cloud DNS entre les options d'hébergement. L'expérience limitée du site Web dans Cloud Storage est meilleure qu'un site Web totalement indisponible et une mauvaise expérience client

Pour une approche alternative qui utilise l'équilibrage de charge HTTP(S) externe au lieu de Cloud DNS pour contrôler le basculement, consultez Déployer un serveur Web récupérable à chaud avec Compute Engine et Cloud Storage. Ce modèle est utile si vous n'avez pas ou ne voulez pas utiliser Cloud DNS

Pour exécuter des applications fiables dans Google Cloud, nous vous recommandons de concevoir votre infrastructure d'application de manière à gérer les pannes. Selon votre application et les besoins de votre entreprise, vous pourriez avoir besoin d'un modèle de basculement à froid, de basculement à chaud ou de basculement à chaud. Pour plus d'informations sur la façon de 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 du déploiement de l'infrastructure s'applique aux autres environnements d'application que vous devez créer.

## Objectifs

- Créer 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 une zone Cloud DNS

- Testez le basculement du serveur Web à chaud avec des enregistrements Cloud DNS mis à jour

- Testez la récupération et le rétablissement avec les enregistrements Cloud DNS mis à jour

## Frais
Ce tutoriel utilise les composants facturables suivants de Google Cloud :
Pour générer une estimation des coûts en fonction de votre utilisation prévue,
utiliser le calculateur de prix

## Avant que tu commences
Certaines des étapes de ce document peuvent 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 faites une requête qui renvoie une erreur sur les contraintes, découvrez comment développer des applications dans un environnement Google Cloud contraint.

- Connectez-vous à votre compte Google Cloud. Si vous débutez avec Google Cloud, créez un compte pour évaluer les performances de nos produits dans des scénarios réels. Les nouveaux clients bénéficient également de 300 USD de crédits gratuits pour exécuter, tester et déployer des charges de travail

-
Dans la console Google Cloud, sur la page de sélection de projet, sélectionnez ou créez un projet Google Cloud

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

-
Activer l'API Compute Engine

- Installer et initialiser la CLI Google Cloud

-
Dans la console Google Cloud, sur la page de sélection de projet, sélectionnez ou créez un projet Google Cloud

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

-
Activer l'API Compute Engine

- Installer et initialiser la CLI Google Cloud

Vous pouvez exécuter l'interface de ligne de commande Google Cloud dans la console Google Cloud sans installer l'interface de ligne de commande Google Cloud. Pour exécuter l'interface de ligne de commande gcloud dans la console Google Cloud, utilisez Cloud Shell

## Préparer l'environnement
Dans cette section, vous définissez certaines variables pour vos noms et emplacements de ressources. Ces variables sont utilisées par les commandes CLI de Google Cloud lorsque vous déployez les ressources

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

Remplacer
avec votre propre ID de projet. Si vous le souhaitez, fournissez votre propre suffixe de nom pour les ressources permettant de les rechercher et de les identifier, telles que
PROJET_ID


application
Spécifiez deux régions, telles que
et
nous-ouest1
, et une zone à l'intérieur de l'une de ces régions, telle que
nous-ouest2
. Cette zone définit l'endroit où est créée la VM de base initiale qui est utilisée pour créer une image pour le groupe d'instances géré

us-west1-a
Enfin, définissez un domaine utilisé pour votre site Web statique, tel que
exemple.com
PROJECT_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## Créer un VPC et un sous-réseau
Pour fournir un accès réseau aux machines virtuelles, vous créez un Virtual Private Cloud (VPC) et des sous-réseaux. Comme 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 plus d'informations sur les avantages du mode de sous-réseau personnalisé pour gérer les plages d'adresses IP utilisées dans votre environnement, consultez Utiliser les réseaux VPC en mode personnalisé

Créez le VPC avec un mode de sous-réseau personnalisé :
les réseaux de calcul gcloud créent un réseau-$NAME_SUFFIX --subnet-mode=custom
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
et
10.1.0.0/20
, qui correspondent à la plage de votre réseau :
10.2.0.0/20
gcloud compute networks subnets create \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range=
10.1.0.0/20\ --region=$REGION1 création de sous-réseaux de réseaux de calcul gcloud \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range= 10.2.0.0/20\ --region=$ RÉGION2
## Créer des règles de pare-feu
Pour permettre au trafic réseau de circuler correctement dans le VPC, utilisez des règles de pare-feu

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=entrée \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
La règle HTTP autorise le trafic vers n'importe quelle machine virtuelle sur laquelle
http-servertag est appliqué, et à partir de n'importe quelle source utilisant le
0.0.0.0/0plage. Pour 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

Pour autoriser le trafic SSH pour la configuration initiale d'une image de machine virtuelle de base, étendez la règle de pare-feu à votre environnement à l'aide de la
--source-rangeparameter. Vous devrez peut-être travailler avec votre équipe réseau pour déterminer les plages de sources utilisées par votre organisation.

Remplacer
avec vos propres étendues d'adresse IP :
IP_ADDRESS_SCOPE
gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:22 \ -- plages-source=
IP_ADDRESS_SCOPE
Après avoir créé les règles de pare-feu, vérifiez que les trois règles ont été ajoutées :
gcloud compute firewall-rules list \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"L'exemple de sortie suivant montre que les trois règles ont été correctement créées :
NOM DIRECTION DU RÉSEAU PRIORITÉ AUTORISER 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 machines virtuelles identiques que vous déployez sans configuration supplémentaire, vous utilisez une image de machine virtuelle personnalisée. Cette image capture la configuration du système d'exploitation et d'Apache, et est utilisée pour créer chaque VM dans le groupe d'instances géré dans les étapes suivantes

Sur la VM, vous créez une base
fichier index.html sur le disque persistant et
le monter sur
/var/www/exemple.com. Un fichier de configuration Apache sur
/etc/apache2/sites-available/example.com.conf sert du contenu Web à partir du
emplacement du disque persistant monté

Le diagramme suivant montre la page HTML de base servie par Apache qui est stockée sur le disque persistant :
Vous construisez cet environnement dans les étapes suivantes

Créez une VM de base avec un disque persistant 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 machine virtuelle et vous connecter au sous-réseau correct. Les noms sont également attribués à partir des paramètres du disque de démarrage et du disque de données

Pour installer et configurer le site Web simple, connectez-vous d'abord à la VM de base à l'aide de SSH :
gcloud calculate ssh vm-base-$NAME_SUFFIX --zone=$ZONE
Dans votre session SSH vers la VM, créez un script pour configurer la VM dans un éditeur de votre choix. L'exemple suivant utilise Nano comme éditeur :
nano configure-vm.
Collez le script de configuration suivant dans le fichier :
bin/bash NAME_SUFFIX=
app# Créer un répertoire pour les fichiers de base du site Web sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Trouvez le nom du disque, puis formatez-le et montez-le DISK_NAME="google-disk-base-$NAME_SUFFIX"DISK_PATHfind /dev/disk/by-id -name DISK_NAME}"| xargs -Ireadlink -fsudo mkfs.ext4 -m 0 - E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH sudo mount -odiscard,defaults $DISK_PATH /var/www/example.com # Installer Apache sudo apt-get update&& sudo apt-get -y install apache2 # Écrire un fichier HTML de base sur le disque persistant monté sudo tee -a /var/ www/example.com/index.html >/dev/null EOF'    Exemple HA/DR   
Bienvenue sur un site Web Compute Engine avec basculement à chaud vers Cloud Storagep>
*: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  EOF # Activer le fichier de configuration Apache et recharger le service sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
Mettre à jour le
variable pour correspondre à la valeur définie au début de ce document, telle que
Application NAME_SUFFIX

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

Rendez le script de configuration exécutable, puis exécutez-le :
chmod +x configure-vm../configure-vm.
Quittez la session SSH sur la VM :
sortir
Obtenez l'adresse IP de la VM et utilisez
curlpour voir 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 sortie suivant :
    Exemple HA/DR   
Bienvenue sur un site Web Compute Engine avec basculement à chaud vers Cloud Storagep>

# Créer les images de VM de base 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 # Créer des modèles d'instance 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 \ --metadatastartup-script /bin/bashn 'echo\ UUIDblkid\ -s\ UUID\ -o\ value\ /dev/sdb /var/www/example.com\ ext4\discard,defaults,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'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 \ --metadatastartup-script /bin/bashn'echo\ UUIDblkid\ -s\ UUID\ -o\ value\ /dev/sdb /var/www/example.com\ ext4\ jeter, défauts ,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # Créer une vérification de l'état des instances de VM gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \ --port 80 # Créer les groupes d'instances gérés 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 groupes d'instances gérés créer un groupe d'instances -$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 accèdent à votre site Web, vous devez autoriser le trafic vers les VM qui s'exécutent 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 créez un équilibreur de charge HTTPS externe avec un service backend pour le trafic HTTP sur le port 80, utilisez la vérification de l'état créée dans les étapes précédentes et mappez une adresse IP externe via le service backend.

Pour plus d'informations, consultez Comment configurer un équilibreur de charge HTTP externe simple

Créez et configurez l'équilibreur de charge pour votre application :
# Configurer les règles de port pour le port HTTP 80 gcloud compute instance-groups set-named-ports \ instance-group-$NAME_SUFFIX-$REGION1 \ --named-ports http:80 \ --region $REGION1 gcloud compute instance-groups set- names-ports \ instance-group-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # Créez un service de backend et ajoutez-y les groupes d'instances gérés 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 # Créer un mappage d'URL pour le service de backend gcloud compute url-maps create carte-web-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Configurer le transfert pour le trafic HTTP 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
Obtenez l'adresse IP de la règle de transfert pour le trafic Web :
IP_ADDRESSgcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress
Utiliser
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
Il faut quelques minutes à l'équilibreur de charge pour terminer le déploiement et diriger correctement le trafic 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 essayez à nouveau d'accéder au site Web

Le site Web de base est renvoyé, comme illustré dans l'exemple de sortie suivant :
    Exemple HA/DR   
Bienvenue sur un site Web Compute Engine avec basculement à chaud vers Cloud Storagep>
< index.html     HA / DR example   
Welcome to a test static web server with warm failover from Cloud Storagep> 

example.com
Get the details of the Cloud DNS zone:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
The following example output shows the
nameServersfor the zone, such as
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

Cloud DNS must be authoritative for your domain. Create nameserver (NS) records with your domain registrar that point to your Cloud DNS zone. Use the nameserver addresses returned in the previous step

For more information and an example using Google Domains, see How to update name servers

In your Cloud DNS zone, add a record for
wwwusing the load balancer IP address obtained in a previous section:
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
This record directs user requests for the website through the load balancer to the managed instance groups. A TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user

Create a record to be used by the Cloud Storage bucket for the static website:
gcloud dns record-sets transaction add c.storage.googleapis.com. \ --name=static-web.$DOMAIN \ --ttl=300 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
This example uses
static-webas the subdomain. Leave the
c.storage.googleapis.com.Again, a TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user
Finally,the DNS record additions to the zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
## Verify and test the DNS zone and records
Let's review the resource deployments before simulating a zone failure. All of the resources have been created to support the environment, as shown in the following image:
- Cloud DNS zone records direct users to the load balancer for distribution across the managed instance group VMs

- A Cloud Storage bucket is configured to host static web pages if there's an outage with the managed instance groups

- The Cloud DNS zone is configured to use the static site in Cloud Storage, but doesn't currently resolve requests to the storage bucket

To view the DNS records and test resolution, you must resolve addresses against the Cloud DNS servers. In production deployments, make sure you test and verify the addresses resolve correctly, then update your own DNS servers to resolve appropriately. This document doesn't detail the steps to update your own DNS servers, only how to verify traffic flows correctly under normal and failover conditions

Get the details of the Cloud DNS zone again:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
The following example output shows the
nameServersfor the zone, such as
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

To resolve the
wwwrecord for your Cloud DNS zone against one of these name servers, use the
digcommand:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
This example uses the
ns-cloud-b1.googledomains.comnameserver address returned from the previous
describecommand. Provide your own nameserver address shown in the output of the previous command
The following example output shows that the record resolves to the IP address of the load balancer. If you used this nameserver to access the address, such as using
curland the
--resolveparameter with the Cloud DNS nameserver, the default page would be displayed from one of the managed instance groups behind the load balancer

;DiG [email protected] 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
Use the
digcommand again to verify the DNS record for the static website in Cloud Storage:
dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN
The following example output shows that the record resolves to Cloud Storage that can serve the static content from the storage bucket:
;DiG [email protected] 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

## Fail over to the Cloud Storage bucket
In a production environment, you might get an alert using Cloud Monitoring or other monitoring solution when there's a problem with the managed instance groups. This alert prompts a human to understand the scope of the failure before you update the Cloud DNS records to redirect traffic to the Cloud Storage-hosted static website. An alternative approach is to use your monitoring solution to automatically respond to outages with the managed instance groups

When you fail over, Cloud DNS resolves traffic to the Cloud Storage-hosted static website, as shown in the following image:
When you or your monitoring solution determine the most appropriate action

is to update the Cloud DNS records to direct traffic to Cloud Storage,
update the existing DNS
A record. In this document, you manually update the
Cloud DNS records to redirect traffic to the Cloud Storage-hosted
static website

To fail over the Cloud DNS records, remove the existing
Arecord that resolves to the load balancer:
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
Create a
CNAMErecord for
wwwthat points to the Cloud Storage-hosted content:
gcloud dns record-sets transaction add static-web.$DOMAIN \ --name=www.$DOMAIN. \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
the updates to the Cloud DNS zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use the
digcommand to confirm the
wwwrecord now resolves to the address of the Cloud Storage static website:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
The following example output shows that the
www.example.comrecord resolves to the CNAME record of the Cloud Storage static website. Requests to access
www.example.comare redirected to the Cloud Storage bucket, which displays the static website:
;DiG [email protected] 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

## Fail back to the managed instance groups
After issues with the managed instance groups are resolved, you can fail back to serving content from the load-balanced managed instance groups by updating the Cloud DNS records again. Again, a human might make this decision using Cloud Monitoring insights for the health of the managed instance groups. Or, you could use automation to respond to the restored health of the managed instance group. In this document, you manually update the Cloud DNS records

When you fail back, Cloud DNS resolves traffic to the managed instance groups again, as shown in the following image:
Remove the
wwwCNAME record that redirects traffic to the Cloud Storage-hosted content:
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
Add an
Arecord to point to the load balancer in front of the managed instance groups again:

gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
the updates to the Cloud DNS zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use the
digcommand one more time to confirm the
wwwrecord resolves to the address of the load balancer in front of the managed instance groups again:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
The following example output shows that the record resolves to the IP address of the load balancer and traffic would be served from one of the managed instance groups:
;DiG [email protected] 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
## Clean up
To avoid incurring charges to your Google Cloud account for the resources used in this tutorial, either delete the project that contains the resources, or keep the project and delete the individual resources

To delete the individual resources created in this document, complete the following steps:
Delete the DNS zone and records:
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
Delete the Cloud Storage bucket:
gsutil rm -r gsstatic-web.$DOMAIN
Delete the load balancer configuration:
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
Delete the managed instance groups and health check:
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
Delete the instance templates, images, base VM, and persistent disks:
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
Delete the firewall rules


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
Delete the subnet and 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
## What's next
- For an alternative approach that uses external HTTP(S) Load Balancing instead of Cloud DNS to control the failover, see Deploy a warm recoverable web server with Compute Engine and Cloud Storage. This pattern is useful if you don't have, or don't want to use, Cloud DNS

- To learn how how to determine the best approach for your own applications and which recovery method to use, see the Disaster recovery planning guide

- To see other patterns for applications, such as cold and hot failover, see Disaster recovery scenarios for applications

- For more ways to handle scale and availability, see the Patterns for scalable and resilient apps

- Explore reference architectures, diagrams, tutorials, and best practices about Google Cloud. Take a look at our Cloud Architecture Center.