Questo tutorial spiega come gestire le regole sulla qualità dei dati Dataplex come codice con Terraform, Cloud Build e GitHub.
Sono disponibili molte opzioni diverse per le regole sulla qualità dei dati per definire e misurare la qualità dei dati. Quando automatizzi il processo di deployment delle regole sulla qualità dei dati nell'ambito della tua più ampia strategia di gestione dell'infrastruttura, ti assicuri che i tuoi dati siano soggetti alle regole che assegni in modo coerente e prevedibile.
Se hai versioni diverse di un set di dati per più ambienti, ad esempio ambienti dev
e prod
, Terraform offre un modo affidabile per assegnare regole di qualità dei dati a versioni dei set di dati specifici dell'ambiente.
Anche il controllo delle versioni è un'importante best practice per DevOps. La gestione delle regole sulla qualità dei dati come codice ti fornisce le versioni delle regole sulla qualità dei dati disponibili nella tua cronologia di GitHub. Terraform può anche salvare il proprio stato in Cloud Storage, che può archiviare versioni precedenti del file di stato.
Per ulteriori informazioni su Terraform e Cloud Build, consulta Panoramica di Terraform su Google Cloud e Cloud Build.
Architettura
Per capire in che modo questo tutorial utilizza Cloud Build per gestire
le esecuzioni di Terraform, considera il seguente diagramma di architettura. Tieni presente che
utilizza i rami GitHub, dev
e prod
, per rappresentare gli ambienti reali.
Il processo viene avviato quando esegui il push del codice Terraform nel ramo dev
o prod
. In questo scenario, Cloud Build attiva e quindi applica i manifest Terraform per ottenere lo stato desiderato nel rispettivo ambiente.
Quando esegui il push del codice Terraform in qualsiasi altro ramo, ad esempio
a un ramo di funzionalità, Cloud Build viene eseguito per eseguire terraform plan
, ma
nessuna viene applicata ad alcun ambiente.
Idealmente, gli sviluppatori o gli operatori devono fare proposte di infrastruttura per
filiali non protette
e poi inviarle tramite
richieste pull.
L'app Cloud Build GitHub, discussa 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 nel ramo di base.
Se non vengono sollevati dubbi, devi prima unire le modifiche alla filiale dev
. Questa unione attiva un deployment dell'infrastruttura nell'ambiente dev
, consentendoti di testare questo ambiente. Dopo aver eseguito i test e aver acquisito sicurezza di ciò di cui è stato eseguito il deployment, devi unire il ramo dev
al ramo prod
per attivare l'installazione dell'infrastruttura nell'ambiente di produzione.
Obiettivi
- Configura il tuo repository GitHub.
- Configurare Terraform per archiviare lo stato in un bucket Cloud Storage.
- Concedi le autorizzazioni al tuo account di servizio Cloud Build.
- Connetti Cloud Build al tuo repository GitHub.
- Stabilire regole sulla qualità dei dati Dataplex.
- Modifica la configurazione del tuo ambiente in un ramo di funzionalità ed esegui un test.
- Promuovere le modifiche all'ambiente di sviluppo.
- Promuovere le modifiche all'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.
Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.
Prerequisiti
- 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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Nella console Google Cloud, attiva Cloud Shell.
Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.
- 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. SostituisciPROJECT_ID
con il tuo ID progetto.gcloud config set project PROJECT_ID
- 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. - Se non hai mai utilizzato Git in Cloud Shell, configuralo con il tuo
nome e il tuo 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.
Configurazione del repository GitHub
In questo tutorial, utilizzerai un singolo repository Git per definire la tua infrastruttura cloud. Puoi orchestrare l'infrastruttura con rami diversi corrispondenti ad 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.
Con questa infrastruttura, puoi sempre fare riferimento al repository per sapere quale configurazione è prevista in ciascun ambiente e per proporre nuove modifiche unendole prima nell'ambiente dev
. Successivamente, promuovi le modifiche
unendo il ramo dev
a quello prod
successivo.
Per iniziare, crea un fork del repository terraform-google-dataplex-auto-data-quality.
Su GitHub, vai a https://github.com/GoogleCloudPlatform/terraform-google-dataplex-auto-data-quality.git.
Fai clic su Fork.
Ora hai una copia del repository
terraform-google-dataplex-auto-data-quality
con i file di origine.In Cloud Shell, clona questo repository creato con fork, sostituendo
YOUR_GITHUB_USERNAME
con il tuo nome utente GitHub:cd ~ git clone https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality.git cd ~/terraform-google-dataplex-auto-data-quality
Crea rami
dev
eprod
:git checkout -b prod git checkout -b dev
Il codice in questo repository è strutturato come segue:
La cartella
environments/
contiene sottocartelle che rappresentano ambienti, comedev
eprod
, che forniscono una separazione logica tra i carichi di lavoro rispettivamente in diverse fasi di maturità, sviluppo e produzione.La cartella
modules/
contiene moduli Terraform incorporati. Questi moduli rappresentano raggruppamenti logici di risorse correlate e vengono utilizzati per condividere il codice in diversi ambienti. Il modulomodules/deploy/
qui rappresenta un modello per un deployment e viene riutilizzato per diversi ambienti di deployment.Entro
modules/deploy/
:La cartella
rule/
contieneyaml
file con regole sulla qualità dei dati. Un file rappresenta un insieme di regole sulla qualità dei dati per una tabella. Questo file viene utilizzato in ambientidev
eprod
.La cartella
schemas/
contiene lo schema della 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 un'analisi dei dati Dataplex per la qualità dei dati. Questo file viene utilizzato insieme arules_file_parsing.tf
per leggere le regole sulla qualità dei dati da un fileyaml
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 un insieme 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
eprod
, vengono eseguiti i seguenti passaggi:terraform init
terraform plan
terraform apply
Per qualsiasi altro ramo, vengono eseguiti i seguenti passaggi:
terraform init
per tutte leenvironments
sottocartelleterraform plan
per tutte leenvironments
sottocartelle
Per garantire che le modifiche proposte siano appropriate per tutti gli ambienti, terraform init
e terraform plan
vengono eseguiti per tutti gli ambienti. 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.
Configurazione di Terraform per l'archiviazione dello stato nei bucket Cloud Storage
Per impostazione predefinita, Terraform archivia lo state localmente in un file denominato terraform.tfstate
. Questa configurazione predefinita può rendere difficile l'utilizzo di Terraform per i team, soprattutto se molti utenti eseguono Terraform contemporaneamente e ogni macchina ha una propria conoscenza dell'infrastruttura attuale.
Per aiutarti a evitare questi problemi, questa sezione configura uno
stato remoto
che punti a un bucket Cloud Storage. Lo stato remoto è una funzionalità dei backend e, in questo tutorial, è configurato nel file backend.tf
.
Esiste un file backend.tf
separato in ciascuno degli ambienti dev
e prod
. È considerata una best practice usare 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.
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}
Abilita il controllo delle versioni degli oggetti per conservare la cronologia dei deployment:
gcloud storage buckets update ${DEV_BUCKET} --versioning gcloud storage buckets update ${PROD_BUCKET} --versioning
L'abilitazione del controllo delle versioni degli oggetti aumenta i costi di archiviazione, che puoi mitigare configurando la Gestione del ciclo di vita degli oggetti per eliminare le versioni precedenti dello stato.
Sostituisci il segnaposto
PROJECT_ID
con l'ID progetto nei filemain.tf
ebackend.tf
di ogni ambiente: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, potrebbe essere necessario aggiungere due virgolette (
""
) doposed -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
Controlla se tutti i file sono stati aggiornati:
git status
L'output avrà il seguente aspetto:
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")
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, dovrai eseguire l'autenticazione per eseguire il push delle modifiche precedenti.
Concessione delle autorizzazioni all'account di servizio Cloud Build
Per consentire all'account di servizio Cloud Build di eseguire script Terraform con l'obiettivo di gestire le risorse Google Cloud, devi concedere l'accesso appropriato al tuo progetto. Per semplicità, in questo tutorial viene concesso l'accesso come editor di progetto. Tuttavia, quando il ruolo di Editor del progetto ha un'autorizzazione ad ampio raggio, negli ambienti di produzione è necessario seguire le best practice per la sicurezza IT della tua azienda, fornendo in genere l'accesso con privilegi minimi.
In Cloud Shell, recupera l'email per l'account di servizio Cloud Build del tuo progetto:
CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID \ --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com"
Concedi l'accesso richiesto al tuo account di servizio Cloud Build:
gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:$CLOUDBUILD_SA --role roles/editor
Connessione diretta di Cloud Build al repository GitHub
Questa sezione mostra come installare l'app Cloud Build GitHub. Questa installazione ti consente di connettere il tuo repository GitHub al tuo progetto Google Cloud in modo che Cloud Build possa applicare automaticamente i manifest Terraform ogni volta che crei un nuovo ramo o esegui il push di codice su GitHub.
I passaggi seguenti forniscono istruzioni per installare l'app solo per il repository
terraform-google-dataplex-auto-data-quality
, ma puoi scegliere di
installare l'app per più o per tutti i tuoi repository.
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 nella parte inferiore della pagina. Quindi, 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.
Fai clic su Configura nella riga Cloud Build.
Seleziona Seleziona solo i repository, quindi seleziona
terraform-google-dataplex-auto-data-quality
per connetterti al repository.Fai clic su Salva o Installa: l'etichetta del pulsante cambia in base al flusso di lavoro. Si aprirà Google Cloud per continuare l'installazione.
Accedi con il tuo account Google Cloud. Se richiesto, autorizza l'integrazione di Cloud Build con GitHub.
Nella pagina Cloud Build, seleziona il tuo progetto. Appare una procedura guidata.
Nella sezione Seleziona repository, seleziona il tuo account GitHub e il repository
terraform-google-dataplex-auto-data-quality
.Se accetti i termini e condizioni, seleziona la casella di controllo, quindi fai clic su Connetti.
Nella sezione Crea un attivatore, fai clic su Crea un attivatore:
- Aggiungi un nome per l'attivatore, ad esempio
push-to-branch
. Prendi nota di questo nome trigger perché ti servirà in seguito. - Nella sezione Evento, seleziona Esegui il push a un ramo.
- Nella sezione Origine, seleziona
.*
nel campo Ramo. - Fai clic su Crea.
- Aggiungi un nome per l'attivatore, ad esempio
L'app GitHub di Cloud Build è ora configurata e il tuo repository GitHub è collegato al tuo progetto Google Cloud. D'ora in poi, le modifiche al repository GitHub attivano le esecuzioni di Cloud Build, che segnalano i risultati a GitHub tramite i controlli GitHub.
Modifica della configurazione dell'ambiente in un nuovo ramo di funzionalità
A questo punto, la maggior parte dell'ambiente è configurata. È quindi il momento di apportare alcune modifiche al codice nel tuo ambiente locale.
Su GitHub, vai alla pagina principale del repository creato con fork.
https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
Assicurati di trovarti nella filiale
dev
.Per aprire il file per modificarlo, vai al file
modules/deploy/dataplex.tf
.Alla riga 19, modifica l'etichetta
the_environment
inenvironment
.Aggiungi un messaggio di commit nella parte inferiore della pagina, ad esempio "modifica dell'etichetta", e seleziona Crea un nuovo ramo per questo commit e avvia una richiesta di pull.
Fai clic su Proponi modifiche.
Nella pagina seguente, fai clic su Crea richiesta di pull per aprire una nuova richiesta di pull con la modifica al ramo
dev
.Una volta aperta la richiesta di pull, viene avviato automaticamente un job di Cloud Build.
Fai clic su Mostra tutti i controlli e attendi che il segno di spunta diventi verde. Non unire ancora la richiesta di pull. L'unione viene eseguita in un passaggio successivo del tutorial.
Fai clic su Dettagli per visualizzare ulteriori informazioni, incluso l'output del
terraform plan
al link Visualizza altri dettagli su Google Cloud Build.
Tieni presente che il job Cloud Build ha eseguito la pipeline definita nel file cloudbuild.yaml
. Come già detto, questa pipeline ha comportamenti
diversi a seconda del ramo recuperato. La build controlla se la variabile $BRANCH_NAME
corrisponde a qualsiasi 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 uno di questi piani non viene eseguito, la build non va a buon fine.
Allo stesso modo, il comando terraform apply
viene eseguito per i rami di ambiente, ma
viene completamente ignorato in qualsiasi altro caso. In questa sezione hai inviato una modifica del codice a un nuovo ramo, quindi non sono stati applicati deployment dell'infrastruttura al tuo progetto Google Cloud.
Applicazione forzata dell'esecuzione di Cloud Build prima dell'unione dei rami
Per assicurarti che le unioni possano essere applicate solo quando le rispettive esecuzioni di Cloud Build sono riuscite, procedi con i seguenti passaggi:
Su GitHub, vai alla pagina principale del repository creato con fork.
https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
Sotto il nome del repository, fai clic su Impostazioni.
Nel menu a sinistra, fai clic su Filiale.
In Regole di protezione dei rami, fai clic su Aggiungi regola.
In Pattern nome ramo, digita
dev
.Nella sezione Proteggi i rami corrispondenti, seleziona Richiedi il superamento dei controlli di stato prima dell'unione.
Cerca il nome del trigger di Cloud Build creato in precedenza.
Fai clic su Crea.
Ripeti i passaggi da 3 a 7, impostando Pattern nome ramo su
prod
.
Questa configurazione è importante per
proteggere
entrambi i rami dev
e prod
. In altre parole, i commit devono prima essere sottoposti
a push a un altro ramo, dopodiché possono essere uniti al ramo protetto. In questo tutorial, la protezione richiede che l'esecuzione di Cloud Build vada a buon fine affinché l'unione sia consentita.
Promozione di modifiche all'ambiente di sviluppo
Hai una richiesta di pull in attesa di essere unita. È il momento di applicare lo stato desiderato
all'ambiente dev
.
Su GitHub, vai alla pagina principale del repository creato con fork.
https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
Sotto il nome del repository, fai clic su Richieste pull.
Fai clic sulla richiesta di pull appena creata.
Fai clic su Unisci richiesta di pull, quindi su Conferma unione.
Verifica che sia stato attivato un nuovo Cloud Build:
Apri la build e controlla i log. Ti mostra tutte le risorse che Terraform crea e gestisce.
Promozione di modifiche all'ambiente di produzione
Ora che il tuo ambiente di sviluppo è stato testato, puoi promuovere il codice per le regole sulla qualità dei dati in produzione.
Su GitHub, vai alla pagina principale del repository creato con fork.
https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
Sotto il nome del repository, fai clic su Richieste pull.
Fai clic su Nuova richiesta di pull.
Per il repository di base, seleziona il repository appena creato con fork.
Per base, seleziona
prod
dal tuo repository di base. Per confronta, selezionadev
.Fai clic su Crea richiesta di pull.
Per title, inserisci un titolo, come
Changing label name
, quindi fai clic su Crea richiesta di pull.Esamina le modifiche proposte, inclusi i dettagli di
terraform plan
di Cloud Build, quindi fai clic su Unisci richiesta di pull.Fai clic su Conferma unione.
Nella console Google Cloud, apri la pagina Cronologia build per visualizzare le modifiche applicate all'ambiente di produzione:
Hai configurato correttamente le regole sulla qualità dei dati gestite tramite 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 addebitati costi in futuro.
Elimina il progetto
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Eliminazione del repository GitHub
Per evitare di bloccare le nuove richieste di pull nel tuo repository GitHub, puoi eliminare le regole di protezione dei rami:
- In GitHub, vai alla pagina principale del repository creato con fork.
- Sotto il nome del repository, fai clic su Impostazioni.
- Nel menu a sinistra, fai clic su Filiale.
- Nella sezione Regole di protezione dei rami, fai clic sul pulsante Elimina per le righe
dev
eprod
.
Facoltativamente, puoi disinstallare completamente l'app Cloud Build da GitHub:
In GitHub, vai alla pagina delle applicazioni GitHub.
Nella scheda App GitHub installate, fai clic su Configura nella riga Cloud Build. Quindi, nella sezione Zona pericolo, fai clic sul pulsante Disinstalla nella riga Disinstalla Google Cloud Builder.
Nella parte superiore della pagina viene visualizzato il messaggio "Fatto. Un job è stato messo in coda per disinstallare Google Cloud Build."
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:
- In GitHub, vai alla pagina principale del repository creato con fork.
- Sotto il nome del repository, fai clic su Impostazioni.
- Vai a Pericolo.
- Fai clic su Elimina questo repository e segui la procedura di conferma.
Passaggi successivi
- Scopri di più sulla qualità automatica dei dati.
- Scopri di più sulle best practice per DevOps e DevOps.
- Esplora il Cloud Foundation Toolkit per trovare altri modelli Terraform.