Questa pagina spiega come creare una pipeline di integrazione e distribuzione continue (CI/CD) su Google Cloud utilizzando solo prodotti in hosting e la popolare metodo GitOps.
I tecnici Google archiviano da molto tempo i file di configurazione e di deployment nel repository principale del codice sorgente. Questa metodologia è descritta nel libro Site Reliability Engineering, Capitolo 8 (Beyer et. al., 2016) ed è stato dimostrato da Kelsey Hightower durante il corso di apertura di Google Cloud Next '17.
Una parte fondamentale di GitOps è l'idea di "environments-as-code", che descrive i tuoi deployment in modo dichiarativo mediante file (ad esempio, manifest di Kubernetes) archiviati in un repository Git.
In questo tutorial creerai una pipeline CI/CD che crea automaticamente un'immagine container dal codice sottoposto a commit, archivia l'immagine in Artifact Registry, aggiorna un manifest Kubernetes in un repository Git ed esegue il deployment dell'applicazione in Google Kubernetes Engine (GKE) utilizzando questo manifest.
Questo tutorial utilizza due repository Git:
- Repository di app: contiene il codice sorgente dell'applicazione stessa
- Repository env: contiene i manifest per il deployment Kubernetes
Quando esegui il push di una modifica al repository app, la pipeline Cloud Build esegue i test, crea un'immagine container e ne esegue il push ad Artifact Registry. Dopo aver eseguito il push dell'immagine, Cloud Build aggiorna il manifest del deployment ed esegue il push al repository env. Questo attiva un'altra pipeline di Cloud Build che applica il manifest al cluster GKE e, in caso di esito positivo, archivia il manifest in un altro ramo del repository env.
Manteniamo separati i repository app ed env perché hanno cicli di vita e utilizzi diversi. Gli utenti principali del repository app sono persone reali e questo repository è dedicato a un'applicazione specifica. Gli utenti principali del repository env sono sistemi automatizzati (come Cloud Build) e questo repository potrebbe essere condiviso da più applicazioni. Il repository env può avere diversi rami, ognuno dei quali mappa a un ambiente specifico (in questo tutorial utilizzi solo la produzione) e fa riferimento a un'immagine container specifica, mentre il repository app non lo fa.
Al termine di questo tutorial, disponi di un sistema in cui puoi facilmente:
- Distinguere tra deployment non riusciti e riusciti esaminando la cronologia di Cloud Build,
- Accedi al manifest attualmente utilizzato osservando il ramo production del repository env,
- Esegui il rollback a qualsiasi versione precedente eseguendo nuovamente la build di Cloud Build corrispondente.
Informazioni su questo tutorial
Questo tutorial utilizza Cloud Source Repositories per l'hosting dei repository Git, ma puoi ottenere gli stessi risultati con altri prodotti di terze parti come GitHub, Bitbucket o GitLab.
Questa pipeline non implementa un meccanismo di convalida prima del deployment. Se utilizzi GitHub, Bitbucket o GitLab, puoi modificare la pipeline in modo da utilizzare una richiesta di pull a questo scopo.
Anche se consigliamo di utilizzare Spinnaker ai team che vogliono implementare pattern di deployment avanzati (blu/verde, analisi canary, multi-cloud e così via), il suo insieme di funzionalità potrebbe non essere necessario per una strategia CI/CD efficace per organizzazioni e progetti più piccoli. In questo tutorial imparerai a creare una pipeline CI/CD adatta alle applicazioni ospitate su GKE con gli strumenti.
Per semplicità, questo tutorial utilizza un unico ambiente, di produzione, nel repository env, ma è possibile estenderlo per eseguire il deployment in più ambienti, se necessario.
Obiettivi
- Creare repository Git in Cloud Source Repositories.
- Creare un'immagine container con Cloud Build e archiviarla in Artifact Registry.
- Creare una pipeline CI.
- Creare una pipeline CD.
- Testa la pipeline CI/CD.
Costi
In questo documento, utilizzi 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.
Prima di iniziare
Seleziona o crea un progetto Google Cloud.
Abilita la fatturazione per il tuo progetto.
Apri Cloud Shell per eseguire i comandi elencati in questo tutorial. Cloud Shell è un ambiente shell interattivo per Google Cloud che permette di gestire progetti e risorse dal browser web.
Se il comando
gcloud config get-value project
non restituisce l'ID del progetto selezionato, configura Cloud Shell per utilizzare il progetto.gcloud config set project [PROJECT_ID]
In Cloud Shell, abilita le API richieste.
gcloud services enable container.googleapis.com \ cloudbuild.googleapis.com \ sourcerepo.googleapis.com \ artifactregistry.googleapis.com
Crea un repository Docker Artifact Registry denominato
my-repository
nella regioneus-central1
per archiviare le tue immagini container.gcloud artifacts repositories create my-repository \ --repository-format=docker \ --location=us-central1
In Cloud Shell, crea un cluster GKE da utilizzare per eseguire il deployment dell'applicazione di esempio di questo tutorial.
Autopilot
Crea un cluster Autopilot denominato
hello-cloudbuild
:gcloud container clusters create-auto hello-cloudbuild \ --region us-central1
Standard
Crea un cluster standard a un nodo denominato
hello-cloudbuild
:gcloud container clusters create hello-cloudbuild \ --num-nodes 1 --region us-central1
Se non hai mai utilizzato Git in Cloud Shell, configuralo con il tuo nome e indirizzo email. Git li utilizzerà per identificarti come autore dei commit che creerai in Cloud Shell.
git config --global user.email "YOUR_EMAIL_ADDRESS" git config --global user.name "YOUR_NAME"
Al termine di questo tutorial, potrai evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori dettagli, consulta Pulizia.
Creazione di repository Git in Cloud Source Repositories
In questa sezione, creerai i due repository Git (app ed env) utilizzati in questo tutorial e inizializzerai app uno con del codice campione.
In Cloud Shell, crea i due repository Git.
gcloud source repos create hello-cloudbuild-app gcloud source repos create hello-cloudbuild-env
Clona il codice campione da GitHub.
cd ~ git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
Configura Cloud Source Repositories come repository remoto.
PROJECT_ID=$(gcloud config get-value project) git remote add google \ "https://source.developers.google.com/p/${PROJECT_ID}/r/hello-cloudbuild-app"
Il codice clonato contiene un'applicazione "Hello World".
Creazione di un'immagine container con Cloud Build
Il codice clonato contiene il seguente Dockerfile.
Con questo Dockerfile puoi creare un'immagine container con Cloud Build e archiviarla in Artifact Registry.
In Cloud Shell, crea una build di Cloud Build basata sul commit più recente con il comando seguente.
cd ~/kubernetes-engine-samples/management/gitops-style-delivery/ COMMIT_ID="$(git rev-parse --short=7 HEAD)" gcloud builds submit --tag="us-central1-docker.pkg.dev/${PROJECT_ID}/my-repository/hello-cloudbuild:${COMMIT_ID}" .
Cloud Build trasmette il flusso dei log generati dalla creazione dell'immagine container al tuo terminale quando esegui questo comando.
Al termine della build, verifica che la nuova immagine container sia disponibile in Artifact Registry.
Creazione della pipeline di integrazione continua
In questa sezione configurerai Cloud Build per eseguire automaticamente un piccolo test delle unità, creare l'immagine container ed eseguirne il push ad Artifact Registry. Il push di un nuovo commit in Cloud Source Repositories
attiva automaticamente questa pipeline. Il file cloudbuild.yaml
incluso nel codice è la configurazione della pipeline.
Apri la pagina Trigger di Cloud Build.
Fai clic su Crea trigger.
Completa le seguenti opzioni:
- Nel campo Nome, digita
hello-cloudbuild
. - In Evento, seleziona Push al ramo.
- In Origine, seleziona
hello-cloudbuild-app
come Repository e^master$
come Ramo. - In Configurazione build, seleziona File di configurazione Cloud Build.
- Nel campo Posizione file di configurazione Cloud Build,
digita
cloudbuild.yaml
dopo/
.
- Nel campo Nome, digita
Fai clic su Crea per salvare il trigger di build.
Suggerimento: se devi creare trigger di build per molti progetti, puoi utilizzare l'API Build Triggers.
In Cloud Shell, esegui il push del codice dell'applicazione in Cloud Source Repositories per attivare la pipeline CI in Cloud Build.
cd ~/kubernetes-engine-samples/management/gitops-style-delivery/ git push google master
Apri la console di Cloud Build.
Vengono visualizzate le build eseguite e terminate di recente. Puoi fare clic su una build per seguirne l'esecuzione ed esaminare i relativi log.
Creazione della pipeline di distribuzione continua
Cloud Build viene utilizzato anche per la pipeline di distribuzione continua. La pipeline viene eseguita ogni volta che viene eseguito il push di un commit nel ramo candidate del repository hello-cloudbuild-env. La pipeline applica la nuova versione del manifest al cluster Kubernetes e, in caso di esito positivo, copia il manifest nel ramo production. Questo processo prevede le seguenti proprietà:
- Il ramo candidate è una cronologia dei tentativi di deployment.
- Il ramo production è una cronologia dei deployment riusciti.
- Puoi visualizzare i deployment riusciti e non riusciti in Cloud Build.
- Puoi eseguire il rollback a qualsiasi deployment precedente eseguendo di nuovo la build corrispondente in Cloud Build. Un rollback aggiorna anche il ramo production per riflettere fedelmente la cronologia dei deployment.
Modificherai la pipeline di integrazione continua per aggiornare il ramo candidate del repository hello-cloudbuild-env, attivando la pipeline di distribuzione continua.
Concessione dell'accesso a Cloud Build a GKE
Per eseguire il deployment dell'applicazione nel cluster Kubernetes, Cloud Build deve disporre del ruolo Sviluppatore di identità e accessi Kubernetes Engine.
Shell
In Cloud Shell, esegui questo comando:
PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)')" gcloud projects add-iam-policy-binding ${PROJECT_NUMBER} \ --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role=roles/container.developer
Console
Nella console Google Cloud, apri la pagina Impostazioni di Cloud Build:
Apri le impostazioni di Cloud Build
Viene visualizzata la pagina Autorizzazioni account di servizio:
Imposta lo stato del ruolo Sviluppatore Kubernetes Engine su Abilitato.
Inizializzazione del repository hello-cloudbuild-env
Devi inizializzare il repository hello-cloudbuild-env con due rami (production e candidate) e un file di configurazione di Cloud Build che descrive il processo di deployment.
In Cloud Shell, clona il repository hello-cloudbuild-env e crea il ramo production.
cd ~ gcloud source repos clone hello-cloudbuild-env cd ~/kubernetes-engine-samples/management/gitops-style-delivery/ git checkout -b production
Copia il file
cloudbuild-delivery.yaml
disponibile nel repository hello-cloudbuild-app ed esegui il commit della modifica.cd ~/kubernetes-engine-samples/management/gitops-style-delivery/ cp ~/hello-cloudbuild-app/cloudbuild-delivery.yaml ~/kubernetes-engine-samples/management/gitops-style-delivery/cloudbuild.yaml git add . git commit -m "Create cloudbuild.yaml for deployment"
Il file
cloudbuild-delivery.yaml
descrive il processo di deployment da eseguire in Cloud Build. che prevede due passaggi:Cloud Build applica il manifest sul cluster GKE.
In caso di esito positivo, Cloud Build copia il manifest nel ramo production.
Crea un ramo candidate ed esegui il push di entrambi i rami per renderli disponibili in Cloud Source Repositories.
git checkout -b candidate git push origin production git push origin candidate
Concedi il ruolo IAM Writer repository di codice sorgente all'account di servizio Cloud Build per il repository hello-cloudbuild-env.
PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \ --format='get(projectNumber)')" cat >/tmp/hello-cloudbuild-env-policy.yaml <<EOF bindings: - members: - serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com role: roles/source.writer EOF gcloud source repos set-iam-policy \ hello-cloudbuild-env /tmp/hello-cloudbuild-env-policy.yaml
Creazione del trigger per la pipeline di distribuzione continua
In questa sezione configurerai Cloud Build in modo che venga attivato da un push al ramo candidate del repository hello-cloudbuild-env.
Apri la pagina Trigger di Cloud Build.
Fai clic su Crea trigger.
Completa le seguenti opzioni:
- Nel campo Nome, digita
hello-cloudbuild-deploy
. - In Evento, seleziona Push al ramo.
- In Origine, seleziona
hello-cloudbuild-env
come Repository e^candidate$
come Ramo. - In Configurazione, seleziona File di configurazione Cloud Build (yaml o json).
- Nel campo Posizione file di configurazione Cloud Build,
digita
cloudbuild.yaml
dopo/
.
- Nel campo Nome, digita
Fai clic su Crea.
Modifica della pipeline di integrazione continua per attivare la pipeline di distribuzione continua
In questa sezione aggiungerai alcuni passaggi alla pipeline di integrazione continua che generano una nuova versione del manifest Kubernetes e ne eseguirai il push al repository hello-cloudbuild-env per attivare la pipeline di distribuzione continua.
Sostituisci il file
cloudbuild.yaml
con l'esempio esteso nel filecloudbuild-trigger-cd.yaml
.cd ~/kubernetes-engine-samples/management/gitops-style-delivery/ cp cloudbuild-trigger-cd.yaml cloudbuild.yaml
cloudbuild-trigger-cd.yaml
è una versione estesa del filecloudbuild.yaml
. Aggiunge passaggi per generare il nuovo manifest di Kubernetes e attivare la pipeline di distribuzione continua.Esegui il commit delle modifiche e inviale a Cloud Source Repositories.
cd ~/kubernetes-engine-samples/management/gitops-style-delivery/ git add cloudbuild.yaml git commit -m "Trigger CD pipeline" git push google master
In questo modo viene attivata la pipeline di integrazione continua in Cloud Build.
Esamina la build di integrazione continua.
Vengono visualizzate le build eseguite e terminate di recente per il repository hello-cloudbuild-app. Puoi fare clic su una build per seguirne l'esecuzione ed esaminare i log. L'ultimo passaggio di questa pipeline esegue il push del nuovo manifest al repository hello-cloudbuild-env, che attiva la pipeline di distribuzione continua.
Esamina la build di distribuzione continua.
Vengono visualizzate le build completate e eseguite di recente per il repository hello-cloudbuild-env. Puoi fare clic su una build per seguirne l'esecuzione ed esaminare i relativi log.
Test della pipeline completa
La pipeline CI/CD completa è ora configurata. In questa sezione, lo testerai dall'inizio alla fine.
Vai alla pagina Servizi GKE.
Vai ai servizi Google Kubernetes Engine
L'elenco contiene un singolo servizio denominato hello-cloudbuild creato dalla build di distribuzione continua completata di recente.
Fai clic sull'endpoint per il servizio hello-cloudbuild. Viene visualizzato il messaggio "Hello World!". Se non è presente alcun endpoint o se visualizzi un errore del bilanciatore del carico, potresti dover attendere alcuni minuti prima che il bilanciatore del carico sia completamente inizializzato. Fai clic su Aggiorna per aggiornare la pagina, se necessario.
In Cloud Shell, sostituisci "Hello World" con "Hello Cloud Build", sia nell'applicazione sia nel test delle unità.
cd ~/kubernetes-engine-samples/management/gitops-style-delivery/ sed -i 's/Hello World/Hello Cloud Build/g' app.py sed -i 's/Hello World/Hello Cloud Build/g' test_app.py
Esegui il commit e il push della modifica in Cloud Source Repositories.
git add app.py test_app.py git commit -m "Hello Cloud Build" git push google master
Questo attiva la pipeline CI/CD completa.
Dopo qualche minuto, ricarica l'applicazione nel browser. Viene visualizzato il messaggio "Hello Cloud Build!".
Test del rollback
In questa sezione eseguirai il rollback alla versione dell'applicazione che diceva "Hello World!".
Apri la console Cloud Build per il repository hello-cloudbuild-env.
Fai clic sulla seconda build più recente disponibile.
Fai clic su Ricrea.
Al termine dell'esecuzione della build, ricarica l'applicazione nel browser. Viene visualizzato di nuovo "Hello World!".
Esegui la pulizia
Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.
- 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 delle risorse
Se vuoi conservare il progetto Google Cloud utilizzato in questo tutorial, elimina le singole risorse:
Elimina i repository Git locali.
cd ~ rm -rf ~/hello-cloudbuild-app rm -rf ~/hello-cloudbuild-env
Elimina i repository Git in Cloud Source Repositories.
gcloud source repos delete hello-cloudbuild-app --quiet gcloud source repos delete hello-cloudbuild-env --quiet
Eliminare i trigger di Cloud Build.
Apri la pagina Trigger di Cloud Build.
Per ogni attivatore, fai clic su Altro more_vert, poi su Elimina.
Elimina il repository Docker in Artifact Registry.
gcloud artifacts repositories delete my-repository \ --location=us-central1
Rimuovi l'autorizzazione concessa a Cloud Build per la connessione a GKE.
PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \ --format='get(projectNumber)')" gcloud projects remove-iam-policy-binding ${PROJECT_NUMBER} \ --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role=roles/container.developer
Elimina il cluster GKE.
gcloud container clusters delete hello-cloudbuild \ --region us-central1
Passaggi successivi
- Dai un'occhiata alle funzionalità più avanzate di Cloud Build: Configurazione dell'ordine dei passaggi di build, Creazione, test e deployment degli artefatti, Creazione di passaggi di build personalizzati
- Scopri come eseguire il mirroring di un repository GitHub o Bitbucket in Cloud Source Repositories
- Connetti direttamente Cloud Build al tuo repository GitHub