Bu belge, operasyonlarda ve idari ekiplerde çalışan mimarlar ve kişiler için hazırlanmıştır. Belgede, Google Cloud'da kendi dağıtımlarınız için kullanabileceğiniz örnek bir model açıklanmaktadır.

Bu modelde Cloud DNS, trafiği içeriğe hizmet veren yönetilen örnek gruplarındaki Compute Engine örneklerine yönlendirir. Bir kesintide, Cloud DNS bölgesini günceller ve Cloud Storage'daki statik bir siteye devredersiniz

Bu öğreticiyi tamamlamak için, kontrolünüzde olan ve bu belgeyle birlikte kullanmak istediğiniz kayıtlı bir alan adına ihtiyacınız var.

Üretim dağıtımlarında, web siteniz muhtemelen yönetilen örnek grubu sanal makinelerinizde (VM'ler) bu belgede gösterilenden çok daha fazla dosya ve ek uygulama kodu içerir. Cloud Storage daha sonra minimum işlevsellik sağlayan daha sınırlı bir statik sürüm barındırır. Sıcak bir yük devretme senaryosunda, kullanıcılar, yönetilen bulut sunucusu grupları iyileşene ve tam web sitesi deneyimi için trafik sunabilene kadar bu sınırlı web sitesini görür.

Bu öğreticide, aşağıdaki görüntüde gösterildiği gibi bir ortam oluşturmak için kaynakları dağıtacaksınız:
Yük devretmeniz gerektiğinde, trafiği aşağıdaki resimde gösterildiği gibi Bulut Depolamaya yönlendirmek için Bulut DNS yapılandırmasını güncellersiniz:
Bu sıcak yük devretme modeli, yalnızca birincil bölge başarısız olduğunda kullandığınız farklı bir bölgede başka bir yönetilen bulut sunucusu grubu çalıştırmanın maliyetini dengeler. Cloud Storage kullanan statik bir sitenin maliyeti, başka bir yönetilen örnek grubu çalıştırmaktan daha düşüktür, ancak barındırma seçenekleri arasında Cloud DNS'yi güncellerken kısa bir gecikme olur. Cloud Storage'daki sınırlı web sitesi deneyimi, tamamen kullanılamayan bir web sitesinden ve kötü müşteri deneyiminden daha iyidir

Yük devretmeyi kontrol etmek için Bulut DNS yerine harici HTTP(S) Yük Dengeleme kullanan alternatif bir yaklaşım için bkz. Compute Engine ve Bulut Depolama ile sıcak kurtarılabilir bir web sunucusu dağıtma. Bu model, Cloud DNS'e sahip değilseniz veya kullanmak istemiyorsanız kullanışlıdır.

Google Cloud'da güvenilir uygulamalar çalıştırmak için uygulama altyapınızı kesintileri kaldıracak şekilde tasarlamanızı öneririz. Uygulamanıza ve iş ihtiyaçlarınıza bağlı olarak, soğuk yük devretme, sıcak yük devretme veya sıcak yük devretme düzenine ihtiyacınız olabilir. Kendi uygulamalarınız için en iyi yaklaşımı nasıl belirleyeceğiniz konusunda daha fazla bilgi için Felaket kurtarma planlama kılavuzuna bakın.

Bu belge, temel bir Apache web sunucusu kullanır, ancak altyapı dağıtımına yönelik aynı yaklaşım, oluşturmanız gereken diğer uygulama ortamları için de geçerlidir.

## Hedefler

- Özel bir sanal makine görüntüsüyle bölgesel olarak yönetilen örnek grupları oluşturun

- Bir Bulut Depolama grubu oluşturun

- Bir Bulut DNS bölgesi oluşturun ve yapılandırın

- Sıcak web sunucusu yük devretmesini güncellenmiş Bulut DNS kayıtlarıyla test edin

- Güncellenmiş Bulut DNS kayıtlarıyla kurtarma ve yeniden çalışmayı test edin

## Maliyetler
Bu eğitici, Google Cloud'un aşağıdaki faturalandırılabilir bileşenlerini kullanır:
Öngörülen kullanımınıza dayalı bir maliyet tahmini oluşturmak için,
fiyat hesaplayıcıyı kullan

## Sen başlamadan önce
Kuruluşunuz Google Cloud ortamınıza kısıtlamalar uyguluyorsa bu belgedeki adımlardan bazıları doğru şekilde çalışmayabilir. Bu durumda, genel IP adresleri veya hizmet hesabı anahtarları oluşturma gibi görevleri tamamlayamayabilirsiniz. Kısıtlamalarla ilgili bir hata döndüren bir istekte bulunursanız, kısıtlamalı bir Google Cloud ortamında nasıl uygulama geliştirileceğini öğrenin.

- Google Cloud hesabınızda oturum açın. Google Cloud'da yeniyseniz, ürünlerimizin gerçek dünya senaryolarında nasıl performans gösterdiğini değerlendirmek için bir hesap oluşturun. Yeni müşteriler ayrıca iş yüklerini çalıştırmak, test etmek ve devreye almak için 300 ABD doları tutarında ücretsiz kredi kazanır.

-
Google Cloud konsolunda, proje seçici sayfasında bir Google Cloud projesi seçin veya oluşturun

-
Bulut projeniz için faturalandırmanın etkinleştirildiğinden emin olun. Bir projede faturalandırmanın etkinleştirilip etkinleştirilmediğini nasıl kontrol edeceğinizi öğrenin

-
Compute Engine API'yi etkinleştirin

- Google Cloud CLI'yi kurun ve başlatın

-
Google Cloud konsolunda, proje seçici sayfasında bir Google Cloud projesi seçin veya oluşturun

-
Bulut projeniz için faturalandırmanın etkinleştirildiğinden emin olun. Bir projede faturalandırmanın etkinleştirilip etkinleştirilmediğini nasıl kontrol edeceğinizi öğrenin

-
Compute Engine API'yi etkinleştirin

- Google Cloud CLI'yi kurun ve başlatın

Google Cloud CLI'yi, Google Cloud CLI'yi yüklemeden Google Cloud konsolunda çalıştırabilirsiniz. gcloud CLI'yi Google Cloud konsolunda çalıştırmak için Cloud Shell'i kullanın

## Ortamı hazırlayın
Bu bölümde, kaynak adlarınız ve konumlarınız için bazı değişkenler tanımlarsınız. Bu değişkenler, siz kaynakları dağıtırken Google Cloud CLI komutları tarafından kullanılır.

Bu eğitim boyunca, aksi belirtilmedikçe tüm komutları Cloud Shell'e veya yerel geliştirme ortamınıza girersiniz.

Yer değiştirmek
kendi proje kimliğiniz ile. İstenirse, kaynakları aramaya ve tanımlamaya yardımcı olacak kaynaklar için kendi ad son ekinizi sağlayın, örneğin:
PROJE_KİMLİĞİ


uygulama
gibi iki bölge belirtin.
ve
us-west1
ve bu bölgelerden biri içindeki bir bölge, örneğin
us-west2
. Bu bölge, yönetilen örnek grubu için bir görüntü oluşturmak için kullanılan ilk temel sanal makinenin nerede oluşturulacağını tanımlar.

us-west1-a
Son olarak, statik web siteniz için kullanılan bir alan adı belirleyin, örneğin
örnek.com
PROJE_KİMLİĞİ=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## Bir VPC ve alt ağ oluşturun
VM'lere ağ erişimi sağlamak için Sanal Özel Bulut (VPC) ve alt ağlar oluşturursunuz. İki bölgede yönetilen bulut sunucusu gruplarına ihtiyaç duyduğunuz için her bölgede bir alt ağ oluşturursunuz. Ortamınızda kullanılan IP adresi aralıklarını yönetmek için özel alt ağ modunun avantajları hakkında daha fazla bilgi için bkz. Özel mod VPC ağlarını kullanma

VPC'yi özel bir alt ağ moduyla oluşturun:
gcloud bilgi işlem ağları, $NAME_SUFFIX --subnet-mode=özel ağ oluşturur
Şimdi yeni VPC'de her bölge için bir tane olmak üzere iki alt ağ oluşturun. Kendi adres aralıklarınızı tanımlayın, örneğin
ve
10.1.0.0/20
, ağ aralığınıza uyan:
10.2.0.0/20
gcloud bilgi işlem ağları alt ağları \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range= oluşturur
10.1.0.0/20\ --region=$REGION1 gcloud bilgi işlem ağları alt ağları \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range= 10.2.0.0/20\ --region=$ oluşturur BÖLGE2
## Güvenlik duvarı kuralları oluştur
Ağ trafiğinin VPC'de doğru şekilde akmasına izin vermek için güvenlik duvarı kurallarını kullanın

Yük dengeleyici ve yönetilen örnek grupları için web trafiğine ve durum denetimlerine izin vermek için güvenlik duvarı kuralları oluşturun:
gcloud bilgi işlem güvenlik duvarı kuralları oluştur allow-http-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=İZİN VER \ --rules=tcp:80 \ -- source-ranges=0.0.0.0/0 \ --target-tags=http-server gcloud hesaplama güvenlik duvarı-kuralları create allow-health-check-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --action=allow \ - -direction=giriş \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
HTTP kuralı, herhangi bir VM'ye trafiğe izin verir.
http-servertag uygulanır ve herhangi bir kaynaktan
0.0.0.0/0 aralığı. Durum denetimi kuralı için, Google Cloud'un varsayılan aralıkları, platformun kaynakların durumunu doğru bir şekilde kontrol etmesine izin verecek şekilde ayarlanmıştır.

Bir temel VM görüntüsünün ilk yapılandırması için SSH trafiğine izin vermek üzere, güvenlik duvarı kuralını
--kaynak aralığı parametresi. Kuruluşunuzun hangi kaynak aralıklarını kullandığını belirlemek için ağ ekibinizle birlikte çalışmanız gerekebilir.

Yer değiştirmek
kendi IP adresi kapsamlarınızla:
IP_ADDRESS_SCOPE
gcloud hesaplama güvenlik duvarı-kuralları oluşturmak allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=İZİN VER \ --rules=tcp:22 \ -- kaynak aralıkları=
IP_ADDRESS_SCOPE
 Güvenlik duvarı kurallarını oluşturduktan sonra, üç kuralın eklendiğini doğrulayın:
gcloud hesaplama güvenlik duvarı kuralları listesi \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"Aşağıdaki örnek çıktı, üç kuralın doğru şekilde oluşturulduğunu gösterir:
ADI AĞ YÖNÜ ÖNCELİK İZİN ver allow-health-check-app ağ-uygulaması INGRESS 1000 tcp:80 allow-http-app ağ-uygulaması INGRESS 1000 tcp:80 allow-ssh-app ağ-uygulaması GİRİŞ 1000 tcp:22
## Bir temel sanal makine görüntüsü oluşturun ve yapılandırın
Ek yapılandırma olmadan dağıttığınız özdeş VM'ler oluşturmak için özel bir VM görüntüsü kullanırsınız. Bu görüntü, işletim sistemi ve Apache yapılandırmasını yakalar ve sonraki adımlarda yönetilen örnek grubundaki her bir sanal makineyi oluşturmak için kullanılır.

Sanal makinede, temel bir
kalıcı diskteki index.html dosyası ve
monte et
/var/www/example.com. adresindeki bir Apache yapılandırma dosyası
/etc/apache2/sites-available/example.com.conf, web içeriğini şu adresten sunar:
bağlı kalıcı disk konumu

Aşağıdaki diyagram, kalıcı diskte saklanan ve Apache tarafından sunulan temel HTML sayfasını göstermektedir:
Bu ortamı aşağıdaki adımlarda oluşturursunuz

Kalıcı disk eklenmiş bir temel VM oluşturun:
gcloud bilgi işlem örnekleri, vm-base-$NAME_SUFFIX \ --zone=$ZONE \ --machine-type=n1-standard-1 \ --subnet=subnet-$NAME_SUFFIX-$REGION1 \ --tags=http-server \ oluşturur --image=debian-10-buster-v20210420 \ --image-project=debian-cloud \ --boot-disk-size=10GB \ --boot-disk-type=pd-dengeli \ --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
VM'yi adlandırmak ve doğru alt ağa bağlanmak için bu belgenin başında tanımlanan parametreleri kullanırsınız. Adlar ayrıca önyükleme diski ve veri diski için parametrelerden atanır.

Basit web sitesini kurmak ve yapılandırmak için önce SSH kullanarak temel VM'ye bağlanın:
gcloud hesaplama ssh vm-base-$NAME_SUFFIX --zone=$ZONE
VM'ye yönelik SSH oturumunuzda, VM'yi seçtiğiniz bir düzenleyicide yapılandırmak için bir betik oluşturun. Aşağıdaki örnek, düzenleyici olarak Nano'yu kullanır:
nano yapılandırma-vm.
Aşağıdaki yapılandırma komut dosyasını dosyaya yapıştırın:
bin/bash NAME_SUFFIX=
app# Temel web sitesi dosyaları için dizin oluşturun 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 adını bulun, ardından biçimlendirin ve bağlayın 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 throw,defaults $DISK_PATH /var/www/example.com # Apache'yi kurun sudo apt-get update&&  sudo apt-get -y install apache2 # Bağlı kalıcı diske temel bir HTML dosyası yazın sudo tee -a /var/www/example.com/index.html >/dev/null EOF'     HA / DR örneği   
 Cloud Storage'a sıcak yük devretme özelliğine sahip bir Compute Engine web sitesine hoş geldinizp>
*: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 yapılandırma dosyasını etkinleştirin ve hizmeti yeniden yükleyin sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
güncelle
bu belgenin başında ayarlanan değerle eşleşecek değişken, örneğin
NAME_SUFFIX uygulaması

Dosyayı yazın ve düzenleyicinizden çıkın. Örneğin, Nano'da kullandığınız
Ctrl-Oto dosyayı yazın, ardından ile çıkın
Ctrl-X

Yapılandırma betiğini yürütülebilir yapın, ardından çalıştırın:
chmod +x yapılandırma-vm../configure-vm.
SSH oturumundan sanal makineye çıkın:
çıkış
VM'nin IP adresini alın ve kullanın
temel web sayfasını görmek için kıvırın:
curl $(gcloud bilgi işlem örnekleri, vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP'yi açıklar)
Aşağıdaki örnek çıktıda gösterildiği gibi temel web sitesi döndürülür:
     HA / DR örneği   
 Cloud Storage'a sıcak yük devretme özelliğine sahip bir Compute Engine web sitesine hoş geldinizp>

# Temel sanal makine görüntülerini oluşturun gcloud bilgi işlem görüntüleri görüntü oluştur-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE gcloud bilgi işlem görüntüleri oluştur image-disk-$NAME_SUFFIX \ - -source-disk=disk-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE # Örnek şablonları oluştur gcloud hesaplama örnek-templates şablon oluştur-$NAME_SUFFIX-$REGION1 \ --machine-type=n1-standart- 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\ throw,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 hesaplama örneği-şablonları şablon oluştur-$NAME_SUFFIX-$REGION2 \ --machine -type=n1-standart-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\ throw,defaults ,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # Sanal makine örnekleri için bir durum denetimi oluşturun gcloud hesaplama durum denetimleri create http http-basic-check-$NAME_SUFFIX \ --port 80 # Yönetilen örnek gruplarını oluşturun gcloud hesaplama örnek-grupları yönetilen create instance-group-$NAME_SUFFIX-$REGION1 \ --template=template-$NAME_SUFFIX-$REGION1 \ --size=2 \ --region=$REGION1 \ --health-check=http-basic-check-$NAME_SUFFIX yönetilen gcloud işlem örnek grupları örnek grubu oluştur -$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## Bir yük dengeleyici oluşturun ve yapılandırın
Kullanıcıların web sitenize erişmesi için, trafiğin yönetilen örnek gruplarında çalışan sanal makinelere geçmesine izin vermeniz gerekir. Yönetilen bir örnek grubunda bir bölge hatası olması durumunda trafiği otomatik olarak yeni sanal makinelere yönlendirmek de isteyebilirsiniz.

Aşağıdaki bölümde, 80 numaralı bağlantı noktasındaki HTTP trafiği için bir arka uç hizmetiyle harici bir HTTPS yük dengeleyici oluşturur, önceki adımlarda oluşturulan durum denetimini kullanır ve harici bir IP adresini arka uç hizmetine eşlersiniz.

Daha fazla bilgi için bkz. Basit bir harici HTTP yük dengeleyici nasıl kurulur?

Uygulamanız için yük dengeleyiciyi oluşturun ve yapılandırın:
# HTTP bağlantı noktası 80 için bağlantı noktası kurallarını yapılandırın adlandırılmış bağlantı noktaları \ örnek-grubu-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # Bir arka uç hizmeti oluşturun ve yönetilen örnek gruplarını buna ekleyin gcloud hesaplama arka uç hizmetleri oluştur \ web- arka uç hizmeti-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --global gcloud bilgi işlem arka uç hizmetleri eklenti arka ucu \ web- backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \ --instance-group-region=$REGION1 \ --global gcloud bilgi işlem arka uç hizmetleri eklenti arka ucu \ web arka ucu- service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \ --instance-group-region=$REGION2 \ --global # Arka uç hizmeti için bir URL eşlemesi oluşturun gcloud hesaplama url-haritaları oluştur web haritası-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # HTTP trafiği için yönlendirmeyi yapılandırın gcloud hesaplama hedefi-http-proxies create \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http- $NAME_SUFFIX gcloud bilgi işlem iletme kuralları oluşturma \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
Web trafiği için yönlendirme kuralının IP adresini alın:
IP_ADDRESSgcloud bilgi işlem iletme kuralları, http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress) açıklar
Kullanmak
Önceki adımdaki yük dengeleyicinin IP adresini kullanarak web sitesini görüntülemek için kıvırın veya web tarayıcınızı açın:
$IP_ADDRESS kıvırmak
Yük dengeleyicinin dağıtımı tamamlaması ve trafiği doğru şekilde arka ucunuza yönlendirmesi birkaç dakika sürer. Yük dengeleyici hala dağıtılıyorsa bir HTTP 404 hatası döndürülür. Gerekirse, birkaç dakika bekleyin ve web sitesine tekrar erişmeyi deneyin.

Aşağıdaki örnek çıktıda gösterildiği gibi temel web sitesi döndürülür:
     HA / DR örneği   
 Cloud Storage'a sıcak yük devretme özelliğine sahip bir Compute Engine web sitesine hoş geldinizp>
< 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.