Google CloudЦей документ призначений для архітекторів і людей, які працюють в операційних і адміністративних групах. У документі описано приклад шаблону, який можна використовувати для власного розгортання в Google Cloud У цьому шаблоні Cloud DNS спрямовує трафік до примірників Compute Engine у керованих групах примірників, які обслуговують вміст. У разі збою ви оновлюєте зону Cloud DNS і переходите на статичний сайт у Cloud Storage Щоб пройти цей підручник, вам потрібне зареєстроване доменне ім’я, яким ви керуєте та хочете використовувати його з цим документом У робочих розгортаннях ваш веб-сайт, імовірно, містить набагато більше файлів і додаткового коду програми на віртуальних машинах (ВМ) групи керованих екземплярів, ніж показано в цьому документі. Тоді Cloud Storage розміщує більш обмежену статичну версію, яка забезпечує мінімальну функціональність. У сценарії гарячого відновлення після відмови користувачі бачать цей обмежений веб-сайт, доки керовані групи екземплярів не відновляться та не зможуть обслуговувати трафік для повного використання веб-сайту У цьому посібнику ви розгортаєте ресурси для створення середовища, як показано на наступному зображенні: Коли вам потрібно виконати збій, ви оновлюєте конфігурацію Cloud DNS, щоб спрямувати трафік у Cloud Storage, як показано на наступному зображенні: Цей шаблон гарячого відновлення після відмови врівноважує вартість запуску іншої керованої групи екземплярів в іншому регіоні, який ви використовуєте лише тоді, коли основний регіон виходить з ладу. Вартість статичного сайту з використанням хмарного сховища нижча, ніж запуск іншої керованої групи екземплярів, але існує невелика затримка, коли ви оновлюєте хмарний DNS між параметрами хостингу. Обмежений досвід веб-сайту в Cloud Storage краще, ніж повністю недоступний веб-сайт і погана взаємодія з клієнтами Для альтернативного підходу, який використовує зовнішнє балансування навантаження HTTP(S) замість Cloud DNS для керування відмовами, див. Розгортання теплого відновлюваного веб-сервера за допомогою Compute Engine і Cloud Storage. Цей шаблон корисний, якщо у вас немає або ви не хочете використовувати Cloud DNS Щоб працювати з надійними програмами в Google Cloud, ми рекомендуємо розробити інфраструктуру додатків так, щоб справлятися з перебоями. Залежно від вашої програми та бізнес-потреб вам може знадобитися холодний, теплий або гарячий шаблони відновлення після відмови. Додаткову інформацію про те, як визначити найкращий підхід для ваших власних програм, див. у посібнику з планування аварійного відновлення У цьому документі використовується базовий веб-сервер Apache, але той самий підхід до розгортання інфраструктури застосовується до інших середовищ програм, які потрібно створити ## Цілі - Створюйте регіональні групи керованих екземплярів із власним образом віртуальної машини - Створіть відро Cloud Storage - Створіть і налаштуйте зону Cloud 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 CLI на консолі Google Cloud, використовуйте Cloud Shell ## Підготуйте середовище У цьому розділі ви визначаєте деякі змінні для назв ресурсів і розташування. Ці змінні використовуються командами Google Cloud CLI під час розгортання ресурсів У цьому посібнику, якщо не зазначено інше, ви вводите всі команди в Cloud Shell або локальному середовищі розробки Замінити з вашим власним ідентифікатором проекту. Якщо потрібно, надайте власний суфікс назви для ресурсів, щоб допомогти їх шукати та ідентифікувати, наприклад PROJECT_ID додаток Вкажіть два регіони, наприклад і нас-захід1 , а також зону в одному з цих регіонів, наприклад нас-захід2 . Ця зона визначає, де створюється початкова базова віртуальна машина, яка використовується для створення образу для групи керованих екземплярів us-west1-a Нарешті, установіть домен, який використовуватиметься для вашого статичного веб-сайту, наприклад example.com PROJECT_ID= PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com ## Створіть VPC і підмережу Щоб забезпечити мережевий доступ до віртуальних машин, ви створюєте віртуальну приватну хмару (VPC) і підмережі. Оскільки вам потрібні керовані групи екземплярів у двох регіонах, ви створюєте одну підмережу в кожному регіоні. Щоб отримати додаткові відомості про переваги спеціального режиму підмережі для керування діапазонами IP-адрес, що використовуються у вашому середовищі, див. розділ Використання мереж VPC спеціального режиму Створіть VPC із спеціальним режимом підмережі: gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom Тепер створіть дві підмережі в новому VPC, по одній для кожного регіону. Визначте власні діапазони адрес, наприклад і 10.1.0.0/20 , які відповідають діапазону вашої мережі: 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 gcloud compute networks subnets create \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range= 10.2.0.0/20\ --region=$ РЕГІОН2 ## Створення правил брандмауера Щоб дозволити мережевому трафіку правильно проходити у VPC, використовуйте правила брандмауера Створіть правила брандмауера, щоб дозволити веб-трафік і перевірку працездатності для балансувальника навантаження та керованих груп екземплярів: gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:80 \ -- source-ranges=0.0.0.0/0 \ --target-tags=http-server gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --action=allow \ - -direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80 Правило HTTP дозволяє трафік до будь-якої віртуальної машини, де http-servertag застосовується з будь-якого джерела за допомогою 0.0.0.0/0 діапазон. Для правила перевірки працездатності встановлено діапазони за замовчуванням для Google Cloud, щоб дозволити платформі правильно перевіряти працездатність ресурсів Щоб дозволити трафік SSH для початкової конфігурації базового образу віртуальної машини, охопіть правило брандмауера своїм середовищем за допомогою --source-rangeparameter. Можливо, вам доведеться попрацювати зі своєю мережевою командою, щоб визначити, які діапазони джерел використовує ваша організація Замінити з вашими власними областями 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 \ -- джерело-діапазони= IP_ADDRESS_SCOPE Після створення правил брандмауера перевірте, чи додано три правила: gcloud compute firewall-rules list \ --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 ## Створіть і налаштуйте базовий образ віртуальної машини Щоб створити ідентичні віртуальні машини, які ви розгортаєте без додаткової конфігурації, ви використовуєте спеціальний образ віртуальної машини. Це зображення фіксує конфігурацію ОС і Apache і використовується для створення кожної віртуальної машини в групі керованих екземплярів у наступних кроках На віртуальній машині ви створюєте базову index.html на постійному диску та змонтувати його /var/www/example.com. Файл конфігурації Apache за адресою /etc/apache2/sites-available/example.com.conf обслуговує веб-вміст із змонтоване розташування постійного диска На наступній діаграмі показано базову сторінку HTML, яка обслуговується Apache і зберігається на постійному диску: Ви створюєте це середовище, виконавши наступні кроки Створіть базову віртуальну машину з підключеним постійним диском: 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 Ви використовуєте параметри, визначені на початку цього документа, щоб назвати віртуальну машину та підключитися до правильної підмережі. Імена також призначаються з параметрів для завантажувального диска та диска даних Щоб установити та налаштувати простий веб-сайт, спочатку підключіться до базової віртуальної машини за допомогою SSH: gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE У вашому сеансі SSH до віртуальної машини створіть сценарій для налаштування віртуальної машини в обраному вами редакторі. У наступному прикладі як редактор використовується Nano: nano configure-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,відкинути $DISK_PATH sudo mount -o відкинути,за замовчуванням $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'Приклад 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 configure-vm../configure-vm. Вийдіть із сеансу SSH до віртуальної машини: вихід Отримайте IP-адресу віртуальної машини та використовуйте curl, щоб переглянути основну веб-сторінку: curl $(примірники gcloud compute описують 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 створити шаблон-$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\ значення\ /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\ значення\ /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 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 managed create instance-group -$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 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- 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 # Створення URL-карти для серверної служби gcloud compute url-maps create web-map-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 create \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80 Отримайте IP-адресу правила переадресації для веб-трафіку: IP_ADDRESSgcloud compute forwarding-rules описують http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress використання curl або відкрийте веб-браузер, щоб переглянути веб-сайт за допомогою IP-адреси балансувальника навантаження з попереднього кроку: curl $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.
Розгорніть теплий відновлюваний веб-сервер за допомогою Cloud DNS із Compute Engine і Cloud Storage | Центр хмарної архітектури | Google Cloud
Дізнайтеся, як використовувати теплий шаблон відновлення після відмови для веб-серверів за допомогою Cloud DNS і Compute Engine VMs і Cloud Storage.
