本文档适用于架构师以及在运营和管理团队中工作的人员。该文档描述了一个示例模式，您可以将其用于自己在 Google Cloud 中的部署

在此模式中，Cloud DNS 将流量定向到为内容提供服务的托管实例组中的 Compute Engine 实例。在中断时，您更新 Cloud DNS 区域并故障转移到 Cloud Storage 中的静态站点

要完成本教程，您需要一个由您控制并希望与本文档一起使用的注册域名

在生产部署中，您的网站可能在托管实例组虚拟机 (VM) 上包含比本文档中显示的更多的文件和附加应用程序代码。然后，Cloud Storage 托管一个功能更有限的静态版本，该版本提供的功能最少。在热故障转移场景中，用户只能看到这个受限的网站，直到托管实例组恢复并且可以为完整网站体验提供流量

在本教程中，您将部署资源以创建如下图所示的环境：
当您需要进行故障转移时，您可以更新 Cloud DNS 配置以将流量定向到 Cloud Storage，如下图所示：
这种热故障转移模式平衡了在不同区域运行另一个托管实例组的成本，您仅在主要区域出现故障时使用该实例组。使用 Cloud Storage 的静态站点的成本低于运行另一个托管实例组的成本，但在托管选项之间更新 Cloud DNS 时会有短暂的延迟。云存储中有限的网站体验优于完全不可用的网站和糟糕的客户体验

有关使用外部 HTTP(S) 负载平衡而不是 Cloud DNS 来控制故障转移的替代方法，请参阅使用 Compute Engine 和 Cloud Storage 部署热可恢复 Web 服务器。如果您没有或不想使用 Cloud DNS，此模式很有用

要在 Google Cloud 中运行可靠的应用程序，我们建议您设计应用程序基础架构来处理中断。根据您的应用程序和业务需求，您可能需要冷故障转移、热故障转移或热故障转移模式。有关如何为您自己的应用程序确定最佳方法的更多信息，请参阅灾难恢复规划指南

本文档使用基本的 Apache Web 服务器，但基础设施部署的相同方法适用于您需要创建的其他应用程序环境

## 目标

- 使用自定义 VM 映像创建区域托管实例组

- 创建一个云存储桶

- 创建和配置云 DNS 区域

- 使用更新的 Cloud DNS 记录测试热 Web 服务器故障转移

- 使用更新的 Cloud DNS 记录测试恢复和故障回复

## 费用
本教程使用 Google Cloud 的以下收费组件：
要根据您的预计使用情况生成成本估算，
使用定价计算器

＃＃ 在你开始之前
如果您的组织将限制应用于您的 Google Cloud 环境，则本文档中的某些步骤可能无法正常工作。在这种情况下，您可能无法完成创建公共 IP 地址或服务帐户密钥等任务。如果您发出的请求返回有关约束的错误，请参阅如何在受限的 Google Cloud 环境中开发应用程序

- 登录您的 Google Cloud 帐户。如果您是 Google Cloud 的新手，请创建一个帐户来评估我们的产品在真实场景中的表现。新客户还可获得 300 美元的免费积分，用于运行、测试和部署工作负载

-
在 Google Cloud 控制台的项目选择器页面上，选择或创建一个 Google Cloud 项目

-
确保为您的 Cloud 项目启用了计费。了解如何检查项目是否启用了计费

-
启用计算引擎 API

- 安装并初始化谷歌云 CLI

-
在 Google Cloud 控制台的项目选择器页面上，选择或创建一个 Google Cloud 项目

-
确保为您的 Cloud 项目启用了计费。了解如何检查项目是否启用了计费

-
启用计算引擎 API

- 安装并初始化谷歌云 CLI

您可以在 Google Cloud 控制台中运行 Google Cloud CLI，而无需安装 Google Cloud CLI。要在 Google Cloud 控制台中运行 gcloud CLI，请使用 Cloud Shell

##准备环境
在本节中，您将为资源名称和位置定义一些变量。在您部署资源时，Google Cloud CLI 命令会使用这些变量

在本教程中，除非另有说明，否则您将在 Cloud Shell 或本地开发环境中输入所有命令

代替
使用您自己的项目 ID。如果需要，为资源提供您自己的名称后缀以帮助搜索和识别它们，例如
项目编号


应用程序
指定两个区域，比如
和
美国西部1
，以及其中一个区域内的区域，例如
美国西部2
.此区域定义初始基础 VM 的创建位置，用于为托管实例组创建映像

us-west1-a
最后，设置一个用于静态网站的域，例如
例子.com
PROJECT_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## 创建VPC和子网
要提供对 VM 的网络访问，您可以创建虚拟私有云 (VPC) 和子网。由于您需要两个区域中的托管实例组，因此您在每个区域中创建一个子网。有关使用自定义子网模式管理环境中使用的 IP 地址范围的优势的更多信息，请参阅使用自定义模式 VPC 网络

使用自定义子网模式创建 VPC：
gcloud 计算网络创建网络-$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 中正确流动，请使用防火墙规则

创建防火墙规则以允许对负载均衡器和托管实例组进行 Web 流量和运行状况检查：
gcloud compute firewall-rules 创建允许-http-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:80 \ --源范围=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
HTTP 规则允许流量流向任何 VM，其中
http-servertag 已应用，并且来自任何使用
0.0.0.0/0 范围。对于健康检查规则，Google Cloud 设置了默认范围以允许平台正确检查资源的健康状况

要允许 SSH 流量用于基本 VM 映像的初始配置，请使用
--source-range参数。您可能需要与您的网络团队合作来确定您的组织使用的源范围

代替
使用您自己的 IP 地址范围：
IP_ADDRESS_SCOPE
gcloud compute firewall-rules 创建允许-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:22 \ --源范围=
IP_ADDRESS_SCOPE
创建防火墙规则后，验证是否已添加三个规则：
gcloud 计算防火墙规则列表 \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"以下示例输出显示已正确创建三个规则：
名称 网络方向 优先级 允许 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
## 创建和配置基本 VM 映像
要创建无需额外配置即可部署的相同 VM，您可以使用自定义 VM 映像。此映像捕获操作系统和 Apache 配置，并用于在后续步骤中创建托管实例组中的每个 VM

在 VM 上，您创建一个基本的
永久磁盘上的 index.html 文件和
安装到
/var/www/example.com。 Apache 配置文件位于
/etc/apache2/sites-available/example.com.conf 提供来自
挂载的永久性磁盘位置

下图显示了存储在永久磁盘上的 Apache 提供的基本 HTML 页面：
您通过以下步骤构建此环境

创建一个附加了永久性磁盘的基础虚拟机：
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
您可以使用本文档开头定义的参数来命名 VM 并连接到正确的子网。启动盘和数据盘的名称也是从参数中分配的

要安装和配置简单网站，首先使用 SSH 连接到基本 VM：
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
在与 VM 的 SSH 会话中，创建一个脚本以在您选择的编辑器中配置 VM。以下示例使用 Nano 作为编辑器：
纳米配置-vm。
将以下配置脚本粘贴到文件中：
bin/bash 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 文件到已安装的Persistent disk sudo tee -a /var/www/example.com/index.html >/dev/null EOF'    HA / DR 示例   
欢迎使用 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-X

使配置脚本可执行，然后运行它：
chmod +x 配置虚拟机../配置虚拟机。
退出与 VM 的 SSH 会话：
出口
获取 VM 的 IP 地址并使用
curl查看基本网页：
curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP
返回基本网站，如以下示例输出所示：
    HA / DR 示例   
欢迎使用 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-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 创建模板-$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\ 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 # 为 VM 实例创建健康检查 gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \ --port 80 # 创建托管实例组 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 托管创建实例组-$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## 创建和配置负载均衡器
为了让用户访问您的网站，您需要允许流量通过托管实例组中运行的虚拟机。如果托管实例组中出现区域故障，您还希望自动将流量重定向到新虚拟机

在下一节中，您将创建一个外部 HTTPS 负载均衡器，并为端口 80 上的 HTTP 流量提供后端服务，使用在前面的步骤中创建的运行状况检查，并将外部 IP 地址映射到后端服务

有关详细信息，请参阅如何设置简单的外部 HTTP 负载平衡器

为您的应用程序创建和配置负载均衡器：
# 配置 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- 的端口规则named-ports \ instance-group-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # 创建后端服务并将托管实例组添加到其中 gcloud compute backend-services create \ web-后端服务-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --global gcloud compute backend-services add-backend \ web-后端服务-$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 compute url-maps create网络地图-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # 配置 HTTP 流量的转发 gcloud compute target-http-proxies create \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http- $NAME_SUFFIX gcloud compute forwarding-rules 创建 \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
获取网络流量转发规则的 IP 地址：
IP_ADDRESSgcloud 计算转发规则描述 http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress
使用
curl，或打开您的 Web 浏览器，使用上一步中负载均衡器的 IP 地址查看网站：
卷曲 $IP_ADDRESS
负载均衡器需要几分钟才能完成部署并将流量正确定向到您的后端。如果负载平衡器仍在部署，则会返回 HTTP 404 错误。如果需要，请等待几分钟并再次尝试访问该网站

返回基本网站，如以下示例输出所示：
    HA / DR 示例   
欢迎使用 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.