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à:

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 rispettivamente dalle reti Virtual Private Cloud (VPC) dev e prod 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 della funzionalità.
  • Promuovi le modifiche nell'ambiente di sviluppo.
  • Promuovi le modifiche nell'ambiente di produzione.

Costi

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

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 saperne di più, consulta Esegui la pulizia.

Prima di iniziare

  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 senza costi per l'esecuzione, il test e il deployment dei workload.

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

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

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

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

  6. Nella console Google Cloud , attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  7. 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
  8. 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.
  9. 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 all'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 il seguente 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 una buona pratica rendere questi ambienti 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 garantire 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 di 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 richiesta di pull.

      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.

Concedi 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 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.

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

    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 alla regione del 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 del 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 a discesa.

      Se utilizzi un secret esistente, potresti dover concedere manualmente il ruolo Funzione di accesso ai secret di Secret Manager al service agent Cloud Build service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com.

      Per saperne di più, consulta 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 compilazione.

  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 dell'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.

  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 sull'attivatore.

    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 secret inseriti durante la creazione del trigger di build di 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.

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 dell'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 di 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 messaggio simile a questo:

    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 vedrai Environment: dev.

  11. Vai 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 di pull.
  4. Per merge into: (unisci in), seleziona il branch prod del repository.
  5. In pull from: (estrai da), seleziona il ramo dev del repository.
  6. Fai clic su Nuova richiesta di pull.
  7. Per title, inserisci un titolo come "Promozione delle modifiche al networking" 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. Vai 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

  1. Nella console Google Cloud , vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona quello che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi