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

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

Questo documento fa parte di una serie:

Questo documento è destinato agli enterprise architect e agli sviluppatori di applicazioni, nonché ai team di sicurezza IT, DevOps e Site Reliability Engineering. Un po' di esperienza con gli strumenti e i processi di deployment automatizzati è utile per comprendere i concetti contenuti in questo documento.

Flusso di lavoro CI/CD

Per creare un sistema CI/CD moderno, devi prima scegliere strumenti e servizi che svolgano le funzioni principali del sistema. Questa architettura di riferimento è incentrata 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
    • Archivia il codice dell'applicazione e della configurazione.
    • Ti consente di rivedere le modifiche.
  • Per la gestione della configurazione delle applicazioni: kustomize
    • Definisce la configurazione prevista di un'applicazione.
    • Consente di riutilizzare ed estendere i progetti o le primitive di configurazione.
  • Per l'integrazione continua: Cloud Build
    • Testa e convalida il codice sorgente.
    • Crea gli artefatti utilizzati dall'ambiente di deployment.
  • Per la distribuzione continua: Cloud Deploy
    • Definisce il processo di implementazione del codice in più ambienti.
    • Fornisce il rollback per le modifiche non riuscite.
  • Per la configurazione dell'infrastruttura: Config Sync
    • Applica in modo coerente la configurazione del cluster e dei criteri.
  • Per l'applicazione dei criteri: Policy Controller
    • Fornisce un meccanismo che puoi utilizzare per definire quali dati possono essere eseguiti in un determinato ambiente in base ai criteri dell'organizzazione.
  • Per l'orchestrazione di container: Google Kubernetes Engine
    • Esegue gli artefatti creati durante la CI.
    • Offre metodologie di scalabilità, controllo di integrità e implementazione per i carichi di lavoro.
  • Per gli artefatti dei container: Artifact Registry
    • Archivia gli artefatti (immagini container) creati durante la CI.

Architettura

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

Per una discussione generale su questi aspetti del sistema CI/CD, consulta Modern CI/CD with GKE: A distribuzione del software Framework.

Varianti dell'architettura di riferimento

L'architettura di riferimento prevede due modelli di deployment:

  • Una variante multiprogetto che assomiglia di più a un deployment di produzione con limiti di isolamento migliorati
  • Una variante per un solo progetto, utile per le dimostrazioni.

Architettura di riferimento per più progetti

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

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

Per maggiori dettagli su come installare e applicare questa versione dell'architettura di riferimento, vedi il progetto base per la 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 singolo progetto Google Cloud. Questa versione può aiutare tutti gli utenti che non dispongono di ruoli IAM elevati a installare e provare l'architettura di riferimento con il solo ruolo di proprietario su un progetto. Questo documento illustra la versione dell'architettura di riferimento per un singolo progetto.

Infrastruttura della piattaforma

L'infrastruttura per questa architettura di riferimento è composta da cluster Kubernetes per supportare ambienti applicativi di sviluppo, gestione temporanea e 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 repository per operatori, sviluppatori, piattaforme e tecnici della sicurezza.

Il seguente diagramma mostra l'implementazione dell'architettura di riferimento dei diversi repository di codice e il modo in cui i team operativi, di sviluppo e di sicurezza interagiscono con i repository:

I repository includono quelli per le best practice e per 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 applicazioni nel repository degli operatori. Quando gli sviluppatori eseguono l'onboarding delle applicazioni nel repository di sviluppo, ottengono automaticamente le best practice, la logica di business dell'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 dell'applicazione

In questa architettura di riferimento, la zona di destinazione di un'applicazione viene creata al momento del provisioning dell'applicazione. Nel documento successivo di questa serie, CI/CD moderno con GKE: applica il flusso di lavoro per sviluppatori, eseguirai il provisioning di una nuova applicazione che crei 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 diverse applicazioni.

Ogni spazio dei nomi include un account di servizio che viene utilizzato per la federazione delle identità per i carichi di lavoro per GKE per accedere a servizi al di fuori del container Kubernetes, ad esempio 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 CD. Consigliamo ai team di seguire il principio del privilegio minimo per garantire che un account di servizio di esecuzione CD possa accedere solo agli spazi dei nomi richiesti.

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

Obiettivi

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

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. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

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

  1. Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  2. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  3. Nella console Google Cloud, attiva Cloud Shell.

    Attiva 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. C'è un file vuoto denominato vars.sh nella cartella software-delivery-bluprint/launch-scripts. 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 di GitHub.

    Sostituisci GITHUB_ORG con il nome dell'organizzazione GitHub.

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

    ./bootstrap.sh

    Lo script esegue il bootstrap della 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 alla pagina 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 Repositories.

Esplora i repository di base, operatore, configurazione e infrastruttura

I repository di base, operatore, configurazione e infrastruttura consentono agli operatori e agli amministratori della piattaforma di definire le best practice comuni per la creazione e il funzionamento della piattaforma. Questi repository vengono creati nella tua organizzazione GitHub quando viene eseguito il bootstrapping dell'architettura di riferimento.

Ogni repository nell'elenco include una breve descrizione.

Repository di base

I repository di base favoriscono l'adozione di best practice per CI/CD, infrastruttura e sviluppo su tutta la piattaforma. Per maggiori informazioni, consulta CI/CD moderni con GKE: un framework di distribuzione del software.

Repository di base per le applicazioni

Nei repository di applicazioni di base, gli operatori possono codificare e documentare best practice come CI/CD, raccolta di metriche, logging, passaggi dei container e sicurezza per le applicazioni. L'architettura di riferimento include esempi di repository di base per applicazioni Go, Python e Java.

I repository di comandi iniziali per le applicazioni 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 dell'applicazione. I repository di comandi iniziali per le applicazioni forniti dall'architettura di riferimento contengono:

  • kustomize base e patch nella cartella k8s.

  • Codice sorgente dell'applicazione.

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

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

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

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

Repository di partenza per l'infrastruttura

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

Repository di modelli condivisi

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

Repository operatori

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

  • Si tratta di modelli di base che contengono i file manifest Kubernetes di base per le applicazioni in esecuzione su Kubernetes. Gli operatori possono aggiornare i manifest nei modelli di base in base alle esigenze. Gli aggiornamenti vengono selezionati quando viene creata un'applicazione.
  • I file cloudbuild.yaml e skaffold.yaml in questi repository memorizzano le best practice per l'esecuzione di CI e CD rispettivamente sulla piattaforma. Analogamente alle configurazioni delle applicazioni, gli operatori possono aggiornare e aggiungere passaggi alle best practice. Le pipeline delle singole 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 base. Gli sviluppatori sono quindi liberi di estendere i manifest con modifiche specifiche dell'applicazione, come i nomi delle risorse e i 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'applicazione viene effettuata in più repository gestiti da team separati.

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

Per ulteriori informazioni sull'uso 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 configurazioni e criteri che utilizza Config Sync e Policy Controller. Il repository acm-gke-infrastructure-repo contiene la configurazione e i criteri di cui esegui il deployment nei cluster dell'ambiente applicativo. 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 operativi e di sviluppo.

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

Configurazione

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

Utilizzando Config Sync, la tua organizzazione può registrare i propri cluster per sincronizzare la configurazione da un repository Git, un processo noto come GitOps. Quando aggiungi nuovi cluster, questi vengono sincronizzati automaticamente con la configurazione più recente e riconciliano continuamente lo stato del cluster con la configurazione nel caso in cui qualcuno introduca modifiche fuori banda.

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

Norme

In questa implementazione di riferimento, utilizzerai Policy Controller, basato su Open Policy Agent, per intercettare e convalidare ogni richiesta ai cluster Kubernetes nella piattaforma. Puoi creare i criteri utilizzando il linguaggio dei criteri Rego, che ti consente di avere il controllo completo non solo dei tipi di risorse inviate al cluster, ma anche della loro configurazione.

L'architettura nel seguente diagramma mostra un flusso di richiesta 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 client API.

Creerai e definisci le regole nel repository Config Sync e queste modifiche verranno applicate al cluster. Dopodiché, le nuove richieste di risorse dai client API o dall'interfaccia a riga di comando vengono convalidate in base ai vincoli da Policy Controller.

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

Repository di infrastrutture

Nel riferimento è inclusa un'implementazione del repository dell'infrastruttura utilizzando Terraform. Il repository gke-infrastructure-repo contiene Infrastructure as Code per creare cluster GKE per ambienti di sviluppo, gestione temporanea e produzione e per configurarne Config Sync utilizzando il repository acm-gke-infrastructure-repo. gke-infrastructure-repo contiene tre rami, uno per ogni ambiente di sviluppo, gestione temporanea e produzione. Contiene inoltre le cartelle di sviluppo, gestione temporanea e produzione su 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 esplorerai la pipeline Infrastructure as Code e la eseguirai per creare l'infrastruttura condivisa, inclusi i cluster GKE. La pipeline è un trigger di Cloud Build denominato create-infra nel progetto Google Cloud collegato al repository dell'infrastruttura gke-infrastructure-repo. Segui la metodologia GitOps per creare l'infrastruttura, come spiegato nel video Ripetibili di ambienti Google Cloud su larga scala con Cloud Build Infra-As-Code Pipelines.

gke-infrastructure-repo ha rami di sviluppo, gestione temporanea e produzione. Nel repository sono presenti anche cartelle dev, gestione temporanea e produzione che corrispondono a questi rami. Nel repository sono presenti regole di protezione dei rami che assicurano che sia possibile eseguire il push del codice solo al ramo dev. Per eseguire il push del codice ai rami di gestione temporanea e produzione, devi creare una richiesta pull.

In genere, un utente 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 alle persone di provare il progetto, le regole di protezione dei rami sono state semplificate nell'architettura di riferimento, in modo che l'amministratore del repository possa ignorare la revisione e unire la richiesta di pull.

Quando viene eseguito un push su gke-infrastructure-repo, richiama il trigger create-infra. Questo trigger identifica il ramo in cui è stato eseguito il push e rimanda 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 inviato al ramo dev, il trigger esegue Terraform sulla cartella dev del ramo dev per creare un cluster GKE dev. Analogamente, quando viene eseguito un push al ramo staging, il trigger esegue Terraform sulla cartella temporanea del ramo di gestione temporanea per creare un cluster GKE di gestione temporanea.

Esegui la pipeline per creare i cluster GKE:

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

    Vai alla pagina di Cloud Build

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

  2. Fai clic sul nome del trigger. Si apre la definizione dell'attivatore.

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

    Gli altri trigger vengono utilizzati quando esegui l'onboarding di un'applicazione in CI/CD moderni con GKE: applica il flusso di lavoro degli sviluppatori

    Trigger di Cloud Build.

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

    Vai alla pagina della 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 dev del repository gke-infrastructure-repo che ha avviato questa pipeline e ha creato il cluster GKE di sviluppo.

  5. Per creare un cluster GKE di gestione temporanea, invia una richiesta di pull dal ramo dev al ramo di gestione temporanea:

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

    2. Fai clic su Richieste di pull, quindi su Nuova richiesta di pull.

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

    4. Fai clic su Crea richiesta di 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 della cronologia di Cloud Build.

    Vai alla pagina della cronologia di Cloud Build

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

  8. Per creare cluster GKE di produzione, invia un pull request dalla gestione temporanea al ramo di produzione:

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

    2. Fai clic su Richieste di pull, quindi su Nuova richiesta di pull.

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

    4. Fai clic su Crea richiesta di 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 della cronologia di Cloud Build.

    Vai alla pagina della cronologia di Cloud Build

    Nel progetto viene avviata una terza pipeline di 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 Cluster Kubernetes

    In questa pagina sono elencati i cluster utilizzati per lo sviluppo (gke-dev-us-central1), la gestione temporanea (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) offre agli sviluppatori l'accesso a uno spazio dei nomi che possono utilizzare per eseguire l'iterazione nelle loro applicazioni. Consigliamo ai team di utilizzare strumenti come Skaffold, che offrono 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 loop di iterazione è simile al ricaricamento rapido. Tuttavia, il loop non è specifico del linguaggio di programmazione, ma funziona con qualsiasi applicazione che puoi creare con un'immagine Docker. Puoi eseguire il loop all'interno di un cluster Kubernetes.

In alternativa, i tuoi sviluppatori possono seguire il loop CI/CD per un ambiente di sviluppo. Questo loop rende le modifiche al codice pronte per la promozione in ambienti superiori.

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

Cluster di gestione temporanea

Questo cluster esegue l'ambiente di gestione temporanea delle tue applicazioni. In questa architettura di riferimento creerai un cluster GKE per la gestione temporanea. In genere, un ambiente di gestione temporanea è 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 i sistemi di ridondanza geografica o ad alta disponibilità (HA), consigliamo di aggiungere più cluster a ogni ambiente. Per tutti i cluster in cui viene eseguito il deployment delle applicazioni, l'ideale è utilizzare i cluster regionali. Questo approccio isola le applicazioni da errori a livello di zona e da eventuali interruzioni causate dagli upgrade dei cluster o del 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 ulteriori informazioni su come gestire queste risorse, consulta Repository per configurazione e criteri.

Applicare l'architettura di riferimento

Ora che hai esplorato l'architettura di riferimento, puoi esplorare un flusso di lavoro degli sviluppatori basato su questa implementazione. Nel documento successivo di questa serie, CI/CD moderni con GKE: applica il flusso di lavoro degli sviluppatori, creerai una nuova applicazione, aggiungerai una funzionalità ed eseguirai il deployment dell'applicazione negli ambienti di gestione temporanea e produzione.

Esegui la pulizia

Se vuoi provare il prossimo documento di questa serie, CI/CD moderno con GKE: applicazione del flusso di lavoro degli sviluppatori, non eliminare il progetto o le risorse associati 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. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

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