Questo tutorial descrive come configurare e utilizzare un sistema di sviluppo, integrazione continua (CI) e distribuzione continua (CD) utilizzando un set integrato di strumenti Google Cloud. Puoi utilizzare questo sistema per sviluppare ed eseguire il deployment di applicazioni in Google Kubernetes Engine (GKE).
Questo tutorial è destinato sia agli sviluppatori di software che agli operatori e svolgerai entrambi i ruoli man mano che lo completi. Innanzitutto agisci come operatore per configurare la pipeline CI/CD. I componenti principali di questa pipeline sono Cloud Build, Artifact Registry e Google Cloud Deploy.
Successivamente, agisci come sviluppatore per modificare un'applicazione utilizzando Cloud Code. Quando agisci come sviluppatore, vedi l'esperienza integrata fornita da questa pipeline.
Infine, agisci come operatore e segui i passaggi per eseguire il deployment di un'applicazione in produzione.
Questo tutorial presuppone che tu abbia dimestichezza con l'esecuzione di comandi gcloud
su Google Cloud e con il deployment di container di applicazioni in GKE.
Di seguito sono riportate le funzionalità principali di questo sistema integrato:
Sviluppo e deployment più rapidi.
Il ciclo di sviluppo è efficiente perché puoi convalidare le modifiche nell'area di lavoro dello sviluppatore. Il deployment è rapido perché il sistema CI/CD automatizzato e la maggiore parità negli ambienti consentono di rilevare più problemi durante il deployment delle modifiche in produzione.
Approfitta di una maggiore parità tra sviluppo, gestione temporanea e produzione.
I componenti di questo sistema utilizzano un set comune di strumenti Google Cloud.
Riutilizza le configurazioni nei diversi ambienti.
Questo riutilizzo viene eseguito con Skaffold, che consente un formato di configurazione comune per i diversi ambienti. Consente inoltre a sviluppatori e operatori di aggiornare e utilizzare la stessa configurazione.
Applica la governance nelle prime fasi del flusso di lavoro.
Questo sistema applica test di convalida per la governance in produzione e nell'ambiente di sistema e di sviluppo CI. L'applicazione della governance nell'ambiente di sviluppo consente di individuare e risolvere i problemi prima.
Consenti agli strumenti di gestione di gestire la distribuzione del software.
La distribuzione continua è completamente gestita, separando le fasi della pipeline di CD dai dettagli di rendering e deployment.
Panoramica dell'architettura
Il seguente diagramma mostra le risorse utilizzate in questo tutorial:
I tre componenti principali di questa pipeline sono:
Cloud Code come area di lavoro di sviluppo
Come parte di questa area di lavoro, puoi vedere i cambiamenti nel cluster di sviluppo, che viene eseguito su minikube. Esegui Cloud Code e il cluster minikube in Cloud Shell. Cloud Shell è un ambiente di sviluppo online accessibile dal browser. Ha risorse di calcolo, memoria, un ambiente di sviluppo integrato (IDE) e Cloud Code installato.
Cloud Build per creare e testare l'applicazione: la parte "CI" della pipeline
Questa parte della pipeline include le seguenti azioni:
- Cloud Build monitora le modifiche al repository di origine, utilizzando un trigger di Cloud Build.
- Quando viene eseguito il commit di una modifica nel ramo principale, il trigger Cloud Build esegue le seguenti operazioni:
- Ricrea il container dell'applicazione.
- I luoghi creano artefatti in un bucket Cloud Storage.
- Posiziona il container dell'applicazione in Artifact Registry.
- Esegue test sul container.
- Chiama Google Cloud Deploy per eseguire il deployment del container nell'ambiente di gestione temporanea. In questo tutorial, l'ambiente di gestione temporanea è un cluster Google Kubernetes Engine.
- Se la build e i test hanno esito positivo, puoi utilizzare Google Cloud Deploy per promuovere il container dallo staging alla produzione.
Google Cloud Deploy per gestire il deployment, la parte "CD" della pipeline
In questa parte della pipeline, Google Cloud Deploy esegue queste operazioni:
- Registra una pipeline di distribuzione e dei target. Le destinazioni rappresentano i cluster di fase e produzione.
- Crea un bucket Cloud Storage e archivia l'origine di rendering Skaffold e i manifest in tale bucket.
- Genera una nuova release per ogni modifica del codice sorgente. In questo tutorial c'è una modifica, quindi una nuova release.
- Esegue il deployment dell'applicazione nell'ambiente di produzione. Per questo deployment in produzione, un operatore (o altra persona designata) approva manualmente il deployment. In questo tutorial, l'ambiente di produzione è un cluster Google Kubernetes Engine.
Skaffold, uno strumento a riga di comando che facilita lo sviluppo continuo per le applicazioni native di Kubernetes, è alla base di questi componenti e consente la condivisione della configurazione tra gli ambienti di sviluppo, gestione temporanea e produzione.
Google Cloud archivia il codice sorgente dell'applicazione in GitHub e, nell'ambito di questo tutorial, cloni il repository in Cloud Source Repositories per connetterlo alla pipeline CI/CD.
Questo tutorial utilizza i prodotti Google Cloud per la maggior parte dei componenti del sistema e Skaffold consente l'integrazione del sistema. Skaffold è open source, pertanto puoi utilizzare questi principi per creare un sistema simile utilizzando una combinazione di componenti di Google Cloud, interni e di terze parti. La modularità di questa soluzione significa che puoi adottarla in modo incrementale nell'ambito della tua pipeline di sviluppo e deployment.
Obiettivi
In qualità di operatore, esegui queste operazioni:
- Configurare la pipeline CI e la pipeline CD. Questa configurazione include quanto segue:
- Configura le autorizzazioni richieste.
- Creare i cluster GKE per gli ambienti di gestione temporanea e di produzione.
- Creare un repository in Cloud Source Repositories per il codice sorgente.
- Creare un repository in Artifact Registry per il container dell'applicazione.
- Creare un trigger di Cloud Build sul repository GitHub principale.
- Creare una pipeline di distribuzione e le destinazioni di Google Cloud Deploy. I target sono l'ambiente di gestione temporanea e di produzione.
- Avvia il processo CI/CD per il deployment in gestione temporanea e poi passa alla produzione.
In qualità di sviluppatore, apporti una modifica all'applicazione. Per farlo, segui questi passaggi:
- Clona il repository per lavorare con un ambiente di sviluppo preconfigurato.
- Apporta una modifica all'applicazione all'interno della tua area di lavoro per sviluppatori.
- Crea e testa la modifica. I test includono un test di convalida per la governance.
- Visualizza e convalida la modifica in un cluster di sviluppo. Questo cluster viene eseguito su minikube.
- Esegui il commit della modifica nel repository principale.
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
- Cloud Build
- Google Cloud Deploy
- Artifact Registry
- Google Kubernetes Engine
- Cloud Source Repositories
- Cloud Storage
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
-
Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API Artifact Registry, Cloud Build, Google Cloud Deploy, Cloud Source Repositories, Google Kubernetes Engine, Resource Manager, and Service Networking.
-
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.
prepara l'ambiente
In questa sezione, in qualità di operatore dell'applicazione devi:
- Configura le autorizzazioni richieste.
- Creare i cluster GKE per gli ambienti di gestione temporanea e di produzione.
- Clona il repository di origine.
- Creare un repository in Cloud Source Repositories per il codice sorgente.
- Creare un repository in Artifact Registry per l'applicazione container.
Configurare le autorizzazioni
In questa sezione concederai le autorizzazioni necessarie per configurare la pipeline CI/CD.
Se stai lavorando in una nuova istanza dell'editor di Cloud Shell, specifica il progetto da utilizzare per questo tutorial:
gcloud config set project PROJECT_ID
Sostituisci PROJECT_ID con l'ID del progetto selezionato o creato per questo tutorial.
Se viene visualizzata una finestra di dialogo, fai clic su Autorizza.
Concedi agli account di servizio le autorizzazioni richieste:
Assicurati che l'account di servizio predefinito di Compute Engine abbia le autorizzazioni sufficienti per eseguire i job in Google Cloud Deploy ed eseguire il pull dei container da Artifact Registry. Cloud Build e Google Cloud Deploy utilizzano questo account di servizio predefinito.
Questo account di servizio potrebbe già disporre delle autorizzazioni necessarie. Questo passaggio garantisce che vengano concesse le autorizzazioni necessarie per i progetti che disattivano la concessione automatica dei ruoli per gli account di servizio predefiniti.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")-compute@developer.gserviceaccount.com \ --role="roles/clouddeploy.jobRunner" gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")-compute@developer.gserviceaccount.com \ --role="roles/artifactregistry.reader"
Concedi al privilegio dell'account di servizio Cloud Build di richiamare i deployment con Google Cloud Deploy e di aggiornare la pipeline di distribuzione e le definizioni di destinazione:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \ --role="roles/clouddeploy.operator"
Consulta il ruolo clouddeploy.operator per ulteriori dettagli su questo ruolo IAM.
Concedi i privilegi dell'account di servizio Cloud Build e Google Cloud Deploy per il deployment su GKE:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")-compute@developer.gserviceaccount.com \ --role="roles/container.admin"
Per ulteriori dettagli su questo ruolo IAM, consulta il ruolo container.admin.
Concedi all'account di servizio Cloud Build le autorizzazioni necessarie per richiamare le operazioni di Google Cloud Deploy:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \ --role="roles/iam.serviceAccountUser"
Quando Cloud Build richiama Google Cloud Deploy, utilizza un account di servizio Compute Engine per creare una release, motivo per cui questa autorizzazione è necessaria.
Per ulteriori dettagli su questo ruolo IAM, consulta il ruolo iam.serviceAccountUser.
Hai concesso le autorizzazioni necessarie per la pipeline CI/CD.
Crea i cluster GKE
In questa sezione creerai gli ambienti di gestione temporanea e di produzione, che sono entrambi cluster GKE. Non è necessario configurare il cluster di sviluppo qui, perché utilizza minikube.
Crea i cluster GKE di gestione temporanea e di produzione:
gcloud container clusters create-auto staging \ --region us-central1 \ --project=$(gcloud config get-value project) \ --async
gcloud container clusters create-auto prod \ --region us-central1 \ --project=$(gcloud config get-value project) \ --async
Nel cluster di gestione temporanea puoi testare le modifiche al codice. Dopo aver verificato che il deployment gestione temporanea non abbia influito negativamente sull'applicazione, esegui il deployment in produzione.
Esegui il comando seguente e assicurati che l'output abbia
STATUS: RUNNING
per i cluster temporanei e di produzione:gcloud container clusters list
Recupera le credenziali nei file
kubeconfig
per i cluster temporanei e di produzione.Utilizza queste credenziali per interagire con i cluster GKE, ad esempio per verificare se un'applicazione è in esecuzione correttamente.
gcloud container clusters get-credentials staging --region us-central1
gcloud container clusters get-credentials prod --region us-central1
Hai creato i cluster GKE per l'ambiente di gestione temporanea e di produzione.
Apri l'IDE e clona il repository
Per clonare il repository e visualizzare l'applicazione nel tuo ambiente di sviluppo, procedi come segue:
Fai clic su Conferma.
L'editor di Cloud Shell apre e clona il repository di esempio.
Ora puoi visualizzare il codice dell'applicazione nell'editor di Cloud Shell.
Specifica il progetto da utilizzare per questo tutorial:
gcloud config set project PROJECT_ID
Se viene visualizzata una finestra di dialogo, fai clic su Autorizza.
Ora hai il codice sorgente per l'applicazione nel tuo ambiente di sviluppo.
Questo repository di codice di origine include i file Cloud Build e Google Cloud Deploy necessari per la pipeline CI/CD.
Creare repository per il codice sorgente e i container
In questa sezione configurerai un repository in Cloud Source Repositories per il codice sorgente e un repository in Artifact Registry per archiviare i container creati dalla pipeline CI/CD.
Creare un repository in Cloud Source Repositories per archiviare il codice sorgente e collegarlo al processo CI/CD:
gcloud source repos create cicd-sample
Assicurati che le configurazioni di Google Cloud Deploy abbiano come target il progetto corretto:
sed -i s/project-id-placeholder/$(gcloud config get-value project)/g deploy/* git config --global credential.https://source.developers.google.com.helper gcloud.sh git remote add google https://source.developers.google.com/p/$(gcloud config get-value project)/r/cicd-sample
Esegui il push del codice sorgente nel repository:
git push --all google
Crea un repository di immagini in Artifact Registry:
gcloud artifacts repositories create cicd-sample-repo \ --repository-format=Docker \ --location us-central1
Ora hai un repository per il codice sorgente in Cloud Source Repositories e uno per il container dell'applicazione in Artifact Registry. Il repository Cloud Source Repositories consente di clonare il codice sorgente e collegarlo alla pipeline CI/CD.
Configura la pipeline CI/CD
In questa sezione, operi come operatore dell'applicazione e configuri la pipeline CI/CD. La pipeline utilizza Cloud Build per CI e Google Cloud Deploy per CD. I passaggi della pipeline sono definiti nel trigger di Cloud Build.
Crea un bucket Cloud Storage per Cloud Build per archiviare il file
artifacts.json
(che monitora gli artefatti generati da Skaffold per ogni build):gsutil mb gs://$(gcloud config get-value project)-gceme-artifacts/
Archiviare il file
artifacts.json
di ogni build in una posizione centrale è una buona prassi perché offre la tracciabilità, che semplifica la risoluzione dei problemi.Esamina il file
cloudbuild.yaml
, che definisce il trigger di Cloud Build, e che è già configurato nel repository di origine che hai clonato.Questo file definisce il trigger richiamato ogni volta che viene eseguito un nuovo push al ramo principale del repository del codice sorgente.
I passaggi per la pipeline CI/CD sono definiti in questo file:
Cloud Build utilizza Skaffold per creare il container dell'applicazione.
Cloud Build inserisce il file
artifacts.json
della build nel bucket Cloud Storage.Cloud Build posiziona il container dell'applicazione in Artifact Registry.
Cloud Build esegue test sul container dell'applicazione.
Il comando
gcloud deploy apply
registra i seguenti file con il servizio Google Cloud Deploy:deploy/pipeline.yaml
, ovvero la pipeline di distribuzionedeploy/staging.yaml
edeploy/prod.yaml
, che sono i file di destinazioneUna volta registrati i file, Google Cloud Deploy crea la pipeline e le destinazioni se non esistono ancora o le ricrea se la configurazione è cambiata. I target sono gli ambienti di gestione temporanea e di produzione.
Google Cloud Deploy crea una nuova release per la pipeline di distribuzione.
Questa release fa riferimento al container dell'applicazione, creato e testato nel processo CI.
Google Cloud Deploy esegue il deployment della release nell'ambiente di gestione temporanea.
La pipeline e le destinazioni di distribuzione sono gestite da Google Cloud Deploy e sono disaccoppiate dal codice sorgente. Questo disaccoppiamento significa che non è necessario aggiornare la pipeline di distribuzione e i file di destinazione quando viene apportata una modifica al codice sorgente dell'applicazione.
Crea il trigger di Cloud Build:
gcloud beta builds triggers create cloud-source-repositories \ --name="cicd-sample-main" \ --repo="cicd-sample" \ --branch-pattern="main" \ --build-config="cloudbuild.yaml"
Questo trigger indica a Cloud Build di osservare il repository di origine e di utilizzare il file
cloudbuild.yaml
per reagire a qualsiasi modifica al repository. Questo trigger viene richiamato ogni volta che viene eseguito un nuovo push al ramo principale.Vai su Cloud Build e nota che non sono presenti build per la tua applicazione.
A questo punto hai configurato le pipeline CI e CD e creato un trigger nel ramo principale del repository.
Apporta una modifica all'applicazione all'interno dell'area di lavoro dello sviluppatore
In questa sezione agisci come sviluppatore dell'applicazione.
Durante lo sviluppo dell'applicazione, puoi apportare e verificare le modifiche iterative all'applicazione utilizzando Cloud Code come area di lavoro di sviluppo:
- Apporta una modifica all'applicazione.
- Creare e testare il nuovo codice.
- Eseguire il deployment dell'applicazione nel cluster minikube e verificare le modifiche apportate dall'utente.
- Invia la modifica al repository principale.
Quando viene eseguito il commit di questa modifica nel repository principale, il trigger Cloud Build avvia la pipeline CI/CD.
Crea, testa ed esegui l'applicazione
In questa sezione creerai, testerai, eseguirai il deployment e accederai all'applicazione.
Utilizzare la stessa istanza dell'editor di Cloud Shell utilizzata nella sezione precedente. Se hai chiuso l'editor, apri l'editor di Cloud Shell nel browser andando all'indirizzo ide.cloud.google.com.
Nel terminale, avvia minikube:
minikube start
minikube configura un cluster Kubernetes locale in Cloud Shell. L'esecuzione di questa configurazione richiede alcuni minuti. Al termine, il processo minikube viene eseguito in background sull'istanza di Cloud Shell.
Nel riquadro nella parte inferiore dell'editor di Cloud Shell, seleziona Cloud Code.
Nel riquadro sottile che appare tra il terminale e l'editor, seleziona Esegui su Kubernetes.
Se viene visualizzato un messaggio
Use current context (minikube) to run the app?
, fai clic su Sì.Questo comando crea il codice sorgente ed esegue i test. Questa operazione può richiedere alcuni minuti. I test includono test delle unità e un passaggio di convalida preconfigurato che controlla le regole impostate per l'ambiente di deployment. In questo modo riceverai un avviso sui problemi di deployment anche quando stai ancora lavorando nel tuo ambiente di sviluppo.
La scheda Output mostra l'avanzamento di Skaffold durante la creazione e il deployment della tua applicazione.
Tieni la scheda aperta in questa sezione.
Al termine della build e dei test, la scheda Output indica
Update succeeded
e mostra due URL.Durante la creazione e il test dell'app, Cloud Code trasmette il flusso di log e URL nella scheda Output. Man mano che apporti modifiche ed esegui test nel tuo ambiente di sviluppo, puoi vedere la versione dell'app nel tuo ambiente di sviluppo e verificare che funzioni correttamente.
L'output dice anche
Watching for changes...
, il che significa che la modalità orologio è abilitata. Quando Cloud Code è in modalità di visualizzazione, il servizio rileva eventuali modifiche salvate nel repository ed esegue automaticamente la ricreazione e il deployment dell'app con le modifiche più recenti.Nel terminale Cloud Code, tieni il puntatore sul primo URL nell'output (
http://localhost:8080
).Nella descrizione comando dello strumento, seleziona Apri anteprima web.
In background, Cloud Code esegue automaticamente il port forwarding del traffico al servizio
cicd-sample
in esecuzione su minikube.Nel browser, aggiorna la pagina.
Il numero accanto a Contatore aumenta, per indicare che l'app risponde all'aggiornamento.
Nel browser, lascia aperta questa pagina in modo da poter visualizzare l'applicazione mentre apporti modifiche nel tuo ambiente locale.
Ora hai creato e testato la tua applicazione nell'ambiente di sviluppo. Hai eseguito il deployment dell'applicazione nel cluster di sviluppo in esecuzione su minikube e hai visualizzato il comportamento dell'applicazione rivolto agli utenti.
Apporta una modifica
In questa sezione, apporti una modifica all'applicazione e la visualizzi mentre l'applicazione viene eseguita nel cluster di sviluppo.
Nell'editor di Cloud Shell, apri il file
index.html
.Cerca la stringa
Sample App Info
e modificala insample app info
, in modo che il titolo ora utilizzi lettere minuscole.Il file viene salvato automaticamente, attivando una ricreazione del container dell'applicazione.
Cloud Code rileva la modifica e ne esegue nuovamente il deployment automaticamente. La scheda Output mostra
Update initiated
. L'esecuzione di questo nuovo deployment richiede alcuni minuti.Questa funzionalità di deployment automatico è disponibile per qualsiasi applicazione in esecuzione su un cluster Kubernetes.
Al termine della build, vai al browser, apri l'app e aggiorna la pagina.
Quando esegui l'aggiornamento, controlla che il testo ora utilizzi lettere minuscole.
Questa configurazione consente di ricaricare automaticamente qualsiasi architettura, con qualsiasi componente. Quando utilizzi Cloud Code e minikube, tutto ciò che è in esecuzione in Kubernetes include questa funzionalità di ricaricamento di hot code.
Puoi eseguire il debug delle applicazioni di cui viene eseguito il deployment in un cluster Kubernetes in Cloud Code. Questi passaggi non sono trattati in questo tutorial, ma per maggiori dettagli consulta Debug di un'applicazione Kubernetes.
Esegui il commit del codice
Ora che hai apportato una modifica all'applicazione, esegui il commit del codice:
Configura la tua identità Git:
git config --global user.email "YOU@EXAMPLE.COM" git config --global user.name "NAME"
Sostituisci quanto segue:
- YOU@EXAMPLE.COM con l'indirizzo email collegato al tuo account GitHub
- NAME con il nome collegato al tuo account GitHub
Nel terminale, esegui il commit del codice:
git add . git commit -m "use lowercase for: sample app info"
Non è necessario eseguire il comando
git push
qui. Questo avviene dopo.
Lavorando nell'ambiente di sviluppo, hai apportato una modifica all'applicazione, sviluppato e testato la modifica e verificato il comportamento di tali modifiche rivolto all'utente. I test nell'ambiente di sviluppo includono controlli di governance, che consentono di risolvere i problemi che causano problemi nell'ambiente di produzione.
In questo tutorial, quando esegui il commit del codice nel repository principale, non verrà eseguito un esame del codice. Tuttavia, una procedura di revisione del codice o di approvazione delle modifiche è una procedura consigliata per lo sviluppo del software.
Per ulteriori informazioni sulle best practice per l'approvazione delle modifiche, consulta la pagina Semplificare l'approvazione delle modifiche.
Esegui il deployment di una modifica in produzione
In questa sezione, in qualità di operatore dell'applicazione devi:
- Attiva la pipeline CI/CD, che esegue il deployment della release nell'ambiente di gestione temporanea.
- Promuovi e approva la release in produzione.
Avvia la pipeline CI/CD ed esegui il deployment in gestione temporanea
In questa sezione, avvierai la pipeline CI/CD richiamando il trigger di Cloud Build. Questo trigger viene richiamato ogni volta che viene eseguito il commit di una modifica nel repository principale. Puoi anche avviare il sistema CI con un trigger manuale.
Nell'editor di Cloud Shell, esegui il comando seguente per attivare una build:
git push google
Questa build include la modifica apportata a
cicd-sample
.Torna alla dashboard di Cloud Build e controlla che sia stata creata una build.
Fai clic su In esecuzione: cicd-sample - cicd-sample-main nel log di build a destra e cerca il testo blu che indica l'inizio e la fine di ogni passaggio.
Il passaggio 0 mostra l'output delle istruzioni
skaffold build
eskaffold test
dal filecloudbuild.yaml
. Le attività di build e test nel Passaggio 0 (la parte CI della pipeline) sono andate a buon fine, quindi le attività di deployment del Passaggio 1 (la parte CD della pipeline) vengono ora eseguite.Questo passaggio viene completato correttamente con il seguente messaggio:
Created Google Cloud Deploy rollout ROLLOUT_NAME in target staging
Apri la pagina delle pipeline di distribuzione di Google Cloud Deploy e fai clic sulla pipeline
cicd-sample delivery
.Il deployment dell'applicazione viene eseguito in gestione temporanea, ma non in produzione.
Verifica che l'applicazione funzioni correttamente in gestione temporanea:
kubectl proxy --port 8001 --context gke_$(gcloud config get-value project)_us-central1_staging
Questo comando configura un proxy kubectl per accedere all'applicazione.
Accedi all'applicazione da Cloud Shell:
Nell'editor di Cloud Shell, apri una nuova scheda del terminale.
Invia una richiesta a
localhost
per incrementare un contatore:curl -s http://localhost:8001/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter
Puoi eseguire questo comando più volte e osservare l'incremento del valore del contatore ogni volta.
Mentre visualizzi l'app, nota che il testo che hai modificato si trova nella versione dell'applicazione di cui hai eseguito il deployment in gestione temporanea.
Chiudi questa seconda scheda.
Nella prima scheda, premi
Control+C
per interrompere il proxy.
Hai richiamato il trigger di Cloud Build per avviare il processo CI, che include la creazione dell'applicazione, il deployment nell'ambiente di gestione temporanea e l'esecuzione di test per verificare che l'applicazione funzioni in gestione temporanea.
Il processo CI ha esito positivo quando le build e i test del codice vengono superati nell'ambiente di gestione temporanea. Il successo del processo CI avvia il sistema CD in Google Cloud Deploy.
Promuovi il lancio in produzione
In questa sezione promuovi la release dalla gestione temporanea alla produzione. Il target di produzione viene preconfigurato per richiedere l'approvazione, quindi lo devi approvare manualmente.
Per la tua pipeline CI/CD, potresti utilizzare una strategia di deployment che avvia il deployment gradualmente prima di eseguire un deployment completo in produzione. L'avvio graduale del deployment può agevolare il rilevamento di problemi e, se necessario, il ripristino di una release precedente.
Per promuovere la release in produzione:
Apri la panoramica delle pipeline di distribuzione di Google Cloud Deploy e seleziona la pipeline cicd-sample.
Promuovere il deployment, dalla gestione temporanea alla produzione. Ecco come fare:
Nel diagramma della pipeline nella parte superiore della pagina, fai clic sul pulsante blu Promuovi nella casella temporanea.
Nella finestra che si apre, fai clic sul pulsante Promuovi in basso.
Il deployment non è ancora in esecuzione in produzione. È in attesa dell'approvazione manuale richiesta.
Approva manualmente il deployment:
Nella visualizzazione della pipeline, fai clic sul pulsante Rivedi tra le caselle di gestione temporanea e di produzione.
Nella finestra che si apre, fai clic sul pulsante Rivedi.
Nella finestra successiva, fai clic su Approva.
Torna alla panoramica delle pipeline di distribuzione di Google Cloud Deploy e seleziona la pipeline cicd-sample.
Dopo che la visualizzazione della pipeline mostra la casella di produzione in verde (significa che un'implementazione è andata a buon fine), verifica che l'applicazione funzioni in produzione impostando un proxy kubectl che utilizzi per accedere all'applicazione:
kubectl proxy --port 8002 --context gke_$(gcloud config get-value project)_us-central1_prod
Accedi all'applicazione da Cloud Shell:
Nell'editor di Cloud Shell, apri una nuova scheda del terminale.
Aumenta il contatore:
curl -s http://localhost:8002/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter
Puoi eseguire questo comando più volte e osservare l'incremento del valore del contatore ogni volta.
Chiudi questa seconda scheda del terminale.
Nella prima scheda, premi
Control+C
per interrompere il proxy.
Ora hai promosso e approvato il deployment in produzione. L'applicazione con la tua modifica recente è ora in esecuzione in produzione.
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.
Opzione 1: 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.
Opzione 2: elimina le singole risorse
Elimina la pipeline di Google Cloud Deploy:
gcloud deploy delivery-pipelines delete cicd-sample --region=us-central1 --force
Elimina il trigger di Cloud Build:
gcloud beta builds triggers delete cicd-sample-main
Elimina i cluster di gestione temporanea e di produzione:
gcloud container clusters delete staging
gcloud container clusters delete prod
Elimina il repository in Cloud Source Repositories:
gcloud source repos delete cicd-sample
Elimina i bucket Cloud Storage:
gsutil rm -r gs://$(gcloud config get-value project)-gceme-artifacts/
gsutil rm -r gs://$(gcloud config get-value project)_clouddeploy/
Elimina il repository in Artifact Registry:
gcloud artifacts repositories delete cicd-sample-repo \ --location us-central1
Passaggi successivi
- Per informazioni su come eseguire il deployment in un'istanza GKE privata, consulta Deployment in un cluster privato su una rete Virtual Private Cloud.
- Per scoprire le best practice sull'automazione dei deployment, consulta:
- Tecnologia DevOps: automazione del deployment per implementare, migliorare e misurare l'automazione del deployment.
- Automatizzare i deployment dal framework dell'architettura.
- Per saperne di più sulle strategie di deployment, consulta:
- Avvia i deployment gradualmente dal framework dell'architettura.
- Strategie di deployment e test delle applicazioni
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Centro architettura cloud.