CI/CD moderno con GKE: crea un sistema CI/CD

Questa architettura di riferimento fornisce un metodo e un'infrastruttura iniziale per creare un sistema di integrazione/distribuzione continua (CI/CD) moderno utilizzando strumenti come Google Kubernetes Engine, Cloud Build, Skaffold, kustomize, Config Sync, Policy Controller, Artifact Registry e Cloud Deploy.

Questo documento fa parte di una serie:

Questo documento è rivolto a Enterprise Architect e sviluppatori di applicazioni, nonché a team di sicurezza IT, DevOps e Site Reliability Engineering. Per comprendere i concetti di questo documento è utile avere qualche esperienza con gli strumenti e le procedure di deployment automatico.

Flusso di lavoro CI/CD

Per creare un sistema CI/CD moderno, devi prima scegliere gli strumenti e i servizi che svolgono le funzioni principali del sistema. Questa architettura di riferimento si concentra sull'implementazione delle funzioni di base di un sistema CI/CD mostrate nel seguente diagramma:

Vari team gestiscono o condividono la responsabilità del sistema CI/CD.

Questa implementazione di riferimento utilizza i seguenti strumenti per ogni componente:

  • Per la gestione del codice sorgente: GitHub
    • Memorizza il codice dell'applicazione e della configurazione.
    • Ti consente di esaminare le modifiche.
  • Per la gestione della configurazione delle applicazioni: kustomize
    • Definisce la configurazione prevista di un'applicazione.
    • Consente di riutilizzare ed estendere le primitive o i blueprint di configurazione.
  • Per l'integrazione continua: Cloud Build
    • Testa e convalida il codice sorgente.
    • Genera gli artefatti utilizzati dall'ambiente di deployment.
  • Per la distribuzione continua: Cloud Deploy
    • Definisce la procedura di implementazione del codice negli ambienti.
    • Consente il rollback delle modifiche non riuscite.
  • Per la configurazione dell'infrastruttura: Config Sync
    • Applica in modo coerente la configurazione del cluster e dei criteri.
  • Per l'applicazione delle norme: Policy Controller
    • Fornisce un meccanismo che puoi utilizzare per definire cosa è consentito eseguire in un determinato ambiente in base ai criteri dell'organizzazione.
  • Per l'orchestrazione dei container: Google Kubernetes Engine
    • Esegue gli elementi creati durante la CI.
    • Fornisce metodologie di scalabilità, controllo di integrità e implementazione per i carichi di lavoro.
  • Per gli elementi del contenitore: Artifact Registry
    • Memorizza gli elementi (immagini container) creati durante CI;integrazione continua.

Architettura

Questa sezione descrive i componenti CI/CD che implementi utilizzando questa architettura di riferimento: infrastruttura, pipeline, repository di codice e zone di destinazione.

Per una discussione generale di questi aspetti del sistema CI/CD, consulta CI/CD moderno con GKE: un framework di distribuzione del software.

Varianti dell'architettura di riferimento

L'architettura di riferimento ha due modelli di implementazione:

  • Una variante multi-project più simile a un deployment di produzione con limiti di isolamento migliorati
  • Una variante a progetto singolo, utile per le dimostrazioni

Architettura di riferimento per più progetti

La versione multi-project dell'architettura di riferimento simula scenari simili alla produzione. In questi scenari, utenti tipo diversi creano infrastrutture, pipeline CI/CD e applicazioni con confini di isolamento appropriati. Questi profili o team possono accedere solo alle risorse richieste.

Per ulteriori informazioni, consulta CI/CD moderno con GKE: un framework di distribuzione del software.

Per informazioni dettagliate su come installare e applicare questa versione dell'architettura di riferimento, consulta il blueprint di distribuzione del software.

Architettura di riferimento per un singolo progetto

La versione single-project dell'architettura di riferimento mostra come configurare l'intera piattaforma di distribuzione del software in un unico progetto Google Cloud. Questa versione può aiutare qualsiasi utente che non dispone di ruoli IAM elevati a installare e provare l'architettura di riferimento solo con il ruolo di proprietario in un progetto. Questo documento mostra la versione a progetto singolo dell'architettura di riferimento.

Infrastruttura della piattaforma

L'infrastruttura per questa architettura di riferimento è costituita da cluster Kubernetes per supportare gli ambienti di applicazione di sviluppo, di staging e di produzione. Il seguente diagramma mostra il layout logico dei cluster:

Il layout del cluster supporta diversi carichi di lavoro della piattaforma.

Repository di codice

Utilizzando questa architettura di riferimento, puoi configurare i repository per operatori, sviluppatori, tecnici della piattaforma e della sicurezza.

Il seguente diagramma mostra l'implementazione dell'architettura di riferimento dei diversi repository di codice e come i team di operazioni, sviluppo e sicurezza interagiscono con i repository:

I repository includono quelli per le best practice, nonché la configurazione di applicazioni e piattaforme.

In questo flusso di lavoro, gli operatori possono gestire le best practice per la configurazione di CI/CD e delle applicazioni nel repository dell'operatore. Quando gli sviluppatori caricano le applicazioni nel repository di sviluppo, ottengono automaticamente le best practice, la logica di business per l'applicazione e qualsiasi configurazione specializzata necessaria per il corretto funzionamento dell'applicazione. Nel frattempo, il team operativo e di sicurezza può gestire la coerenza e la sicurezza della piattaforma nei repository di configurazione e criteri.

Zone di destinazione delle applicazioni

In questa architettura di riferimento, la landing zone di un'applicazione viene creata quando viene eseguito il provisioning dell'applicazione. Nel documento successivo di questa serie, CI/CD moderno con GKE: applicazione del flusso di lavoro degli sviluppatori, esegui il provisioning di una nuova applicazione che crea la propria zona di destinazione. Il seguente diagramma illustra i componenti importanti delle zone di destinazione utilizzate in questa architettura di riferimento:

Il cluster GKE include tre spazi dei nomi per applicazioni diverse.

Ogni spazio dei nomi include un account di servizio utilizzato per la federazione delle identità di carico di lavoro per consentire a GKE di accedere ai servizi esterni al contenitore Kubernetes, come Cloud Storage o Spanner. Lo spazio dei nomi include anche altre risorse, come i criteri di rete, per isolare o condividere i confini con altri spazi dei nomi o applicazioni.

Lo spazio dei nomi viene creato dall'account di servizio di esecuzione del CD. Consigliamo ai team di seguire il principio del privilegio minimo per assicurarsi che un account di servizio di esecuzione del CD possa accedere solo ai namespace richiesti.

Puoi definire l'accesso all'account di servizio in Config Sync e implementarlo utilizzando i ruoli e le associazioni di ruoli controllo dell'accesso basato su ruoli (RBAC) di Kubernetes. Con questo modello, i team possono eseguire il deployment di qualsiasi risorsa direttamente negli spazi dei nomi che gestiscono, ma non possono sovrascrivere o eliminare le risorse di altri spazi dei nomi.

Obiettivi

  • Esegui il deployment dell'architettura di riferimento per un singolo progetto.
  • Esplora i repository di codice.
  • Esplora la pipeline e l'infrastruttura.

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. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Al termine delle attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.

Prima di iniziare

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

    Go to project selector

  2. Make sure that billing is enabled for your Google Cloud project.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

Esegui il deployment dell'architettura di riferimento

  1. In Cloud Shell, imposta il progetto:

    gcloud config set core/project PROJECT_ID

    Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.

  2. In Cloud Shell, clona il repository Git:

    git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git
cd software-delivery-blueprint/launch-scripts
git checkout single-project-blueprint

  3. Crea un token di accesso personale in GitHub con i seguenti ambiti:

    • repo
    • delete_repo
    • admin:org
    • admin:repo_hook

  4. Nella cartella software-delivery-bluprint/launch-scripts è presente un file vuoto denominato vars.sh. Aggiungi i seguenti contenuti al file: 

    cat << EOF >vars.sh
export INFRA_SETUP_REPO="gke-infrastructure-repo"
export APP_SETUP_REPO="application-factory-repo"
export GITHUB_USER=GITHUB_USER
export TOKEN=TOKEN
export GITHUB_ORG=GITHUB_ORG
export REGION="us-central1"
export SEC_REGION="us-west1"
export TRIGGER_TYPE="webhook"
EOF

    Sostituisci GITHUB_USER con il nome utente GitHub.

    Sostituisci TOKEN con il token di accesso personale GitHub.

    Sostituisci GITHUB_ORG con il nome dell'organizzazione GitHub.

  5. Esegui lo script bootstrap.sh. Se Cloud Shell ti chiede l'autorizzazione, fai clic su Autorizza:

    ./bootstrap.sh

    Lo script avvia la piattaforma di distribuzione del software.

Esplora i repository di codice

In questa sezione esplorerai i repository di codice.

Accedi a GitHub

  1. In un browser web, vai all'indirizzo github.com e accedi al tuo account.
  2. Fai clic sull'icona dell'immagine nella parte superiore dell'interfaccia.
  3. Fai clic su Le tue organizzazioni.
  4. Scegli l'organizzazione che hai fornito come input nel file vars.sh.
  5. Fai clic sulla scheda Repositoi.

Esplora i repository di comandi iniziali, operatori, configurazione e infrastruttura

I repository di comandi iniziali, operatori, configurazione e infrastruttura sono i luoghi in cui gli operatori e gli amministratori della piattaforma definiscono le best practice comuni per la creazione e il funzionamento della piattaforma. Questi repository vengono creati nella tua organizzazione GitHub quando viene eseguito il bootstrap dell'architettura di riferimento.

Ogni repository nell&#39;elenco include una breve descrizione.

Repository di partenza

I repository iniziali favoriscono l'adozione di best practice di CI/CD, infrastruttura e sviluppo sulla piattaforma. Per ulteriori informazioni, consulta CI/CD moderno con GKE: un framework di distribuzione del software

Repository di app di avvio

Nei repository di comandi iniziali dell'applicazione, gli operatori possono codificare e documentare le best practice come CI/CD, raccolta delle metriche, logging, passaggi dei container e sicurezza per le applicazioni. Nell'architettura di riferimento sono inclusi esempi di repository iniziali per applicazioni Go, Python e Java.

I repository di app iniziali app-template-python, app-template-java e app-template-golang contengono codice boilerplate che puoi utilizzare per creare nuove applicazioni. Oltre a creare nuove applicazioni, puoi creare nuovi modelli in base ai requisiti delle applicazioni. I repository di partenza dell'applicazione forniti dall'architettura di riferimento contengono:

  • kustomize di base e i patch nella cartella k8s.

  • Codice sorgente dell'applicazione.

  • Un Dockerfile che descrive come compilare ed eseguire l'applicazione.

  • Un file cloudbuild.yaml che descrive le best practice per i passaggi di CI.

  • Un file skaffold.yaml che descrive i passaggi di deployment.

Nel documento successivo di questa serie, CI/CD moderno con GKE: applica il flusso di lavoro degli sviluppatori, utilizzerai il repository app-template-python per creare una nuova applicazione.

Repository di inizio dell'infrastruttura

Nei repository di partenza dell'infrastruttura, gli operatori e gli amministratori dell'infrastruttura possono codificare e documentare le best practice, ad esempio pipeline CI/CD, IaC, raccolta delle metriche, logging e sicurezza per l'infrastruttura. Nell'architettura di riferimento sono inclusi esempi di repository di inizio dell'infrastruttura che utilizzano Terraform. Il repository di partenza dell'infrastruttura infra-template contiene codice boilerplate per Terraform che puoi utilizzare per creare le risorse di infrastruttura richieste da un'applicazione, come il bucket Cloud Storage, il database Spanner e altri.

Repository di modelli condivisi

Nei repository di modelli condivisi, gli amministratori e gli operatori dell'infrastruttura forniscono modelli standard per eseguire attività. L'architettura di riferimento fornisce un repository denominato terraform-modules. Il repository include codice Terraform basato su modelli per creare varie risorse di infrastruttura.

Repository di operatori

Nell'architettura di riferimento, i repository dell'operatore sono gli stessi dei repository di avvio dell'applicazione. Gli operatori gestiscono i file richiesti sia per la CI che per la CD nei repository di avvio dell'applicazione. L'architettura di riferimento include i repository app-template-python, app-template-java e app-template-golang.

  • Si tratta di modelli di partenza e contengono i manifest Kubernetes di base per le applicazioni in esecuzione in Kubernetes sulla piattaforma. Gli operatori possono aggiornare i manifest nei modelli di partenza in base alle esigenze. Gli aggiornamenti vengono rilevati quando viene creata un'applicazione.
  • I file cloudbuild.yaml e skaffold.yaml in questi repository memorizzano le best practice per l'esecuzione rispettivamente di CI e CD sulla piattaforma. Come per le configurazioni delle applicazioni, gli operatori possono aggiornare e aggiungere passaggi alle best practice. Le singole pipeline di applicazioni vengono create utilizzando i passaggi più recenti.

In questa implementazione di riferimento, gli operatori utilizzano kustomize per gestire le configurazioni di base nella cartella k8s dei repository di partenza. Gli sviluppatori sono quindi liberi di estendere i manifest con modifiche specifiche per l'applicazione, come nomi di risorse e file di configurazione. Lo strumento kustomize supporta la configurazione come dati. Con questa metodologia, gli input e gli output di kustomize sono risorse Kubernetes. Puoi utilizzare gli output di una modifica dei manifest per un'altra modifica.

Il seguente diagramma illustra una configurazione di base per un'applicazione Spring Boot:

La configurazione dell&#39;applicazione viene eseguita in più repository gestiti da team separati.

La configurazione come modello dei dati in kustomize presenta un vantaggio importante: quando gli operatori aggiornano la configurazione di base, gli aggiornamenti vengono utilizzati automaticamente dalla pipeline di deployment dello sviluppatore alla successiva esecuzione senza alcuna modifica da parte dello sviluppatore.

Per ulteriori informazioni sull'utilizzo di kustomize per gestire i manifest di Kubernetes, consulta la documentazione di kustomize.

Repository di configurazione e criteri

Nell'architettura di riferimento è inclusa un'implementazione di un repository di configurazione e criteri che utilizza Config Sync e Policy Controller. Il repository acm-gke-infrastructure-repo contiene la configurazione e i criteri che esegui il deployment nei cluster dell'ambiente dell'applicazione. La configurazione definita e archiviata dagli amministratori della piattaforma in questi repository è importante per garantire che la piattaforma abbia un aspetto coerente per i team di operazioni e sviluppo.

Le sezioni seguenti descrivono in modo più dettagliato come l'architettura di riferimento implementa i repository di configurazione e criteri.

Configurazione

In questa implementazione di riferimento, utilizzi Config Sync per gestire centralmente la configurazione dei cluster nella piattaforma e applicare le norme. La gestione centralizzata consente di propagare le modifiche alla configurazione in tutto il sistema.

Con Config Sync, la tua organizzazione può registrare i propri cluster per sincronizzarne la configurazione da un repository Git, un processo noto come GitOps. Quando aggiungi nuovi cluster, questi si sincronizzano automaticamente con l'ultima configurazione e riconciliano continuamente lo stato del cluster con la configurazione nel caso in cui qualcuno introduca modifiche out-of-band.

Per ulteriori informazioni su Config Sync, consulta la relativa documentazione.

Norme

In questa implementazione di riferimento, utilizzi Policy Controller, che si basa su Open Policy Agent, per intercettare e convalidare ogni richiesta ai cluster Kubernetes della piattaforma. Puoi creare criteri utilizzando il linguaggio dei criteri Rego, che ti consente di controllare completamente non solo i tipi di risorse inviate al cluster, ma anche la loro configurazione.

L'architettura nel seguente diagramma mostra un flusso di richieste per l'utilizzo di Policy Controller per creare una risorsa:

Una regola del criterio viene prima definita e poi applicata utilizzando vari strumenti come kubectl e i client API.

Creando e definendo regole nel repository Config Sync, le modifiche vengono applicate al cluster. Successivamente, le nuove richieste di risorse da parte dei client CLI o API vengono convalidate in base ai vincoli dal Controller dei criteri.

Per ulteriori informazioni sulla gestione dei criteri, consulta la panoramica di Policy Controller.

Repository di infrastruttura

Il riferimento include un'implementazione del repository di infrastruttura che utilizza Terraform. Il repository gke-infrastructure-repo contiene l'infrastruttura as code per creare cluster GKE per gli ambienti di sviluppo, di gestione temporanea e di produzione e configurare Config Sync su di essi utilizzando il repository gke-infrastructure-repo.acm-gke-infrastructure-repo gke-infrastructure-repo contiene tre branch, uno per ogni ambiente di sviluppo, gestione temporanea e produzione. Contiene inoltre cartelle di sviluppo, gestione temporanea e produzione in ogni ramo.

Esplora la pipeline e l'infrastruttura

L'architettura di riferimento crea una pipeline nel progetto Google Cloud. Questa pipeline è responsabile della creazione dell'infrastruttura condivisa.

Pipeline

In questa sezione esplori la pipeline di Infrastructure as Code ed eseguila per creare l'infrastruttura condivisa, inclusi i cluster GKE. La pipeline è un trigger Cloud Build denominato create-infra nel progetto Google Cloud collegato al repository di infrastruttura gke-infrastructure-repo. Segui la metodologia GitOps per creare l'infrastruttura come spiegato nel video Repeatable GCP Environments at Scale With Cloud Build Infra-As-Code Pipelines.

gke-infrastructure-repo ha branch di sviluppo, gestione temporanea e produzione. Nel repository sono presenti anche le cartelle dev, staging e production che corrispondono a questi branch. Nel repository sono presenti regole di protezione dei rami che assicurano che il codice possa essere eseguito push solo nel ramo di sviluppo. Per eseguire il push del codice nei branch di staging e di produzione, devi creare una richiesta di pull.

In genere, una persona che ha accesso al repository esamina le modifiche e poi unisce la richiesta di pull per assicurarsi che solo le modifiche previste vengano promosse al ramo superiore. Per consentire ai singoli di provare il blueprint, le regole di protezione dei rami sono state allentate nell'architettura di riferimento in modo che l'amministratore del repository possa bypassare la revisione e unire la richiesta di pull.

Quando viene eseguito un push in gke-infrastructure-repo, viene invocato l'attivatore create-infra. L'attivatore identifica il ramo in cui è avvenuto il push e passa alla cartella corrispondente nel repository su quel ramo. Una volta trovata la cartella corrispondente, esegue Terraform utilizzando i file contenuti nella cartella. Ad esempio, se il codice viene eseguito nel ramo di sviluppo, l'attivatore esegue Terraform nella cartella dev del ramo di sviluppo per creare un cluster GKE di sviluppo. Analogamente, quando viene eseguito un push nel ramo staging, l'attivatore esegue Terraform nella cartella di staging del ramo di staging per creare un cluster GKE di staging.

Esegui la pipeline per creare i cluster GKE:

  1. Nella console Google Cloud, vai alla pagina Cloud Build.

    Vai alla pagina Cloud Build

    • Esistono cinque trigger webhook di Cloud Build. Cerca l'attivatore con il nome create-infra. Questo trigger crea l'infrastruttura condivisa, inclusi i cluster GKE.

  2. Fai clic sul nome dell'attivatore. Viene visualizzata la definizione dell'attivatore.

  3. Fai clic su APRI EDITOR per visualizzare i passaggi eseguiti dall'attivatore.

    Gli altri attivatori vengono utilizzati quando esegui l'onboarding di un'applicazione in CI/CD moderno con GKE: applicazione del flusso di lavoro degli sviluppatori

    Trigger di Cloud Build.

  4. Nella console Google Cloud, vai alla pagina Cloud Build.

    Vai alla pagina Cronologia di Cloud Build

    Esamina la pipeline presente nella pagina della cronologia. Quando hai eseguito il deployment della piattaforma di distribuzione del software utilizzando bootstrap.sh, lo script ha eseguito il push del codice nel ramo di sviluppo del repository gke-infrastructure-repo che ha avviato questa pipeline e creato il cluster GKE di sviluppo.

  5. Per creare un cluster GKE di staging, invia una richiesta pull dal ramo di sviluppo al ramo di staging:

    1. Vai su GitHub e vai al repository gke-infrastructure-repo.

    2. Fai clic su Pull request e poi su Nuova pull request.

    3. Nel menu Base, scegli staging e nel menu Confronta, scegli dev.

    4. Fai clic su Crea richiesta pull.

  6. Se sei un amministratore del repository, unisci la richiesta di pull. In caso contrario, chiedi all'amministratore di unire la richiesta di pull.

  7. Nella console Google Cloud, vai alla pagina Cronologia di Cloud Build.

    Vai alla pagina Cronologia di Cloud Build

    Nel progetto viene avviata una seconda pipeline Cloud Build. Questa pipeline crea il cluster GKE di staging.

  8. Per creare cluster GKE di produzione, invia un pull request dal ramo di staging a quello di produzione:

    1. Vai su GitHub e vai al repository gke-infrastructure-repo.

    2. Fai clic su Pull request e poi su Nuova pull request.

    3. Nel menu Base, scegli prod e nel menu Confronta, scegli staging.

    4. Fai clic su Crea richiesta pull.

  9. Se sei un amministratore del repository, unisci la richiesta di pull. In caso contrario, chiedi all'amministratore di unire la richiesta di pull.

  10. Nella console Google Cloud, vai alla pagina Cronologia di Cloud Build.

    Vai alla pagina Cronologia di Cloud Build

    Nel progetto viene avviata una terza pipeline Cloud Build. Questa pipeline crea il cluster GKE di produzione.

Infrastruttura

In questa sezione esplorerai l'infrastruttura creata dalle pipeline.

  • Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

    Vai alla pagina dei cluster Kubernetes

    Questa pagina elenca i cluster utilizzati per lo sviluppo (gke-dev-us-central1), l'implementazione (gke-staging-us-central1) e la produzione ( gke-prod-us-central1, gke-prod-us-west1):

    I dettagli dei cluster includono posizione, dimensione del cluster e core totali.

Cluster di sviluppo

Il cluster di sviluppo (gke-dev-us-central1) consente agli sviluppatori di accedere a un spazio dei nomi che possono utilizzare per eseguire l'iterazione sulle loro applicazioni. Consigliamo ai team di utilizzare strumenti come Skaffold che forniscono un flusso di lavoro iterativo monitorando attivamente il codice in fase di sviluppo e riapplicandolo agli ambienti di sviluppo man mano che vengono apportate modifiche. Questo ciclo di iterazione è simile al ricaricamento a caldo. Tuttavia, anziché essere specifico per un linguaggio di programmazione, il loop funziona con qualsiasi applicazione che puoi creare con un'immagine Docker. Puoi eseguire il loop all'interno di un cluster Kubernetes.

In alternativa, gli sviluppatori possono seguire il ciclo CI/CD per un ambiente di sviluppo. Questo ciclo rende le modifiche al codice pronte per la promozione agli ambienti di livello superiore.

Nel prossimo documento di questa serie, CI/CD moderno con GKE: applica il flusso di lavoro degli sviluppatori, utilizzerai sia Skaffold che CI/CD per creare il ciclo di sviluppo.

Cluster di staging

Questo cluster esegue l'ambiente di staging delle tue applicazioni. In questa architettura di riferimento, crei un cluster GKE per l'implementazione. In genere, un ambiente di staging è una replica esatta dell'ambiente di produzione.

Cluster di produzione

Nell'architettura di riferimento sono presenti due cluster GKE per gli ambienti di produzione. Per la ridondanza geografica o i sistemi ad alta disponibilità (HA), ti consigliamo di aggiungere più cluster a ogni ambiente. Per tutti i cluster in cui vengono implementate le applicazioni, è ideale utilizzare cluster regionali. Questo approccio isola le applicazioni da errori a livello di zona e da eventuali interruzioni causate dagli upgrade dei cluster o dei pool di nodi.

Per sincronizzare la configurazione delle risorse del cluster, come spazi dei nomi, quote e RBAC, ti consigliamo di utilizzare Config Sync. Per maggiori informazioni su come gestire queste risorse, consulta Repository di configurazione e criteri.

Applica l'architettura di riferimento

Ora che hai esplorato l'architettura di riferimento, puoi esplorare un flusso di lavoro per gli sviluppatori basato su questa implementazione. Nel prossimo documento di questa serie, CI/CD moderno con GKE: applicazione del flusso di lavoro degli sviluppatori, creerai una nuova applicazione, aggiungerai una funzionalità e ne eseguirai il deployment negli ambienti di staging e di produzione.

Esegui la pulizia

Se vuoi provare il documento successivo di questa serie, CI/CD moderna con GKE: applicazione del flusso di lavoro dello sviluppatore, non eliminare il progetto o le risorse associate a questa architettura di riferimento. In caso contrario, per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate nell'architettura di riferimento, puoi eliminare il progetto o rimuovere manualmente le risorse.

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.

Rimuovi manualmente le risorse

  • In Cloud Shell, rimuovi l'infrastruttura:

      gcloud container clusters delete gke-dev-us-central1
  gcloud container clusters delete gke-staging-us-central1
  gcloud container clusters delete gke-prod-us-central1
  gcloud container clusters delete gke-prod-us-west1
  gcloud beta builds triggers delete create-infra
  gcloud beta builds triggers delete add-team-files
  gcloud beta builds triggers delete create-app
  gcloud beta builds triggers delete tf-plan
  gcloud beta builds triggers delete tf-apply

Passaggi successivi