Этот документ предназначен для архитекторов и людей, работающих в операционных и административных командах. В документе описан пример шаблона, который вы можете использовать для собственных развертываний в Google Cloud.

В этом шаблоне Cloud DNS направляет трафик на экземпляры Compute Engine в управляемых группах экземпляров, которые обслуживают контент. В случае сбоя вы обновляете зону облачного DNS и выполняете отработку отказа на статический сайт в облачном хранилище.

Для выполнения этого руководства вам потребуется зарегистрированное доменное имя, которым вы управляете и которое вы хотите использовать с этим документом.

В производственных развертываниях ваш веб-сайт, вероятно, содержит намного больше файлов и дополнительного кода приложения на виртуальных машинах управляемой группы экземпляров (ВМ), чем показано в этом документе. Затем в Cloud Storage размещается более ограниченная статическая версия с минимальной функциональностью. В сценарии теплого перехода на другой ресурс пользователи видят этот ограниченный веб-сайт до тех пор, пока группы управляемых экземпляров не восстановятся и не смогут обслуживать трафик для полноценной работы веб-сайта.

В этом руководстве вы развертываете ресурсы для создания среды, как показано на следующем рисунке:
Когда вам нужно выполнить отработку отказа, вы обновите конфигурацию Cloud DNS, чтобы направить трафик в Cloud Storage, как показано на следующем рисунке:
Этот шаблон теплого перехода на другой ресурс уравновешивает затраты на запуск другой группы управляемых экземпляров в другом регионе, который вы используете только в случае сбоя основного региона. Стоимость статического сайта с использованием Cloud Storage ниже, чем запуск другой группы управляемых экземпляров, но между вариантами хостинга возникает небольшая задержка при обновлении Cloud DNS. Ограниченный доступ к веб-сайту в облачном хранилище лучше, чем полностью недоступный веб-сайт и плохое качество обслуживания клиентов.

Альтернативный подход, использующий внешнюю балансировку нагрузки HTTP(S) вместо облачного DNS для управления отработкой отказа, см. в разделе Развертывание восстанавливаемого веб-сервера с теплым восстановлением с помощью Compute Engine и Cloud Storage. Этот шаблон полезен, если у вас нет или вы не хотите использовать Cloud DNS.

Чтобы запускать надежные приложения в Google Cloud, мы рекомендуем спроектировать инфраструктуру приложений таким образом, чтобы она справлялась со сбоями. В зависимости от вашего приложения и бизнес-потребностей вам может потребоваться холодная, теплая или горячая отработка отказа. Дополнительные сведения о том, как определить наилучший подход для собственных приложений, см. в руководстве по планированию аварийного восстановления.

В этом документе используется базовый веб-сервер Apache, но тот же подход к развертыванию инфраструктуры применим и к другим средам приложений, которые необходимо создать.

## Цели

- Создание региональных управляемых групп экземпляров с собственным образом виртуальной машины.

- Создайте корзину облачного хранилища

- Создать и настроить зону облачного DNS

- Протестируйте отказоустойчивость теплого веб-сервера с обновленными записями Cloud DNS.

- Проверьте восстановление и восстановление после отказа с обновленными записями Cloud DNS.

## Расходы
В этом руководстве используются следующие оплачиваемые компоненты Google Cloud:
Чтобы рассчитать стоимость на основе прогнозируемого использования,
воспользуйтесь калькулятором цен

## Прежде чем вы начнете
Некоторые шаги в этом документе могут работать неправильно, если ваша организация применяет ограничения к вашей среде Google Cloud. В этом случае вы не сможете выполнять такие задачи, как создание общедоступных IP-адресов или ключей сервисных учетных записей. Если вы делаете запрос, который возвращает ошибку об ограничениях, узнайте, как разрабатывать приложения в ограниченной среде Google Cloud.

- Войдите в свою учетную запись Google Cloud. Если вы новичок в Google Cloud, создайте учетную запись, чтобы оценить, как наши продукты работают в реальных сценариях. Новые клиенты также получают бесплатные кредиты в размере 300 долларов США для запуска, тестирования и развертывания рабочих нагрузок.

-
В консоли Google Cloud на странице выбора проекта выберите или создайте проект Google Cloud.

-
Убедитесь, что биллинг включен для вашего облачного проекта. Узнайте, как проверить, включена ли оплата для проекта

-
Включить API Compute Engine

- Установите и инициализируйте Google Cloud CLI

-
В консоли Google Cloud на странице выбора проекта выберите или создайте проект Google Cloud.

-
Убедитесь, что биллинг включен для вашего облачного проекта. Узнайте, как проверить, включена ли оплата для проекта

-
Включить API Compute Engine

- Установите и инициализируйте Google Cloud CLI

Вы можете запустить Google Cloud CLI в консоли Google Cloud, не устанавливая Google Cloud CLI. Чтобы запустить интерфейс командной строки gcloud в консоли Google Cloud, используйте Cloud Shell

## Подготовьте среду
В этом разделе вы определяете некоторые переменные для имен и местоположений ваших ресурсов. Эти переменные используются командами Google Cloud CLI при развертывании ресурсов.

В этом руководстве, если не указано иное, вы вводите все команды в Cloud Shell или в локальной среде разработки.

Заменять
с вашим собственным идентификатором проекта. При желании укажите собственный суффикс имени для ресурсов, чтобы облегчить их поиск и идентификацию, например
PROJECT_ID


приложение
Укажите два региона, например
и
сша-запад1
и зону в одном из этих регионов, например
сша-запад2
. Эта зона определяет, где создается исходная базовая виртуальная машина, которая используется для создания образа для управляемой группы экземпляров.

сша-запад1-а
Наконец, установите домен, который используется для вашего статического веб-сайта, например
пример.com
PROJECT_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## Создайте VPC и подсеть
Чтобы обеспечить сетевой доступ к виртуальным машинам, вы создаете виртуальное частное облако (VPC) и подсети. Поскольку вам нужны группы управляемых экземпляров в двух регионах, вы создаете по одной подсети в каждом регионе. Дополнительные сведения о преимуществах режима пользовательской подсети для управления диапазонами IP-адресов, используемых в вашей среде, см. в разделе Использование сетей VPC пользовательского режима.

Создайте VPC с пользовательским режимом подсети:
Вычислительные сети gcloud создают network-$NAME_SUFFIX --subnet-mode=custom
Теперь создайте две подсети в новом VPC, по одной для каждого региона. Определите свои собственные диапазоны адресов, такие как
и
10.1.0.0/20
, которые соответствуют вашему сетевому диапазону:
10.2.0.0/20
создание подсетей вычислительных сетей gcloud \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range=
10.1.0.0/20\ --region=$REGION1 создание подсетей вычислительных сетей gcloud \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range= 10.2.0.0/20\ --region=$ РЕГИОН2
## Создать правила брандмауэра
Чтобы разрешить сетевому трафику правильно проходить через VPC, используйте правила брандмауэра.

Создайте правила брандмауэра, чтобы разрешить веб-трафик и проверки работоспособности для балансировщика нагрузки и групп управляемых экземпляров:
правила брандмауэра вычислений gcloud create allow-http-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=ВХОД \ --priority=1000 \ --action=РАЗРЕШИТЬ \ --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=вход \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
Правило HTTP разрешает трафик на любую виртуальную машину, где
применяется http-servertag, и из любого источника, использующего
0.0.0.0/0диапазон. Для правила проверки работоспособности устанавливаются диапазоны по умолчанию для Google Cloud, позволяющие платформе правильно проверять работоспособность ресурсов.

Чтобы разрешить SSH-трафик для первоначальной настройки образа базовой ВМ, настройте правило брандмауэра на свою среду с помощью параметра
--source-диапазон параметров. Возможно, вам придется поработать с вашей сетевой командой, чтобы определить, какие исходные диапазоны использует ваша организация.

Заменять
с вашими собственными диапазонами IP-адресов:
IP_АДРЕС_SCOPE
правила брандмауэра вычислений gcloud create allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=ВХОД \ --priority=1000 \ --action=РАЗРЕШИТЬ \ --rules=tcp:22 \ -- исходные диапазоны =
IP_АДРЕС_SCOPE
 После создания правил брандмауэра убедитесь, что были добавлены три правила:
список правил брандмауэра вычислений gcloud \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"Следующий пример вывода показывает, что три правила были созданы правильно:
ИМЯ НАПРАВЛЕНИЕ СЕТИ ПРИОРИТЕТ РАЗРЕШИТЬ allow-health-check-app network-app ВХОД 1000 tcp:80 allow-http-app network-app ВХОД 1000 tcp:80 allow-ssh-app network-app ВХОД 1000 tcp:22
## Создать и настроить базовый образ ВМ
Чтобы создать идентичные виртуальные машины, которые вы развертываете без дополнительной настройки, вы используете собственный образ виртуальной машины. Этот образ фиксирует конфигурацию ОС и Apache и используется для создания каждой виртуальной машины в группе управляемых экземпляров на следующих этапах.

На виртуальной машине вы создаете базовый
файл index.html на постоянном диске и
установить его на
/var/www/example.com. Файл конфигурации Apache по адресу
/etc/apache2/sites-available/example.com.conf обслуживает веб-контент из
смонтированное постоянное местоположение на диске

На следующей диаграмме показана базовая HTML-страница, обслуживаемая Apache и хранящаяся на постоянном диске:
Вы создаете эту среду в следующих шагах

Создайте базовую виртуальную машину с подключенным постоянным диском:
экземпляры вычислений gcloud создают 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- имя_устройства=vm-base-$NAME_SUFFIX \ --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
Вы используете параметры, определенные в начале этого документа, чтобы назвать ВМ и подключиться к правильной подсети. Имена также назначаются из параметров для загрузочного диска и диска данных.

Чтобы установить и настроить простой веб-сайт, сначала подключитесь к базовой виртуальной машине с помощью SSH:
gcloud вычислить ssh vm-base-$NAME_SUFFIX --zone=$ZONE
В сеансе SSH с виртуальной машиной создайте сценарий для настройки виртуальной машины в редакторе по вашему выбору. В следующем примере в качестве редактора используется Nano:
нано настроить-vm.
Вставьте следующий скрипт конфигурации в файл:
bin/баш NAME_SUFFIX=
app# Создать каталог для основных файлов веб-сайта sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Найдите имя диска, затем отформатируйте и смонтируйте его 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 -o discard,defaults $DISK_PATH /var/www/example.com # Установить Apache sudo apt-get update&&  sudo apt-get -y install apache2 # Запись основного HTML-файла на смонтированный постоянный диск sudo tee -a /var/www/example.com/index.html >/dev/null EOF'     Пример высокой готовности/аварийного восстановления   
 Добро пожаловать на веб-сайт Compute Engine с теплым аварийным переключением на 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 # Включить файл конфигурации Apache и перезагрузить службу sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
Обновите
переменная, чтобы соответствовать значению, установленному в начале этого документа, например
Приложение NAME_SUFFIX

Запишите файл и выйдите из редактора. Например, в Nano вы используете
Ctrl-O, чтобы записать файл, затем выйти с помощью
Ctrl-Х

Сделайте скрипт конфигурации исполняемым, затем запустите его:
chmod +x настроить-vm../configure-vm.
Выйдите из сеанса SSH на виртуальную машину:
выход
Получите IP-адрес виртуальной машины и используйте
curl, чтобы увидеть основную веб-страницу:
curl $(вычислительные экземпляры gcloud описывают vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP
Базовый веб-сайт возвращается, как показано в следующем примере вывода:
     Пример высокой готовности/аварийного восстановления   
 Добро пожаловать на веб-сайт Compute Engine с теплым аварийным переключением на Cloud Storagep>

# Создать базовые образы ВМ 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 # Создать шаблоны экземпляров 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-сервер \ --metadatastartup-script /bin/bashn 'echo\ UUIDblkid\ -s\ UUID\ -o\ значение\ /dev/sdb /var/www/example.com\ ext4\ discard,defaults,nfail\ 0\ 2 ee\ -a\ /etc/fstabn'mount \ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes шаблоны экземпляров вычислений gcloud 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-сервер \ --metadatastartup-script /bin/bashn'echo\ UUIDblkid\ -s\ UUID\ -o\ значение\ /dev/sdb /var/www/example.com\ ext4\ discard,defaults ,nfail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # Создать проверку работоспособности для экземпляров ВМ gcloud Compute Health-Checks create http http-basic-check-$NAME_SUFFIX \ --port 80 # Создать управляемые группы экземпляров gcloud Compute instance-groups manageed create instance-group-$NAME_SUFFIX-$REGION1 \ --template=template-$NAME_SUFFIX-$REGION1 \ --size=2 \ --region=$REGION1 \ --health-check=http-basic-check-$NAME_SUFFIX управляемые группы экземпляров вычислений gcloud создать группу экземпляров -$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## Создание и настройка балансировщика нагрузки
Чтобы пользователи могли получить доступ к вашему веб-сайту, вам необходимо разрешить трафик к виртуальным машинам, работающим в управляемых группах экземпляров. Вы также хотите автоматически перенаправлять трафик на новые виртуальные машины в случае сбоя зоны в управляемой группе экземпляров.

В следующем разделе вы создадите внешний балансировщик нагрузки HTTPS с серверной службой для HTTP-трафика через порт 80, используете проверку работоспособности, созданную на предыдущих шагах, и сопоставите внешний IP-адрес с серверной службой.

Дополнительные сведения см. в разделе Как настроить простой внешний балансировщик нагрузки HTTP.

Создайте и настройте балансировщик нагрузки для своего приложения:
# Настроить правила портов для HTTP-порта 80 gcloud calculate instance-groups set-named-ports \ instance-group-$NAME_SUFFIX-$REGION1 \ --named-ports http:80 \ --region $REGION1 gcloud calculate instance-groups set- named-ports \ instance-group-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # Создать серверную службу и добавить в нее группы управляемых экземпляров backend-service-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --global gcloud computing 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 # Создать карту URL-адресов для серверной службы gcloud вычислить url-maps create веб-карта-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Настроить переадресацию HTTP-трафика gcloud вычислить target-http-proxy create \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http- $NAME_SUFFIX правила переадресации вычислений gcloud create \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
Получите IP-адрес правила переадресации веб-трафика:
IP_ADDRESSПравила переадресации вычислений gcloud описывают http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress
Использовать
curl или откройте веб-браузер, чтобы просмотреть веб-сайт, используя IP-адрес балансировщика нагрузки из предыдущего шага:
завить $IP_АДРЕС
Балансировщику нагрузки требуется несколько минут, чтобы завершить развертывание и правильно направить трафик на серверную часть. Ошибка HTTP 404 возвращается, если балансировщик нагрузки все еще развертывается. При необходимости подождите несколько минут и попробуйте снова получить доступ к веб-сайту.

Базовый веб-сайт возвращается, как показано в следующем примере вывода:
     Пример высокой готовности/аварийного восстановления   
 Добро пожаловать на веб-сайт Compute Engine с теплым аварийным переключением на 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.