Gestire le regole di qualità dei dati come codice con Terraform

Questo tutorial spiega come gestire le regole di qualità dei dati di Dataplex Universal Catalog come codice con Terraform, Cloud Build e GitHub.

Sono disponibili molte opzioni diverse per le regole di qualità dei dati per definire e misurare la qualità dei dati. Quando automatizzi il processo di deployment delle regole di qualità dei dati nell'ambito della tua strategia di gestione dell'infrastruttura più ampia, ti assicuri che i tuoi dati siano sottoposti in modo coerente e prevedibile alle regole che gli assegni.

Se hai versioni diverse di un set di dati per più ambienti, ad esempio gli ambienti dev e prod, Terraform fornisce un modo affidabile per assegnare regole di qualità dei dati a versioni specifiche dell'ambiente dei set di dati.

Anche il controllo delle versioni è una best practice importante per DevOps. La gestione delle regole di qualità dei dati come codice ti fornisce le versioni delle regole di qualità dei dati disponibili nella cronologia di GitHub. Terraform può anche salvare il suo stato in Cloud Storage, che può archiviare le versioni precedenti del file di stato.

Per saperne di più su Terraform e Cloud Build, consulta Panoramica di Terraform su Google Cloud e Cloud Build.

Architettura

Per capire come questo tutorial utilizza Cloud Build per gestire le esecuzioni di Terraform, esamina il seguente diagramma dell'architettura. Tieni presente che utilizza i rami GitHub dev e prod per rappresentare gli ambienti effettivi.

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 su un altro ramo, ad esempio su 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 ai rami non protetti e poi inviarle tramite richieste pull. L'app GitHub di Cloud Build, descritta più avanti in questo tutorial, attiva automaticamente i job di build e collega i report terraform plan a queste richieste di 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 il repository GitHub.
• 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 tuo repository GitHub.
• Stabilisci le regole di qualità dei dati del Catalogo universale Dataplex.
• Modifica la configurazione dell'ambiente in un ramo della funzionalità e testa.
• Promuovi le modifiche nell'ambiente di sviluppo.
• Promuovi le modifiche all'ambiente di produzione.

Costi

In questo documento, utilizzi i seguenti componenti fatturabili di Google Cloud:

• BigQuery
• Cloud Build
• Cloud Storage
• Compute Engine
• Dataplex Universal Catalog

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

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.

Go to project selector

Make sure 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.

Go to project selector

Make sure 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 in modo che utilizzi il tuo progetto. Sostituisci PROJECT_ID con l'ID progetto.

   gcloud config set project PROJECT_ID

3. Abilita le API richieste:

   gcloud services enable bigquery.googleapis.com cloudbuild.googleapis.com compute.googleapis.com dataplex.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.

Configurare il repository GitHub

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

• Il ramo dev contiene le ultime modifiche applicate all'ambiente di sviluppo.
• Il ramo prod contiene le ultime modifiche applicate all'ambiente di produzione.

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.

Per iniziare, crea un fork del repository terraform-google-dataplex-auto-data-quality.

1. Su GitHub, vai a https://github.com/GoogleCloudPlatform/terraform-google-dataplex-auto-data-quality.git.

2. Fai clic su Fork.

   Ora hai una copia del repository terraform-google-dataplex-auto-data-quality con i file di origine.

3. In Cloud Shell, clona il seguente repository forked:

   cd ~
   git clone https://github.com/GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality.git
   cd ~/terraform-google-dataplex-auto-data-quality
   

   Sostituisci quanto segue:

   • GITHUB_USERNAME: il tuo nome utente GitHub

4. Crea i rami dev e prod:

   git checkout -b prod
   git checkout -b dev
   

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.

• 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 modulo modules/deploy/ qui rappresenta un modello per un deployment e viene riutilizzato per diversi ambienti di deployment.

• Entro modules/deploy/:

  • La cartella rule/ contiene yaml file contenenti regole di qualità dei dati. Un file rappresenta un insieme di regole di qualità dei dati per una tabella. Questo file viene utilizzato negli ambienti dev e prod.

  • La cartella schemas/ contiene lo schema della tabella per la tabella BigQuery di cui è stato eseguito il deployment in questa infrastruttura.

  • Il file bigquery.tf contiene la configurazione per le tabelle BigQuery create in questo deployment.

  • Il file dataplex.tf contiene una scansione dei dati di Dataplex Universal Catalog per la qualità dei dati. Questo file viene utilizzato in combinazione con rules_file_parsing.tf per leggere le regole di qualità dei dati da un file yaml nell'ambiente.

• 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 tutti gli ambienti. Prima di unire la richiesta pull, puoi esaminare i piani per assicurarti che l'accesso non venga concesso a un'entità non autorizzata, ad esempio.

Configurazione di Terraform per archiviare lo stato nei 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 nel file backend.tf.

# Copyright 2024 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-dev"
  }
}

Esiste un file backend.tf separato in ciascuno degli ambienti dev e prod. È considerata una best practice utilizzare un bucket Cloud Storage diverso per ogni ambiente.

Nei passaggi successivi, creerai due bucket Cloud Storage per dev e prod e modificherai alcuni file in modo che puntino ai nuovi bucket e al tuo progetto Google Cloud .

1. In Cloud Shell, crea i due bucket Cloud Storage:

   DEV_BUCKET=gs://PROJECT_ID-tfstate-dev
   gcloud storage buckets create ${DEV_BUCKET}
   
   PROD_BUCKET=gs://PROJECT_ID-tfstate-prod
   gcloud storage buckets create ${PROD_BUCKET}
   

2. Per conservare la cronologia dei deployment, attiva il controllo delle versioni degli oggetti:

   gcloud storage buckets update ${DEV_BUCKET} --versioning
   gcloud storage buckets update ${PROD_BUCKET} --versioning
   

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

3. In ogni ambiente, nei file main.tf e backend.tf , sostituisci PROJECT_ID con l'ID progetto:

   cd ~/terraform-google-dataplex-auto-data-quality
   sed -i s/PROJECT_ID/PROJECT_ID/g environments/*/main.tf
   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:

   cd ~/solutions-terraform-cloudbuild-gitops
   sed -i "" s/PROJECT_ID/PROJECT_ID/g environments/*/main.tf
   sed -i "" s/PROJECT_ID/PROJECT_ID/g environments/*/backend.tf
   

4. Controlla se tutti i file sono stati aggiornati:

   git status
   

   Di seguito è riportato un output di esempio:

   On branch dev
   Your branch is up-to-date with 'origin/dev'.
   Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)
          modified:   environments/dev/backend.tf
          modified:   environments/dev/main.tf
          modified:   environments/prod/backend.tf
          modified:   environments/prod/main.tf
   no changes added to commit (use "git add" and/or "git commit -a")
   

5. Esegui il commit e il push delle modifiche:

   git add --all
   git commit -m "Update project IDs and buckets"
   git push origin dev
   

   A seconda della configurazione di GitHub, devi autenticarti per eseguire il push delle modifiche precedenti.

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 del progetto. Tuttavia, quando il ruolo Editor progetto dispone di un'autorizzazione di ampio raggio, negli ambienti di produzione devi seguire le best practice di sicurezza IT della tua azienda, che in genere prevedono l'accesso con privilegi minimi.

1. In Cloud Shell, recupera l'email del account di servizio Cloud Build del tuo progetto:

   CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID \
       --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com"
   

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

Connettere direttamente Cloud Build al repository GitHub

Questa sezione descrive come installare l'app GitHub Cloud Build. Questa installazione ti consente di collegare il repository GitHub al tuo progettoGoogle Cloud in modo che Cloud Build possa applicare automaticamente i manifest Terraform ogni volta che crei un nuovo ramo o esegui il push del codice su GitHub.

I passaggi riportati di seguito forniscono istruzioni per installare l'app solo per il repository terraform-google-dataplex-auto-data-quality, ma puoi scegliere di installarla per più repository o per tutti.

1. In GitHub Marketplace, vai alla pagina dell'app Cloud Build.

   • Se è la prima volta che configuri un'app in GitHub, fai clic su Configura con Google Cloud Build in fondo alla pagina. Poi fai clic su Concedi a questa app l'accesso al tuo account GitHub.
   • Se non è la prima volta che configuri un'app in GitHub, fai clic su Configura l'accesso. Si apre la pagina Applicazioni del tuo account personale.

2. Fai clic su Configura nella riga Cloud Build.

3. Seleziona Solo repository selezionati, quindi seleziona terraform-google-dataplex-auto-data-quality per connetterti al repository.

4. Fai clic su Salva o Installa. L'etichetta del pulsante cambia a seconda del tuo flusso di lavoro. Vieni reindirizzato a Google Cloud per continuare l'installazione.

5. Accedi con il tuo account Google Cloud . Se richiesto, autorizza l'integrazione di Cloud Build con GitHub.

6. Nella pagina Cloud Build, seleziona il tuo progetto. Viene visualizzata una procedura guidata.

7. Nella sezione Seleziona repository, seleziona il tuo account GitHub e il repository terraform-google-dataplex-auto-data-quality.

8. Se accetti i termini e le condizioni, seleziona la casella di controllo, quindi fai clic su Connetti.

9. Nella sezione Crea un trigger, fai clic su Crea un trigger:

   1. Aggiungi un nome trigger, ad esempio push-to-branch. Prendi nota del nome di questo trigger perché ti servirà in seguito.
   2. Nella sezione Evento, seleziona Push al ramo.
   3. Nella sezione Origine, seleziona .* nel campo Branch.
   4. Fai clic su Crea.

L'app Cloud Build GitHub è configurata e il tuo repository GitHub è collegato al tuo progetto Google Cloud . Le modifiche al repository GitHub attivano le esecuzioni di Cloud Build, che riportano i risultati a GitHub utilizzando GitHub Checks.

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

La maggior parte dell'ambiente è configurata. Apporta le modifiche necessarie al codice nel tuo ambiente locale:

1. Su GitHub, vai alla pagina principale del repository creato mediante fork.

   https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
   

2. Assicurati di trovarti nel ramo dev.

3. Per aprire il file per la modifica, vai al file modules/deploy/dataplex.tf.

4. Alla riga 19, modifica l'etichetta the_environment in environment.

5. Aggiungi un messaggio di commit in fondo alla pagina, ad esempio "modifica etichetta", e seleziona Crea un nuovo ramo per questo commit e avvia una richiesta di pull.

6. Fai clic su Proponi modifiche.

7. Nella pagina successiva, fai clic su Crea richiesta di pull per aprire una nuova richiesta di pull con la modifica al ramo dev.

   Dopo l'apertura della richiesta pull, viene avviato automaticamente un job Cloud Build.

8. Fai clic su Mostra tutti i controlli e attendi che il controllo diventi verde. Non unire ancora la pull request. L'unione viene eseguita in un passaggio successivo del tutorial.

9. Fai clic su Dettagli per visualizzare ulteriori informazioni, incluso l'output di terraform plan nel link Visualizza ulteriori dettagli su Google Cloud Build.

Tieni presente che il job Cloud Build ha eseguito la pipeline definita nel file cloudbuild.yaml. Questa pipeline ha comportamenti diversi a seconda del ramo recuperato. La build controlla se la variabile $BRANCH_NAME 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.9.8'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFORM 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.9.8'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform apply -auto-approve
      else
        echo "***************************** SKIPPING APPLYING *******************************"
        echo "Branch '$BRANCH_NAME' does not represent an official environment."
        echo "*******************************************************************************"
      fi

Imponi l'esecuzione riuscita di Cloud Build prima di unire i rami

Per assicurarti che i merge possano essere applicati solo quando le rispettive esecuzioni di Cloud Build hanno esito positivo, segui questi passaggi:

1. Su GitHub, vai alla pagina principale del repository creato mediante fork.

   https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
   

2. Sotto il nome del repository, fai clic su Impostazioni.

3. Nel menu a sinistra, fai clic su Rami.

4. In Regole di protezione dei rami, fai clic su Aggiungi regola.

5. In Pattern nome ramo, digita dev.

6. Nella sezione Proteggi rami corrispondenti, seleziona Richiedi superamento dei controlli di stato prima dell'unione.

7. Cerca il nome del trigger di Cloud Build creato in precedenza.

8. Fai clic su Crea.

9. Ripeti i passaggi da 3 a 7, impostando Pattern nome ramo su prod.

Questa configurazione è importante per proteggere sia i rami dev che prod. Ciò significa che i commit devono prima essere inviati a un altro ramo e solo dopo possono essere uniti al ramo protetto. In questo tutorial, la protezione richiede che l'esecuzione di Cloud Build vada a buon fine per consentire l'unione.

Promuovere le modifiche all'ambiente di sviluppo

Hai una richiesta di pull in attesa di essere unita. È il momento di applicare lo stato che vuoi al tuo ambiente dev.

1. Su GitHub, vai alla pagina principale del repository creato mediante fork.

   https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
   

2. Sotto il nome del repository, fai clic su Pull request.

3. Fai clic sulla richiesta di pull appena creata.

4. Fai clic su Unisci richiesta di pull e poi su Conferma unione.

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

   Vai alla pagina Cloud Build

6. Apri la build e controlla i log. Verranno visualizzate tutte le risorse che Terraform sta creando e gestendo.

Promuovere le modifiche all'ambiente di produzione

Ora che hai testato completamente l'ambiente di sviluppo, puoi promuovere il codice per le regole di qualità dei dati in produzione.

1. Su GitHub, vai alla pagina principale del repository creato mediante fork.

   https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
   

2. Sotto il nome del repository, fai clic su Pull request.

3. Fai clic su Nuova richiesta pull.

4. Per il repository di base, seleziona il repository appena creato.

5. Per base, seleziona prod dal tuo repository di base. Per confrontare, seleziona dev.

6. Fai clic su Crea richiesta di pull.

7. Per il titolo, inserisci un titolo come Changing label name e poi fai clic su Crea richiesta di pull.

8. Esamina le modifiche proposte, inclusi i dettagli terraform plan di Cloud Build, poi fai clic su Unisci richiesta di pull.

9. Fai clic su Conferma unione.

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

    Vai alla pagina Cloud Build

Hai configurato correttamente le regole di qualità dei dati gestite utilizzando Terraform e Cloud Build.

Esegui la pulizia

Al termine del tutorial, esegui la pulizia delle risorse che hai creato su Google Cloud in modo che non ti vengano addebitate in futuro.

Elimina il progetto

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.

Elimina il repository GitHub

Per evitare di bloccare nuove richieste di pull nel repository GitHub, puoi eliminare le regole di protezione dei rami:

1. In GitHub, vai alla pagina principale del repository di cui hai creato un fork.
2. Sotto il nome del repository, fai clic su Impostazioni.
3. Nel menu a sinistra, fai clic su Rami.
4. Nella sezione Regole di protezione dei rami, fai clic sul pulsante Elimina per le righe dev e prod.

Se vuoi, puoi disinstallare completamente l'app Cloud Build da GitHub:

1. In GitHub, vai alla pagina delle applicazioni GitHub.

2. Nella scheda App GitHub installate, fai clic su Configura nella riga Cloud Build. Quindi, nella sezione Zona di pericolo, fai clic sul pulsante Disinstalla nella riga Disinstalla Google Cloud Builder.

   Nella parte superiore della pagina viene visualizzato il messaggio "Tutto è pronto. Un job è stato messo in coda per disinstallare Google Cloud Build."

3. Nella scheda App GitHub autorizzate, fai clic sul pulsante Revoca nella riga Google Cloud Build, quindi su Ho capito, revoca l'accesso.

Se non vuoi conservare il repository GitHub, eliminalo:

1. In GitHub, vai alla pagina principale del repository di cui hai creato un fork.
2. Sotto il nome del repository, fai clic su Impostazioni.
3. Vai a Zona pericolosa.
4. Fai clic su Elimina questo repository e segui i passaggi per la conferma.

Passaggi successivi

• Scopri di più sulla qualità dei dati automatica.
• Scopri di più su DevOps e sulle best practice DevOps.
• Esplora il Cloud Foundation Toolkit per altri modelli Terraform.