Configura CI/CD per archiviare la configurazione Terraform come codice

Questo tutorial spiega come gestire l'infrastruttura come codice con Terraform e Cloud Build utilizzando la popolare metodologia GitOps. Il termine GitOps è stato coniato per la prima volta da Weaveworks e il suo concetto chiave è l'utilizzo di un repository Git per archiviare lo stato dell'ambiente che desideri. Terraform è uno strumento open source di HashiCorp che consente di creare, modificare e migliorare in modo prevedibile l'infrastruttura cloud utilizzando il codice. In questo tutorial utilizzerai Cloud Build, un servizio di integrazione continua, per applicare automaticamente i manifest Terraform al tuo ambiente. Google Cloud

Questo tutorial è rivolto a sviluppatori e operatori che cercano una strategia elegante per apportare modifiche prevedibili all'infrastruttura. L'articolo presuppone che tu abbia familiarità con Google Cloude Linux.

I report State of DevOps hanno identificato le funzionalità che migliorano le prestazioni di distribuzione del software. Questo tutorial ti aiuterà a utilizzare le seguenti funzionalità:

• Controllo della versione
• Integrazione continua
• Continuous Delivery
• Test continui

Architettura

Questo tutorial applica le pratiche GitOps per la gestione delle esecuzioni di Terraform. Tieni presente che utilizza i rami dev e prod di Secure Source Manager per rappresentare gli ambienti effettivi. Questi ambienti sono definiti dalle reti Virtual Private Cloud (VPC) dev e prod, rispettivamente, all'interno di un progettoGoogle Cloud .

Il processo inizia quando esegui il push del codice Terraform nel ramo dev o prod. In questo scenario, Cloud Build attiva e poi applica i manifest Terraform per raggiungere lo stato desiderato nel rispettivo ambiente. D'altra parte, quando esegui il push del codice Terraform in un altro ramo, ad esempio in un ramo delle funzionalità, Cloud Build viene eseguito per eseguire terraform plan, ma non viene applicato nulla a nessun ambiente.

Idealmente, gli sviluppatori o gli operatori devono presentare proposte di infrastruttura a rami di sviluppo o di funzionalità e poi inviarle tramite richieste pull. In questo modo, puoi discutere e rivedere le potenziali modifiche con i collaboratori e aggiungere commit di follow-up prima che le modifiche vengano unite al ramo di base.

Se non vengono sollevati problemi, devi prima unire le modifiche al ramo dev. Questa unione attiva un deployment dell'infrastruttura nell'ambiente dev, consentendoti di testarlo. Dopo aver testato e aver verificato il deployment, devi unire il ramo dev al ramo prod per attivare l'installazione dell'infrastruttura nell'ambiente di produzione.

Obiettivi

• Configura l'istanza e il repository Secure Source Manager.
• Configura Terraform in modo da archiviare lo stato in un bucket Cloud Storage.
• Concedi le autorizzazioni al account di servizio Cloud Build.
• Connetti Cloud Build al repository Secure Source Manager.
• Modifica la configurazione dell'ambiente in un ramo delle funzionalità.
• Promuovi le modifiche nell'ambiente di sviluppo.
• Promuovi le modifiche all'ambiente di produzione.

Costi

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

• Cloud Build
• Cloud Storage
• Compute Engine

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

I nuovi utenti di Google Cloud potrebbero avere diritto a una prova senza costi.

Al termine delle attività descritte in questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse che hai creato. Per ulteriori informazioni, vedi Pulizia.

Prima di iniziare

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. In Cloud Shell, recupera l'ID del progetto appena selezionato:

   gcloud config get-value project

   Se questo comando non restituisce l'ID progetto, configura Cloud Shell per utilizzare il tuo progetto. Sostituisci PROJECT_ID con l'ID progetto.

   gcloud config set project PROJECT_ID

3. Abilita le API richieste:

   gcloud services enable cloudbuild.googleapis.com compute.googleapis.com securesourcemanager.googleapis.com

   Il completamento di questo passaggio potrebbe richiedere alcuni minuti.
4. Se non hai mai utilizzato Git in Cloud Shell, configuralo con il tuo nome e indirizzo email:

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_NAME"
   

   Git utilizza queste informazioni per identificarti come autore dei commit che crei in Cloud Shell.

Configura il repository Secure Source Manager

In questo tutorial utilizzi un singolo repository Secure Source Manager per definire la tua infrastruttura cloud. Orchestri questa infrastruttura con rami diversi corrispondenti a ambienti diversi:

• Il ramo dev contiene le ultime modifiche applicate all'ambiente di sviluppo.
• Il ramo prod contiene le ultime modifiche applicate all'ambiente di produzione.
• I branch delle funzionalità simili a feature_x vengono utilizzati per apportare modifiche prima di eseguire il push nei branch dev o prod.

Con questa infrastruttura, puoi sempre fare riferimento al repository per sapere quale configurazione è prevista in ogni ambiente e per proporre nuove modifiche unendole prima nell'ambiente dev. Quindi promuovi le modifiche unendo il ramo dev nel ramo prod successivo.

1. Crea un repository Secure Source Manager vuoto: non inizializzare il repository.

2. Aggiungi l'helper di autenticazione di Secure Source Manager al tuo git config globale eseguendo questo comando:

   git config --global credential.'https://*.*.sourcemanager.dev'.helper gcloud.sh
   

   L'helper per l'autenticazione utilizza gcloud CLI per recuperare le tue credenzialiGoogle Cloud quando utilizzi i comandi Git con Secure Source Manager.

3. Per eseguire nuovamente l'autenticazione dopo la configurazione iniziale delle credenziali, esegui questo comando gcloud CLI:

   gcloud auth login
   

4. Clona il repository solutions-terraform-cloudbuild-gitops nella shell locale o nell'ambiente di lavoro:

   git clone https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git
   

5. Aggiungi il repository Secure Source Manager come upstream.

   git remote add google HTTPS_REPO_URL
   

   dove HTTPS_REP_URL è l'URL HTTPS del tuo repository Secure Source Manager. Puoi trovare l'URL nella parte superiore della pagina del repository nell'interfaccia web di Secure Source Manager.

6. Crea e passa al ramo dev.

   git checkout dev
   

7. Esegui il push del repository clonato nel tuo repository con il comando seguente:

   git push -u google --all
   

8. Ripeti i due passaggi precedenti per il ramo prod.

Il codice in questo repository è strutturato nel seguente modo:

• La cartella environments/ contiene sottocartelle che rappresentano ambienti, come dev e prod, che forniscono una separazione logica tra i carichi di lavoro in diverse fasi di maturità, sviluppo e produzione, rispettivamente. Sebbene sia consigliabile che questi ambienti siano il più simili possibile, ogni sottocartella ha una propria configurazione Terraform per garantire che possano avere impostazioni uniche, se necessario.

• La cartella modules/ contiene moduli Terraform incorporati. Questi moduli rappresentano raggruppamenti logici di risorse correlate e vengono utilizzati per condividere il codice in ambienti diversi.

• Il file cloudbuild.yaml è un file di configurazione di compilazione che contiene istruzioni per Cloud Build, ad esempio come eseguire attività in base a una serie di passaggi. Questo file specifica un'esecuzione condizionale a seconda del ramo da cui Cloud Build recupera il codice, ad esempio:

  • Per i rami dev e prod, vengono eseguiti i seguenti passaggi:

    1. terraform init
    2. terraform plan
    3. terraform apply

  • Per qualsiasi altro ramo, vengono eseguiti i seguenti passaggi:

    1. terraform init per tutte le sottocartelle di environments
    2. terraform plan per tutte le sottocartelle di environments

Per assicurarti che le modifiche proposte siano appropriate per ogni ambiente, terraform init e terraform plan vengono eseguiti per tutte le sottocartelle environments. Prima di unire la richiesta di pull, puoi esaminare i piani per assicurarti che l'accesso non venga concesso a un'entità non autorizzata, ad esempio.

Modifica il file di configurazione di compilazione

Per far funzionare il file di configurazione della build di esempio con Secure Source Manager, devi apportare le seguenti modifiche:

• Aggiungi un passaggio per clonare il repository.
• Aggiungi un passaggio per ottenere il nome del ramo e assegnarlo a una variabile.

Modifica il file di configurazione di compilazione nel ramo dev:

1. Passa al branch dev:

   git checkout dev
   

2. Apri il file cloudbuild.yaml e sostituisci i contenuti con i seguenti:

   # Copyright 2019 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     https://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   
   steps:
   - id: 'clone repository'
     name: 'gcr.io/cloud-builders/git'
     args:
     - clone
     - '${_REPO_URL}'
     - .
   - id: 'branch name'
     name: gcr.io/cloud-builders/git
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         git checkout ${branch}
         echo "***********************"
         git branch --show-current
         echo "***********************"
   
   - id: 'tf init'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
      branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform init
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFORM INIT ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform init || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf apply'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform apply -auto-approve
         else
           echo "***************************** SKIPPING APPLYING *******************************"
           echo "Branch '${branch}' does not represent an official environment."
           echo "*******************************************************************************"
         fi

3. Verifica che il file sia stato modificato.

   git status
   

4. Esegui il commit e il push delle modifiche:

   git add --all
   git commit -m "Modify build config file."
   git push google dev
   

5. Apri una richiesta di pull per promuovere rapidamente le modifiche al ramo prod.

   1. Nell'interfaccia web di Secure Source Manager, vai al tuo repository.
   2. Fai clic sulla scheda Pull request.
   3. Fai clic su Nuova richiesta pull.
   4. Nel campo Unisci in:, seleziona il ramo prod.
   5. Nel campo pull from: (estrai da), seleziona il ramo dev.
   6. Rivedi le modifiche, poi fai clic su Nuova richiesta di pull.
   7. Fai clic su Crea richiesta di pull.
   8. Fai clic su Unisci richiesta di pull.

   9. Fai di nuovo clic su Unisci pull request.

      Le modifiche vengono unite al ramo prod.

Configurazione di Terraform per archiviare lo stato in un bucket Cloud Storage

Per impostazione predefinita, Terraform archivia lo stato localmente in un file denominato terraform.tfstate. Questa configurazione predefinita può rendere difficile l'utilizzo di Terraform per i team, soprattutto quando molti utenti eseguono Terraform contemporaneamente e ogni macchina ha la propria comprensione dell'infrastruttura corrente.

Per aiutarti a evitare questi problemi, questa sezione configura uno stato remoto che punta a un bucket Cloud Storage. Lo stato remoto è una funzionalità dei backend e, in questo tutorial, è configurato nei file backend.tf, ad esempio:

# Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.


terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate"
    prefix = "env/dev"
  }
}

Nei passaggi successivi, creerai un bucket Cloud Storage e modificherai alcuni file in modo che puntino al nuovo bucket e al tuo progetto. Google Cloud

1. In Cloud Shell, crea il bucket Cloud Storage:

   PROJECT_ID=$(gcloud config get-value project)
   gcloud storage buckets create gs://${PROJECT_ID}-tfstate
   

2. Abilita il controllo delle versioni degli oggetti per conservare la cronologia dei tuoi deployment:

   gcloud storage buckets update gs://${PROJECT_ID}-tfstate --versioning
   

   L'attivazione del controllo delle versioni degli oggetti aumenta i costi di archiviazione, che puoi ridurre configurando la gestione del ciclo di vita degli oggetti per eliminare le versioni precedenti.

3. Crea un nuovo ramo cloud-storage-bucket in cui apportare le modifiche:

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout -b cloud-storage-bucket
   

4. Sostituisci il segnaposto PROJECT_ID con l'ID progetto sia nel file terraform.tfvars che in quello backend.tf:

   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

   Su OS X o macOS, potresti dover aggiungere due virgolette ("") dopo sed -i, come segue:

   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

5. Controlla se tutti i file sono stati aggiornati:

   git status
   

   L'output ha il seguente aspetto:

   On branch cloud-storage-bucket
   Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git restore ..." to discard changes in working directory)
          modified:   environments/dev/backend.tf
          modified:   environments/dev/terraform.tfvars
          modified:   environments/prod/backend.tf
          modified:   environments/prod/terraform.tfvars
   no changes added to commit (use "git add" and/or "git commit -a")
   

6. Esegui il commit e il push delle modifiche:

   git add --all
   git commit -m "Update project IDs and buckets"
   git push google -u cloud-storage-bucket
   

   Il nuovo ramo cloud-storage-bucket viene inviato al repository.

7. Unisci le modifiche di cloud-storage-bucket ai rami dev e prod aprendo e inviando le richieste di unione per ogni ramo.

Concedere le autorizzazioni al account di servizio Cloud Build

Per consentire al service account Cloud Build di eseguire script Terraform con lo scopo di gestire le risorse Google Cloud , devi concedergli l'accesso appropriato al tuo progetto. Per semplicità, in questo tutorial viene concesso l'accesso editor del progetto. Per gli ambienti di produzione, segui le best practice per la sicurezza IT della tua azienda, in genere fornendo l'accesso con privilegi minimi.

Nota: il account di servizio Cloud Build predefinito utilizzato per eseguire le build sta per essere modificato. Come best practice, ti consigliamo di specificare un service account personalizzato per eseguire le build. Per ulteriori informazioni, vedi Modifica dell'account di servizio Cloud Build.

1. Per trovare l'email del account di servizio Cloud Build, vai a Impostazioni nella pagina Cloud Build.

   Vai alle impostazioni di Cloud Build

2. Copia il valore di Indirizzo email del service account.

3. Concedi l'accesso richiesto al account di servizio Cloud Build:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member serviceAccount:CLOUDBUILD_SA --role roles/editor
   

   Sostituisci quanto segue:

   • PROJECT_ID con l'ID progetto.
   • CLOUDBUILD_SA con l'email del account di servizio Cloud Build.

Connettersi a Cloud Build

Per attivare Cloud Build con un push a qualsiasi ramo, configura un webhook Secure Source Manager. Il file di configurazione della build controllerà il nome del ramo per determinare se è necessario apportare modifiche agli ambienti dev o prod.

1. Abilita e configura Cloud Build nel tuo progetto.

2. Apri la pagina Trigger nella console Google Cloud .

   Apri la pagina Trigger

3. Seleziona il tuo progetto dal menu a discesa del selettore di progetti nella parte superiore della pagina.

4. Fai clic su Apri.

5. Fai clic su Crea trigger.

6. Inserisci le seguenti impostazioni del trigger:

   • Nome: trigger-on-push

   • Regione: seleziona la regione per il trigger. Se il file di configurazione della build associato al trigger specifica un pool privato, la regione selezionata per il trigger deve corrispondere a quella del pool privato.

     Nota: se utilizzi un pool privato, devi assegnare IP esterni per consentire al pool privato di accedere a internet pubblico. Per maggiori dettagli, vedi Creazione di un nuovo pool privato.

     Se selezioni global come regione, Cloud Build utilizza la regione specificata nel file di configurazione della build per eseguire la build. Può trattarsi della regione del pool privato, se ne specifichi uno nel file di configurazione della build, o del pool predefinito globale, se non ne specifichi uno.

   • (Facoltativo) Descrizione: inserisci una descrizione per il trigger.

   • Evento: seleziona Evento webhook come evento del repository per richiamare il trigger.

     Se Secret Manager non è installato, ti viene chiesto di abilitarlo.

   • URL webhook: seleziona una delle seguenti opzioni:

     • Utilizza un nuovo secret se vuoi generare un nuovo secret utilizzando Cloud Build. Fai clic su Crea secret per creare il secret.
     • Utilizza un secret esistente o creane uno tuo se vuoi utilizzare un secret esistente. Inserisci il secret e la versione nelle caselle di selezione del menu a discesa.

     Se utilizzi un secret esistente, potresti dover concedere manualmente il ruolo Funzione di accesso di Secret Manager Reader all'agente di servizio Cloud Build [e-mail].

     Per saperne di più, vedi Concedere un ruolo all'agente di servizio Cloud Build.

7. Fai clic su Mostra anteprima URL e registra l'URL. Questo URL ti serve per configurare il webhook in Secure Source Manager.

   • Configurazione: per Tipo seleziona File di configurazione di Cloud Build (YAML o JSON) e per Posizione, seleziona Inline.

8. Fai clic sul pulsante Apri editor per modificare il file di configurazione della build.

9. Copia i contenuti del file cloudbuild.yaml nell'editor.

   Come discusso in precedenza, questa pipeline ha comportamenti diversi a seconda del ramo recuperato. La build controlla se la variabile ${branch} corrisponde a una cartella di ambiente. In questo caso, Cloud Build esegue terraform plan per quell'ambiente. In caso contrario, Cloud Build esegue terraform plan per tutti gli ambienti per assicurarsi che la modifica proposta sia appropriata per tutti. Se l'esecuzione di uno di questi piani non va a buon fine, la build non riesce.

   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi

   Il comando terraform apply viene eseguito per i rami dell'ambiente, ma viene completamente ignorato in tutti gli altri casi.

10. Fai clic su + Aggiungi variabile e aggiungi le due seguenti variabili di sostituzione:

    • Variabile: _REPO_URL, Valore:$(body.repository.clone_url)
    • Variabile: _REF, Valore:$(body.ref)

11. Fai clic su Crea.

Configurare un webhook in Secure Source Manager

Crea un webhook per attivare le build sui push ai rami dev o prod.

1. Nell'interfaccia web di Secure Source Manager, vai al repository per cui vuoi creare un webhook.
2. Fai clic su Impostazioni.
3. Fai clic su Webhook e poi su Aggiungi webhook.

4. Nel campo ID hook, inserisci un ID per il webhook.

   Nota: gli ID hook devono rispettare la convenzione di denominazione delle risorse. Devono includere solo lettere minuscole, numeri o trattini, devono iniziare con una lettera e non possono essere modificati dopo la creazione del webhook.

5. Nel campo URL di destinazione, inserisci l'URL webhook che hai copiato quando hai configurato un trigger webhook in Cloud Build.

   Per trovare l'URL webhook:

   1. Apri la pagina Trigger nella console Google Cloud .

      Apri la pagina Trigger

   2. Fai clic sul trigger.

   3. Nella sezione URL webhook, fai clic su Mostra anteprima URL e copia l'URL.

6. L'URL webhook contiene i valori della chiave e del segreto inseriti durante la creazione del trigger Cloud Build. Per evitare la divulgazione di questi valori, rimuovili dalla fine dell'URL di destinazione e copiali nel campo Stringa di query sensibile.

   Per trovare la chiave e il secret nell'URL webhook, cerca il testo che inizia con key=

   Ad esempio, dato il seguente URL: https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager

   Copia e rimuovi la parte che inizia con il punto interrogativo ?key=... dal campo URL di destinazione. Poi rimuovi il punto interrogativo iniziale e sposta la parte rimanente key=... nel campo Stringa di query sensibile.

7. Fai clic su Aggiungi webhook.

8. Il webhook viene visualizzato nella pagina Webhook.

   Nota :quando aggiungi o modifichi un webhook, la lunghezza di Sensitive Query String potrebbe non corrispondere a quella inserita, il che è normale in quanto vengono utilizzate stringhe segnaposto per garantire la sicurezza.

Modifica la configurazione dell'ambiente in un ramo della nuova funzionalità

1. Assicurati di essere nel ramo dev:

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout dev
   

2. Esegui il pull delle ultime modifiche:

   git pull
   

3. Crea un branch bug-fix per modificare la configurazione dell'ambiente.

   git checkout -b bug-fix
   

4. Apri modules/firewall/main.tf per modificarlo.

5. Alla riga 30, correggi l'errore di battitura "http-server2" nel campo target_tags.

   Il valore deve essere "http-server".

6. Esegui il commit e il push delle modifiche:

   git add --all
   git commit -m "Fix typo."
   git push google -u bug-fix
   

7. Apri la pagina Cronologia di Cloud Build nella console Google Cloud :

   Apri la pagina Cronologia

8. Fai clic su Build per visualizzare ulteriori informazioni, incluso l'output di terraform plan.

Tieni presente che il job Cloud Build ha eseguito la pipeline definita nel file cloudbuild.yaml. Come discusso in precedenza, questa pipeline ha comportamenti diversi a seconda del ramo recuperato. La build controlla se la variabile ${branch} corrisponde a una cartella di ambiente. In questo caso, Cloud Build esegue terraform plan per quell'ambiente. In caso contrario, Cloud Build esegue terraform plan per tutti gli ambienti per assicurarsi che la modifica proposta sia appropriata per tutti. Se l'esecuzione di uno di questi piani non va a buon fine, la build non riesce.

- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

Analogamente, il comando terraform apply viene eseguito per i rami dell'ambiente, ma viene completamente ignorato in tutti gli altri casi. In questa sezione hai inviato una modifica del codice a un nuovo ramo, quindi non sono stati applicati deployment dell'infrastruttura al tuo Google Cloud progetto.

- id: 'tf apply' name: 'hashicorp/terraform:1.0.0' entrypoint: 'sh' args: - '-c' - | branch=$(basename "$_REF") if [ -d "environments/${branch}/" ]; then cd environments/${branch} terraform apply -auto-approve else echo "***************************** SKIPPING APPLYING *******************************" echo "Branch '${branch}' does not represent an official environment." echo "*******************************************************************************" fi

Promozione delle modifiche all'ambiente di sviluppo

È il momento di applicare lo stato che preferisci al tuo ambiente dev.

1. Nell'interfaccia web di Secure Source Manager, vai al tuo repository.
2. Fai clic su Nuova richiesta di pull.
3. Nel campo Unisci in:, seleziona il ramo dev.
4. Nel campo Estrai da:, seleziona il ramo bug-fix.
5. Fai clic su Nuova richiesta pull.
6. Fai clic su Crea richiesta di pull.
7. Fai clic su Unisci richiesta di pull e poi di nuovo su Unisci richiesta di pull.

8. Verifica che sia stata attivata una nuova build di Cloud Build:

   Vai alla pagina Cloud Build

9. Apri la build e controlla i log.

   Al termine della build, visualizzerai un risultato simile al seguente:

   Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
   Step #3 - "tf apply": firewall_rule = dev-allow-http
   Step #3 - "tf apply": instance_name = dev-apache2-instance
   Step #3 - "tf apply": network = dev
   Step #3 - "tf apply": subnet = dev-subnet-01
   

10. Copia EXTERNAL_IP_VALUE e apri l'indirizzo in un browser web.

    http://EXTERNAL_IP_VALUE
    

    Il provisioning potrebbe richiedere alcuni secondi per l'avvio della VM e la propagazione della regola firewall. Alla fine, nel browser web viene visualizzato Environment: dev.

11. Accedi a Cloud Storage:

    Vai alla pagina Cloud Storage

12. Seleziona il progetto.

13. Fai clic sul bucket di archiviazione dello stato di Terraform. Il nome del bucket è simile al seguente:

    PROJECT_ID-tfstate
    

14. Fai clic su env e poi su dev per visualizzare il file di stato di Terraform.

Promozione delle modifiche all'ambiente di produzione

Ora che hai testato completamente l'ambiente di sviluppo, puoi promuovere il codice dell'infrastruttura in produzione.

1. Nell'interfaccia web di Secure Source Manager, vai al tuo repository.
2. Fai clic sulla scheda Pull request.
3. Fai clic su Nuova richiesta pull.
4. Per Merge into (Unisci in), seleziona il ramo prod del repository.
5. Per Pull from (Estrai da), seleziona il ramo dev del repository.
6. Fai clic su Nuova richiesta pull.
7. Per il titolo, inserisci un titolo come "Promozione delle modifiche di rete" e poi fai clic su Crea richiesta di pull.

8. Esamina le modifiche proposte, poi fai clic su Unisci richiesta di pull.

   La data e l'URL del repository vengono aggiunti nel campo del commento.

9. Fai di nuovo clic su Unisci richiesta di pull per confermare.

10. Nella console Google Cloud , apri la pagina Cronologia build per vedere le modifiche applicate all'ambiente di produzione:

    Vai alla pagina Cloud Build

11. Attendi il completamento della build, quindi controlla i log.

    Alla fine dei log, vedrai un messaggio simile a questo:

    Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
    Step #3 - "tf apply": firewall_rule = prod-allow-http
    Step #3 - "tf apply": instance_name = prod-apache2-instance
    Step #3 - "tf apply": network = prod
    Step #3 - "tf apply": subnet = prod-subnet-01
    

12. Copia EXTERNAL_IP_VALUE e apri l'indirizzo in un browser web.

    http://EXTERNAL_IP_VALUE
    

    Il provisioning potrebbe richiedere alcuni secondi per l'avvio della VM e la propagazione della regola firewall. Alla fine, nel browser web viene visualizzato Environment: prod.

13. Accedi a Cloud Storage:

    Vai alla pagina Cloud Storage

14. Seleziona il progetto.

15. Fai clic sul bucket di archiviazione dello stato di Terraform. Il nome del bucket è simile al seguente:

    PROJECT_ID-tfstate
    

16. Fai clic su env e poi su prod per visualizzare il file di stato di Terraform.

Hai configurato correttamente una pipeline di infrastruttura come codice serverless in Cloud Build. In futuro, potresti provare a:

• Aggiungi implementazioni per casi d'uso separati.
• Crea altri ambienti per soddisfare le tue esigenze.
• Utilizza un progetto per ambiente anziché un VPC per ambiente.

Esegui la pulizia

Al termine del tutorial, esegui la pulizia delle risorse create suGoogle Cloud in modo che non vengano addebitate in futuro.

Elimina il progetto

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini, elimini anche tutto il lavoro che hai svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Passaggi successivi

• Valuta la possibilità di utilizzare i modelli di Cloud Foundation Toolkit per creare rapidamente una base ripetibile a livello aziendale in Google Cloud.
• Guarda Repeatable Google Cloud Environments at Scale With Cloud Build Infra-As-Code Pipelines di Next' 19 sul flusso di lavoro GitOps descritto in questo tutorial.
• Consulta l'esercitazione Distribuzione continua in stile GitOps con Cloud Build.
• Dai un'occhiata alle funzionalità più avanzate di Cloud Build: Configurazione dell'ordine dei passaggi di build, Creazione, test e deployment di artefatti e Creazione di passaggi di build personalizzati.
• Dai un'occhiata al post del blog su Ensuring scale and compliance of your Terraform Deployment with Cloud Build.
• Leggi le nostre risorse su DevOps.
• Scopri di più sulle funzionalità DevOps correlate a questo tutorial:
  • Controllo della versione
  • Integrazione continua
  • Continuous Delivery
  • Test continui
• Esegui il controllo rapido DevOps per capire la tua posizione rispetto al resto del settore.