Esegui il deployment di un server web recuperabile tiepido utilizzando Cloud DNS con Compute Engine e Cloud Storage

Last reviewed 2021-06-28 UTC

---

Questo documento è destinato agli architetti e alle persone che lavorano nei team operativi e amministrativi. Il documento descrive un pattern di esempio che puoi utilizzare per i tuoi deployment in Google Cloud.

In questa architettura, Cloud DNS indirizza il traffico alle istanze di Compute Engine nei gruppi di istanze gestite che pubblicano i contenuti. In caso di interruzione, aggiorni la zona Cloud DNS ed esegui il failover di un sito statico in Cloud Storage.

Per eseguire il deployment di questa soluzione, è necessario un nome di dominio registrato che controlli e vuoi utilizzare con questo documento.

Nei deployment di produzione, il tuo sito web probabilmente include molti più file e codice dell'applicazione aggiuntivo sulle macchine virtuali (VM) del gruppo di istanze gestite rispetto a quanto mostrato in questo documento. Cloud Storage ospita quindi una versione statica più limitata che fornisce funzionalità minime. In uno scenario di failover a caldo, gli utenti visualizzano questo sito web limitato finché i gruppi di istanze gestite non recuperano e possono gestire il traffico per l'esperienza completa del sito web.

Architettura

In questa architettura, eseguirai il deployment delle risorse per creare un ambiente, come mostrato nell'immagine seguente:

Quando devi eseguire il failover, aggiorna la configurazione di Cloud DNS in modo da indirizzare il traffico a Cloud Storage, come illustrato nell'immagine seguente:

Questo pattern di failover caldo bilancia il costo dell'esecuzione di un altro gruppo di istanze gestite in una regione diversa che utilizzi solo in caso di errore della regione principale. Il costo di un sito statico che utilizza Cloud Storage è inferiore rispetto all'esecuzione di un altro gruppo di istanze gestite, ma si verifica un breve ritardo quando aggiorni Cloud DNS tra le opzioni di hosting. L'esperienza limitata sui siti web in Cloud Storage è migliore di un sito web completamente non disponibile e un'esperienza cliente scadente.

Per un approccio alternativo che utilizza un bilanciatore del carico delle applicazioni esterno anziché Cloud DNS per controllare il failover, consulta Eseguire il deployment di un server web recuperabile a caldo con Compute Engine e Cloud Storage. Questo pattern è utile se non hai o non vuoi utilizzare Cloud DNS.

Per eseguire applicazioni affidabili in Google Cloud, ti consigliamo di progettare l'infrastruttura dell'applicazione in modo da gestire le interruzioni. A seconda delle esigenze della tua applicazione e della tua azienda, potresti avere bisogno di un failover a freddo, un failover a caldo o un pattern di failover a caldo. Per ulteriori informazioni su come determinare l'approccio migliore per le tue applicazioni, consulta la Guida alla pianificazione del ripristino di emergenza.

Questo documento utilizza un server web Apache di base, ma lo stesso approccio al deployment dell'infrastruttura si applica agli altri ambienti applicativi che devi creare.

Obiettivi

• Crea gruppi di istanze gestite a livello di regione con un'immagine VM personalizzata.
• Creare un bucket Cloud Storage.
• Crea e configura una zona Cloud DNS.
• Testa il failover del server web a caldo con record Cloud DNS aggiornati.
• Testa il ripristino e il failover con i record Cloud DNS aggiornati.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

• Compute Engine
• Networking
• Cloud DNS
• Cloud Storage

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Prima di iniziare

I vincoli di sicurezza definiti dalla tua organizzazione potrebbero impedirti di completare i passaggi seguenti. Per informazioni sulla risoluzione dei problemi, vedi Sviluppare applicazioni in un ambiente Google Cloud vincolato.

1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

2. Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

   Nota: se non prevedi di conservare le risorse create in questa procedura, crea un progetto anziché selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associate.

   Vai al selettore progetti

3. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

4. Attiva l'API Compute Engine .

   Abilita l'API

5. Installa Google Cloud CLI.

6. Per initialize gcloud CLI, esegui questo comando:

   gcloud init

7. Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

   Nota: se non prevedi di conservare le risorse create in questa procedura, crea un progetto anziché selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associate.

   Vai al selettore progetti

8. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

9. Attiva l'API Compute Engine .

   Abilita l'API

10. Installa Google Cloud CLI.

11. Per initialize gcloud CLI, esegui questo comando:

    gcloud init

Puoi eseguire Google Cloud CLI nella console Google Cloud senza installare Google Cloud CLI. Per eseguire gcloud CLI nella console Google Cloud, utilizza Cloud Shell.

Prepara l'ambiente

In questa sezione definisci alcune variabili per le località e i nomi delle risorse. Queste variabili sono utilizzate dai comandi di Google Cloud CLI durante il deployment delle risorse.

Durante questo deployment, se non diversamente indicato, dovrai inserire tutti i comandi in Cloud Shell o nel tuo ambiente di sviluppo locale.

1. Sostituisci PROJECT_ID con l'ID del tuo progetto. Se vuoi, fornisci il tuo suffisso del nome per le risorse, ad esempio app, per facilitarne la ricerca e l'identificazione.

   Specifica due regioni, come us-west1 e us-west2, e una zona all'interno di una di queste regioni, ad esempio us-west1-a. Questa zona definisce dove viene creata la VM di base iniziale, utilizzata per creare un'immagine per il gruppo di istanze gestite.

   Infine, imposta un dominio da utilizzare per il tuo sito web statico, ad esempio example.com.

   PROJECT_ID=PROJECT_ID
   NAME_SUFFIX=app
   REGION1=us-west1
   REGION2=us-west2
   ZONE=us-west1-a
   DOMAIN=example.com
   

Crea un VPC e una subnet

Per fornire l'accesso di rete alle VM, puoi creare Virtual Private Cloud (VPC) e subnet. Poiché hai bisogno di gruppi di istanze gestite in due regioni, devi creare una subnet in ciascuna regione. Per ulteriori informazioni sui vantaggi della modalità subnet personalizzata per gestire gli intervalli di indirizzi IP in uso nel tuo ambiente, consulta Utilizzare le reti VPC in modalità personalizzata.

1. Crea il VPC con una modalità di subnet personalizzata:

   gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
   

2. Ora crea due subnet nel nuovo VPC, una per ogni area geografica. Definisci intervalli di indirizzi personalizzati, come 10.1.0.0/20 e 10.2.0.0/20, che rientrano nell'intervallo di rete:

   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=$REGION2
   

Crea regole firewall

Per consentire il corretto flusso del traffico di rete nel VPC, utilizza le regole firewall.

1. Crea regole firewall per consentire il traffico web e i controlli di integrità per il bilanciatore del carico e i gruppi di istanze gestite:

   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
   

   La regola HTTP consente il traffico verso qualsiasi VM in cui è applicato il tag http-server e da qualsiasi origine che utilizzi l'intervallo 0.0.0.0/0. Per la regola per il controllo di integrità, gli intervalli predefiniti per Google Cloud sono impostati in modo da consentire alla piattaforma di verificare correttamente l'integrità delle risorse.

2. Per consentire il traffico SSH per la configurazione iniziale di un'immagine VM di base, limita l'ambito della regola firewall al tuo ambiente utilizzando il parametro --source-range. Potrebbe essere necessario collaborare con il team di rete per determinare quali intervalli di origine vengono utilizzati dalla tua organizzazione.

   Attenzione: non è consigliabile utilizzare un intervallo 0.0.0.0/0 ampio che consenta tutto il traffico. Per limitare il traffico a un singolo indirizzo IP, utilizza una maschera di rete /32, ad esempio 35.230.62.163/32.

   Sostituisci IP_ADDRESS_SCOPE con i tuoi ambiti degli indirizzi IP:

   gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:22 \
       --source-ranges=IP_ADDRESS_SCOPE
   

3. Dopo aver creato le regole firewall, verifica che siano state aggiunte:

   gcloud compute firewall-rules list \
       --project=$PROJECT_ID \
       --filter="NETWORK=network-$NAME_SUFFIX"
   

   Il seguente output di esempio mostra che le tre regole sono state create correttamente:

   NAME                    NETWORK      DIRECTION  PRIORITY  ALLOW
   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
   

Crea e configura un'immagine VM di base

Per creare VM identiche di cui esegui il deployment senza configurazioni aggiuntive, utilizza un'immagine VM personalizzata. Questa immagine acquisisce la configurazione del sistema operativo e di Apache e viene utilizzata nei passaggi successivi per creare ogni VM nel gruppo di istanze gestite.

Nota: in questo documento creerai e configurerai manualmente la VM di base e le immagini. Nei deployment di produzione, usa gli strumenti di deployment e le pipeline esistenti per automatizzare il più possibile il processo. Per saperne di più, consulta Gestire l'infrastruttura come codice con Terraform, Cloud Build e GitOps.

Sulla VM, puoi creare un file index.html di base sul disco permanente e montarlo in /var/www/example.com. Un file di configurazione Apache in /etc/apache2/sites-available/example.com.conf pubblica contenuti web dal percorso del disco permanente montato.

Il seguente diagramma mostra la pagina HTML di base fornita da Apache e archiviata sul disco permanente:

Per creare questo ambiente, segui questi passaggi.

1. Crea una VM di base con un disco permanente collegato:

   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
   

   Utilizza i parametri definiti all'inizio di questo documento per assegnare un nome alla VM e connetterti alla subnet corretta. Vengono assegnati nomi anche dai parametri per il disco di avvio e il disco dati.

2. Per installare e configurare il sito web semplice, connettiti prima alla VM di base utilizzando SSH:

   gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
   

3. Nella sessione SSH per la VM, crea uno script per configurare la VM in un editor a tua scelta. L'esempio seguente utilizza Nano come editor:

   nano configure-vm.sh
   

   Incolla il seguente script di configurazione nel file:

   #!/bin/bash
   
   NAME_SUFFIX=app
   
   # Create directory for the basic website files
   sudo mkdir -p /var/www/example.com
   sudo chmod a+w /var/www/example.com
   sudo chown -R www-data: /var/www/example.com
   
   # Find the disk name, then format and mount it
   DISK_NAME="google-disk-base-$NAME_SUFFIX"
   DISK_PATH="$(find /dev/disk/by-id -name "${DISK_NAME}" | xargs -I '{}' readlink -f '{}')"
   
   sudo 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
   
   # Install Apache
   sudo apt-get update && sudo apt-get -y install apache2
   
   # Write out a basic HTML file to the mounted persistent disk
   sudo tee -a /var/www/example.com/index.html >/dev/null <<'EOF'
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   EOF
   
   # Write out an Apache configuration file
   sudo tee -a /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF'
   <VirtualHost *: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
   </VirtualHost>
   EOF
   
   # Enable the Apache configuration file and reload service
   sudo a2dissite 000-default
   sudo a2ensite example.com.conf
   sudo systemctl reload apache2
   

   Aggiorna la variabile NAME_SUFFIX in modo che corrisponda al valore impostato all'inizio di questo documento, ad esempio app.

4. Scrivi il file ed esci dall'editor. Ad esempio, in Nano usi Ctrl-O per scrivere il file, quindi esci con Ctrl-X.

5. Rendi eseguibile lo script di configurazione, quindi eseguilo:

   chmod +x configure-vm.sh
   ./configure-vm.sh
   

6. Esci dalla sessione SSH sulla VM:

   exit
   

7. Ottieni l'indirizzo IP della VM e usa curl per visualizzare la pagina web di base:

   curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \
       --zone $ZONE \
       --format="value(networkInterfaces.accessConfigs.[0].natIP)")
   

   Viene restituito il sito web di base, come mostrato nell'output di esempio seguente:

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

   Questo passaggio conferma che Apache sia configurato correttamente e che la pagina venga caricata dal disco permanente collegato. Nelle sezioni seguenti creerai un'immagine utilizzando questa VM di base e configurerai un modello di istanza con uno script di avvio.

Esegui il deployment delle risorse Compute Engine

Questo pattern di failover a caldo utilizza gruppi di istanze gestite per eseguire le VM. I gruppi di istanze gestite vengono eseguiti in due regioni e ogni gruppo monitora l'integrità delle VM. Se si verifica un'interruzione e una delle VM non funziona, il gruppo di istanze gestite ricrea la VM. Questa configurazione crea un'applicazione ad alta disponibilità, anche senza il failover a caldo in un sito statico in Cloud Storage.

1. Prima di poter creare un'immagine, devi arrestare la VM:

   gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE
   

2. Esegui questo set di comandi per creare le immagini VM, i modelli di istanza e i gruppi di istanze gestite:

   # Create the base VM images
   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
   
   # Create instance templates
   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 \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'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 \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \
       --image=image-$NAME_SUFFIX \
       --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes
   
   # Create a health check for VM instances
   gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \
       --port 80
   
   # Create the managed instance groups
   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
   

Crea e configura un bilanciatore del carico

Affinché gli utenti possano accedere al tuo sito web, devi consentire il traffico verso le VM in esecuzione nei gruppi di istanze gestite. Vuoi anche reindirizzare automaticamente il traffico a nuove VM in caso di errore di una zona in un gruppo di istanze gestite.

Nella sezione seguente, crei un bilanciatore del carico HTTPS esterno con un servizio di backend per il traffico HTTP sulla porta 80, utilizzi il controllo di integrità creato nei passaggi precedenti e mappa un indirizzo IP esterno tramite il servizio di backend.

Per saperne di più, consulta Come configurare un bilanciatore del carico HTTP esterno semplice.

1. Crea e configura il bilanciatore del carico per la tua applicazione:

   # Configure port rules for HTTP port 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
   
   # Create a backend service and add the managed instance groups to it
   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
   
   # Create a URL map for the backend service
   gcloud compute url-maps create web-map-http-$NAME_SUFFIX \
       --default-service web-backend-service-$NAME_SUFFIX
   
   # Configure forwarding for the HTTP traffic
   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
   

2. Ottieni l'indirizzo IP della regola di forwarding per il traffico web:

   IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \
       --global \
       --format="value(IPAddress)")
   

3. Utilizza curl o apri il browser web per visualizzare il sito web utilizzando l'indirizzo IP del bilanciatore del carico del passaggio precedente:

   curl $IP_ADDRESS
   

   Il bilanciatore del carico impiega alcuni minuti per completare il deployment e indirizzare correttamente il traffico al tuo backend. Viene restituito un errore HTTP 404 se il deployment del bilanciatore del carico è ancora in corso. Se necessario, attendi qualche minuto e riprova ad accedere al sito web.

   Viene restituito il sito web di base, come mostrato nell'output di esempio seguente:

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

Crea e configura un bucket di archiviazione

Cloud Storage viene utilizzato per archiviare file statici del sito web. In questo esempio di base, crei un unico file con testo leggermente diverso rispetto a quello presente sulle VM.

Nei deployment di produzione, il tuo sito web probabilmente include molti più file e codice dell'applicazione aggiuntivo sulle VM del gruppo di istanze gestite rispetto a quello mostrato in questo documento. La versione statica ospitata in Cloud Storage è spesso una versione più limitata che fornisce funzionalità minime. In uno scenario di failover a caldo, questo sito web limitato di Cloud Storage viene visualizzato fino a quando i gruppi di istanze gestite non recuperano e possono gestire il traffico per l'esperienza completa del sito web.

1. Verifica il dominio che vuoi utilizzare con il bucket Cloud Storage.

2. Crea un bucket Cloud Storage che corrisponda al nome del dominio che possiedi e vuoi utilizzare:

   gsutil mb gs://static-web.$DOMAIN
   

   Viene utilizzata la variabile DOMAIN definita all'inizio di questo documento, ad esempio example.com. Questo esempio archivia i file statici in static-web.example.com.

3. Crea un file locale che copi nel bucket Cloud Storage nel passaggio successivo:

   cat <<EOF > index.html
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test static web server with warm failover from Cloud Storage!</p>
   </body>
   </html>
   EOF
   

4. Carica il file HTML di base nel bucket Cloud Storage:

   gsutil cp index.html gs://static-web.$DOMAIN
   

5. Per consentire agli utenti di visualizzare i contenuti web statici, imposta le autorizzazioni appropriate nel bucket Cloud Storage:

   gsutil iam ch allUsers:objectViewer gs://static-web.$DOMAIN
   

6. Configura il bucket Cloud Storage in modo che pubblichi il file index.html come pagina web predefinita:

   gsutil web set -m index.html gs://static-web.$DOMAIN
   

Crea una zona e un record DNS

Per consentire che il traffico venga indirizzato al sito statico attivo su Cloud Storage in caso di interruzione dei gruppi di istanze gestite, crea una zona Cloud DNS. In condizioni normali, questa zona DNS indirizza il traffico attraverso il bilanciatore del carico esterno ai gruppi di istanze gestite creati nelle sezioni precedenti.

Nota: con un approccio al failover basato su DNS, gli utenti continuano a risolvere il vecchio indirizzo del bilanciatore del carico fino alla scadenza del record DNS memorizzato nella cache. Il periodo di tempo in cui il record DNS memorizzato nella cache esiste per un utente viene definito con il valore di durata (TTL) quando crei i record Cloud DNS. Poiché questo documento descrive un pattern di failover a caldo, una certa quantità di tempi di inattività dovrebbe essere prevista come parte di equilibrio tra un pattern di failover a caldo con costi aggiuntivi e complessità di configurazione.

1. Crea una zona Cloud DNS:

   gcloud dns managed-zones create zone-$NAME_SUFFIX \
       --dns-name=$DOMAIN \
       --description="DNS zone for warm site failover"
   

   Viene utilizzata la variabile DOMAIN definita all'inizio di questo documento, ad esempio example.com

2. Visualizza i dettagli della zona Cloud DNS:

   gcloud dns managed-zones describe zone-$NAME_SUFFIX
   

   L'output di esempio seguente mostra il valore nameServers per la zona, ad esempio 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.
   

3. Cloud DNS deve essere autorevole per il tuo dominio. Crea record dei server dei nomi (NS) con il tuo registrar di domini che rimandano alla zona Cloud DNS. Utilizza gli indirizzi dei server dei nomi restituiti nel passaggio precedente.

   Per ulteriori informazioni e un esempio sull'utilizzo di Google Domains, vedi Come aggiornare i server dei nomi.

4. Nella tua zona Cloud DNS, aggiungi un record per www utilizzando l'indirizzo IP del bilanciatore del carico ottenuto in una sezione precedente:

   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
   

   Questo record indirizza le richieste degli utenti per il sito web tramite il bilanciatore del carico ai gruppi di istanze gestite. È impostato un TTL di 300 secondi per ridurre il periodo di tempo in cui il record DNS memorizzato nella cache esiste per un utente.

5. Crea un record che deve essere utilizzato dal bucket Cloud Storage per il sito web statico:

   gcloud dns record-sets transaction add c.storage.googleapis.com. \
       --name=static-web.$DOMAIN \
       --ttl=300 \
       --type=CNAME \
       --zone=zone-$NAME_SUFFIX
   

   In questo esempio viene utilizzato static-web come sottodominio. Lascia il campo c.storage.googleapis.com. Anche in questo caso, viene impostato un TTL di 300 secondi per ridurre il periodo di tempo in cui il record DNS memorizzato nella cache esiste per un utente

6. Infine, esegui il commit delle aggiunte dei record DNS nella zona:

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

Verificare e testare la zona e i record DNS

Esaminiamo i deployment delle risorse prima di simulare un errore di zona. Tutte le risorse sono state create a supporto dell'ambiente, come mostrato nella seguente immagine:

• I record di zona Cloud DNS indirizzano gli utenti al bilanciatore del carico per la distribuzione tra le VM del gruppo di istanze gestite.
• Un bucket Cloud Storage è configurato per ospitare pagine web statiche in caso di interruzione dei gruppi di istanze gestite.
• La zona Cloud DNS è configurata per utilizzare il sito statico in Cloud Storage, ma al momento non risolve le richieste al bucket di archiviazione.

Per visualizzare i record DNS e testare la risoluzione dei problemi, devi risolvere gli indirizzi nei server Cloud DNS. Nei deployment di produzione, assicurati di testare e verificare che gli indirizzi vengano risolti correttamente, quindi aggiorna i tuoi server DNS per risolvere in modo appropriato. Questo documento non descrive in dettaglio i passaggi per aggiornare i server DNS, ma solo come verificare correttamente i flussi di traffico in condizioni normali e di failover.

1. Recupera di nuovo i dettagli della zona Cloud DNS:

   gcloud dns managed-zones describe zone-$NAME_SUFFIX
   

   L'output di esempio seguente mostra il valore nameServers per la zona, ad esempio 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.
   

2. Per risolvere il record www per la tua zona Cloud DNS in base a uno di questi server dei nomi, utilizza il comando dig:

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   In questo esempio viene utilizzato l'indirizzo del server dei nomi ns-cloud-b1.googledomains.com, restituito dal precedente comando describe. Fornisci l'indirizzo del tuo server dei nomi visualizzato nell'output del comando precedente

   Il seguente output di esempio mostra che il record viene risolto nell'indirizzo IP del bilanciatore del carico. Se hai utilizzato questo server dei nomi per accedere all'indirizzo, ad esempio curl e il parametro --resolve con il server dei nomi Cloud DNS, la pagina predefinita verrebbe visualizzata da uno dei gruppi di istanze gestite dietro il bilanciatore del carico.

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com 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
   

3. Utilizza di nuovo il comando dig per verificare il record DNS per il sito web statico in Cloud Storage:

   dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN
   

   L'output di esempio seguente mostra che il record viene risolto in Cloud Storage, che può pubblicare i contenuti statici dal bucket di archiviazione:

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com 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.
   

Esegui il failover nel bucket Cloud Storage

In un ambiente di produzione, potresti ricevere un avviso utilizzando Cloud Monitoring o un'altra soluzione di monitoraggio quando si verifica un problema con i gruppi di istanze gestite. Questo avviso richiede a una persona di comprendere l'ambito dell'errore prima di aggiornare i record Cloud DNS in modo da reindirizzare il traffico al sito web statico ospitato su Cloud Storage. Un approccio alternativo consiste nell'utilizzare la tua soluzione di monitoraggio per rispondere automaticamente alle interruzioni con i gruppi di istanze gestite.

Quando esegui il failover, Cloud DNS risolve il traffico verso il sito web statico ospitato su Cloud Storage, come mostrato nell'immagine seguente:

Quando tu o la tua soluzione di monitoraggio determinate l'azione più appropriata è aggiornare i record Cloud DNS per indirizzare il traffico a Cloud Storage, aggiorna il record A DNS esistente. In questo documento, aggiorni manualmente i record Cloud DNS per reindirizzare il traffico al sito web statico ospitato su Cloud Storage.

1. Per eseguire il failover dei record Cloud DNS, rimuovi il record A esistente che viene risolto nel bilanciatore del carico:

   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
   

2. Crea un record CNAME per www che rimandi ai contenuti ospitati da Cloud Storage:

   gcloud dns record-sets transaction add static-web.$DOMAIN \
       --name=www.$DOMAIN. \
       --ttl=30 \
       --type=CNAME \
       --zone=zone-$NAME_SUFFIX
   

3. Esegui il commit degli aggiornamenti nella zona Cloud DNS:

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

4. Utilizza il comando dig per verificare che il record www venga ora risolto nell'indirizzo del sito web statico di Cloud Storage:

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   Il seguente output di esempio mostra che il record www.example.com viene risolto nel record CNAME del sito web statico di Cloud Storage. Le richieste di accesso a www.example.com vengono reindirizzate al bucket Cloud Storage, che visualizza il sito web statico:

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com 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.
   

Esegui il failover dei gruppi di istanze gestite

Una volta risolti i problemi con i gruppi di istanze gestite, puoi non riuscire a gestire i contenuti dei gruppi di istanze gestite con bilanciamento del carico aggiornando di nuovo i record Cloud DNS. Anche in questo caso, una persona potrebbe prendere questa decisione utilizzando gli insight di Cloud Monitoring per l'integrità dei gruppi di istanze gestite. In alternativa, puoi utilizzare l'automazione per rispondere all'integrità ripristinata del gruppo di istanze gestite. In questo documento, si aggiornano manualmente i record Cloud DNS.

In caso di errore, Cloud DNS risolve nuovamente il traffico verso i gruppi di istanze gestite, come mostrato nell'immagine seguente:

1. Rimuovi il record CNAME www che reindirizza il traffico ai contenuti ospitati da Cloud Storage:

   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
   

2. Aggiungi di nuovo un record A per puntare al bilanciatore del carico davanti ai gruppi di istanze gestite:

   gcloud dns record-sets transaction add $IP_ADDRESS \
       --name=www.$DOMAIN \
       --ttl=300 \
       --type=A \
       --zone=zone-$NAME_SUFFIX
   

3. Esegui il commit degli aggiornamenti nella zona Cloud DNS:

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

4. Utilizza ancora una volta il comando dig per verificare che il record www venga risolto nell'indirizzo del bilanciatore del carico davanti ai gruppi di istanze gestite:

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   Il seguente output di esempio mostra che il record viene risolto nell'indirizzo IP del bilanciatore del carico e il traffico verrà gestito da uno dei gruppi di istanze gestite:

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com 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
   

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Per eliminare le singole risorse create in questo documento, completa i seguenti passaggi:

1. Elimina la zona e i record DNS:

   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
   

2. Elimina il bucket Cloud Storage:

   gsutil rm -r gs://static-web.$DOMAIN
   

3. Elimina la configurazione del bilanciatore del carico:

   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
   

4. Elimina i gruppi di istanze gestite e il controllo di integrità:

   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
   

5. Elimina i modelli di istanza, le immagini, la VM di base e i dischi permanenti:

   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
   

6. Elimina le regole firewall.

   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
   

7. Elimina la subnet e il 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
   

Passaggi successivi

• Per un approccio alternativo che utilizza un bilanciatore del carico delle applicazioni esterno anziché Cloud DNS per controllare il failover, consulta Eseguire il deployment di un server web recuperabile a caldo con Compute Engine e Cloud Storage. Questo pattern è utile se non hai o non vuoi utilizzare Cloud DNS.
• Per scoprire come determinare l'approccio migliore per le tue applicazioni e quale metodo di ripristino utilizzare, consulta la Guida alla pianificazione del ripristino di emergenza.
• Per vedere altri pattern per le applicazioni, come il failover a caldo e a freddo, consulta Scenari di ripristino di emergenza per le applicazioni.
• Per conoscere altri modi per gestire scalabilità e disponibilità, consulta la sezione Pattern per app scalabili e resilienti.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.