Questa architettura di riferimento fornisce un metodo e
infrastruttura per creare una moderna integrazione e distribuzione continua
(CI/CD) con 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:
- CI/CD moderna con GKE: un framework di distribuzione del software
- CI/CD moderno con GKE: crea un sistema CI/CD (questo documento)
- Approccio CI/CD moderno con GKE: applica il flusso di lavoro per sviluppatori
Questo documento è rivolto agli architetti aziendali e agli sviluppatori di applicazioni, nonché i team dedicati a sicurezza IT, DevOps e Site Reliability Engineering. Alcune con gli strumenti e i processi di deployment automatizzati è utile i concetti esposti in questo documento.
Flusso di lavoro CI/CD
Per creare un sistema CI/CD moderno, devi prima scegliere strumenti e servizi che svolgono le funzioni principali del sistema. Questa architettura di riferimento si concentra sull'implementazione delle funzioni principali di un sistema CI/CD mostrate in il seguente diagramma:
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 le primitive o i progetti di configurazione.
- Per l'integrazione continua: Cloud Build
- Testa e convalida il codice sorgente.
- Crea artefatti utilizzati dall'ambiente di deployment.
- Per la distribuzione continua: Cloud Deploy
- Definisce il processo di implementazione del codice nei vari 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 cosa può essere eseguito in un determinato ambiente in base ai criteri dell'organizzazione.
- Per l'orchestrazione dei container: Google Kubernetes Engine
- Esegue gli artefatti creati durante la CI.
- Fornisce metodologie di scalabilità, controllo di integrità e implementazione per carichi di lavoro con scale out impegnativi.
- 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 questo architettura di riferimento: infrastruttura, pipeline, repository di codice e zone di destinazione.
Per una discussione generale su questi aspetti del sistema CI/CD, vedi CI/CD moderno con GKE: un framework di distribuzione del software.
Varianti dell'architettura di riferimento
L'architettura di riferimento prevede due modelli di deployment:
- Una variante multi-progetto che è più simile a un deployment di produzione con limiti di isolamento migliorati
- Una variante per un singolo progetto, utile per le dimostrazioni
Architettura di riferimento multiprogetto
La versione multi-project
dell'architettura di riferimento simula scenari di tipo produzione. In questi scenari, diversi utenti tipo creano infrastrutture, pipeline CI/CD e applicazioni con limiti di isolamento adeguati. Questi utenti tipo o team possono accedere solo alle risorse richieste.
Per ulteriori informazioni, vedi 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, consulta il progetto 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 singolo progetto Google Cloud. Questa versione può aiutare tutti gli utenti che non hanno ruoli IAM elevati a installare e provare l'architettura di riferimento solo con il ruolo di proprietario su un progetto. Questo documento illustra la versione dell'architettura di riferimento con un singolo progetto.
Infrastruttura della piattaforma
L'infrastruttura di questa architettura di riferimento è composta da per supportare gli ambienti applicativi di sviluppo, gestione temporanea e produzione. Il seguente diagramma mostra il layout logico dei cluster:
Repository di codice
Utilizzando questa architettura di riferimento, configuri i repository per operatori, sviluppatori, tecnici della piattaforma e della sicurezza.
Il seguente diagramma mostra l'implementazione dell'architettura di riferimento del da diversi repository di codice e il modo in cui operazioni, i team interagiscono con i repository:
In questo flusso di lavoro, gli operatori possono gestire le best practice per CI/CD e alla configurazione dell'applicazione nel repository degli operatori. Quando i tuoi sviluppatori per l'integrazione delle applicazioni nel repository di sviluppo, ottengono automaticamente pratiche, la logica di business per l'applicazione e qualsiasi configurazione specializzata necessarie affinché l'applicazione funzioni correttamente. Nel frattempo, le tue operazioni e il team addetto alla sicurezza possono gestire la coerenza e la sicurezza della piattaforma di configurazione e criteri.
Zone di destinazione dell'applicazione
In questa architettura di riferimento, la zona di destinazione di un'applicazione viene creata quando viene eseguito il provisioning dell'applicazione. Nel prossimo documento serie, Approccio CI/CD moderno con GKE: applica il flusso di lavoro per 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 utilizzati in questa architettura di riferimento:
Ogni spazio dei nomi include un account di servizio che viene utilizzato per la federazione delle identità per i carichi di lavoro per GKE al fine di accedere a servizi al di fuori del container 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 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 agli account di servizio configurare Config Sync e implementarlo utilizzando il modello basato sui ruoli di Kubernetes i ruoli di controllo dell'accesso (RBAC) e le associazioni di ruoli. Con questo modello applicato, i team eseguire il deployment delle risorse direttamente negli spazi dei nomi che gestiscono, ma impossibile sovrascrivere o eliminare 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 vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
- Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Enterprise edition for Config Sync and Policy Controller
- Cloud Build
- Artifact Registry
- Cloud Deploy
Per generare una stima dei costi basata sull'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
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
In the Google Cloud console, activate Cloud Shell.
Esegui il deployment dell'architettura di riferimento
In Cloud Shell, imposta il progetto:
gcloud config set core/project PROJECT_ID
Sostituisci
PROJECT_ID
con l'ID del tuo progetto Google Cloud.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
Crea un token di accesso personale in GitHub con i seguenti ambiti:
repo
delete_repo
admin:org
admin:repo_hook
C'è un file vuoto denominato
vars.sh
nella cartellasoftware-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 GitHub.Sostituisci
GITHUB_ORG
con il nome dell'organizzazione GitHub.Esegui lo script
bootstrap.sh
. Se Cloud Shell ti chiede l'autorizzazione, fai clic su Autorizza:./bootstrap.sh
Lo script avvia il bootstrap della piattaforma di distribuzione del software.
Esplora i repository di codice
In questa sezione esplorerai i repository di codice.
Accedi a GitHub
- In un browser web, vai su github.com. e accedi al tuo account.
- Fai clic sull'icona dell'immagine nella parte superiore dell'interfaccia.
- Fai clic su Le tue organizzazioni.
- Scegli l'organizzazione che hai fornito come input nel file
vars.sh
. - Fai clic sulla scheda Repository.
Esplora i repository di base, operatore, configurazione e infrastruttura
I repository di base, operatore, configurazione e infrastruttura sono i punti in cui gli operatori gli amministratori di piattaforma definiscono le best practice comuni per lo sviluppo la gestione della piattaforma. Questi repository vengono creati nella tua organizzazione GitHub quando viene eseguito il bootstrap dell'architettura di riferimento.
Repository di avvio
I repository di base favoriscono l'adozione di best practice per CI/CD, infrastruttura e sviluppo su tutta la piattaforma. Per saperne di più, consulta CI/CD moderno con GKE: un framework di distribuzione del software
Repository di base delle applicazioni
Nei repository di base dell'applicazione, i tuoi operatori possono codificare e documentare al meglio come CI/CD, raccolta delle metriche, logging, passaggi del container e sicurezza per diverse applicazioni. L'architettura di riferimento include esempi di repository di base per Applicazioni Go, Python e Java.
app-template-python
, app-template-java
e
app-template-golang
repository di avvio dell'applicazione 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 starter dell'applicazione forniti dall'architettura di riferimento contengono:
kustomize
di base e patch nella cartellak8s
.Codice sorgente dell'applicazione.
Un
Dockerfile
che descriva come creare 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 del deployment.
Nel prossimo documento di questa serie,
Approccio CI/CD moderno con GKE: applica il flusso di lavoro per sviluppatori,
utilizzerai il repository app-template-python
per creare
nuova applicazione.
Repository di base dell'infrastruttura
Nei repository di base dell'infrastruttura, gli operatori e gli amministratori dell'infrastruttura possono codificare e documentare al meglio
come pipeline CI/CD, IaC, raccolta di metriche, logging e sicurezza
dell'infrastruttura. L'architettura di riferimento include esempi di repository di base dell'infrastruttura che utilizzano Terraform. Il repository iniziale 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 altro.
Repository di modelli condivisi
Nei repository di modelli condivisi, gli amministratori e gli operatori dell'infrastruttura forniscono modelli standard per eseguire le attività. È stato fornito un repository denominato terraform-modules
con l'architettura di riferimento. Il repository include codice Terraform basato su modelli per creare varie risorse dell'infrastruttura.
Repository operatori
Nell'architettura di riferimento, i repository degli operatori sono gli stessi dei repository di avvio dell'applicazione. Gli operatori gestiscono i file richiesti sia per CI che per CD nei repository di avvio dell'applicazione.
L'architettura di riferimento include app-template-python
, app-template-java
e
app-template-golang
repository.
- Si tratta di modelli di base che contengono gli elementi Kubernetes di base per le applicazioni in esecuzione in Kubernetes sulla piattaforma. Gli operatori possono aggiornare i manifest nei modelli di base in base alle esigenze. Gli aggiornamenti vengono raccolti al momento della creazione di un'applicazione.
- I file
cloudbuild.yaml
eskaffold.yaml
in questi repository memorizzano le best practice per l'esecuzione rispettivamente di CI e CD sulla piattaforma. Analogamente alle configurazioni dell'applicazione, gli operatori possono aggiornare e aggiungere passaggi alle best practice. Individuale le pipeline dell'applicazione 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 file manifest con applicazioni
modifiche, ad esempio nomi delle risorse e file di configurazione. Lo strumento kustomize
supporta la configurazione come dati. Con questo
gli input e gli output di kustomize
sono risorse Kubernetes. Puoi
utilizza gli output di una modifica dei manifest per un'altra modifica.
Il seguente diagramma illustra una configurazione di base per un avvio a molla applicazione:
La configurazione come modello dei dati in kustomize
offre un grande vantaggio: quando
operatori aggiornano la configurazione di base, gli aggiornamenti vengono utilizzati automaticamente
dalla pipeline di deployment dello sviluppatore nella sua successiva esecuzione senza alcuna modifica
lato sviluppatore.
Per saperne di più sull'utilizzo di kustomize
per gestire i manifest di Kubernetes,
vedi il
Documentazione relativa a kustomize
.
Repository di criteri e configurazione
L'architettura di riferimento include l'implementazione di una configurazione e di un criterio
che utilizza Config Sync e Policy Controller. La
Il repository acm-gke-infrastructure-repo
contiene la configurazione e i criteri
di cui esegui il deployment nei cluster dell'ambiente applicativo. La configurazione
definiti e archiviati dagli amministratori della piattaforma
in questi repository è importante
garantendo che la piattaforma abbia un aspetto e un design coerenti per le operazioni
team di sviluppo.
Le seguenti sezioni descrivono l'implementazione dell'architettura di riferimento alla configurazione e ai repository di criteri in modo più dettagliato.
Configurazione
In questa implementazione di riferimento, utilizzi Configurazione Sync per gestire centralmente la configurazione dei cluster nella piattaforma e applicare criteri. La gestione centralizzata consente di propagare le modifiche alla configurazione in tutto il sistema.
Con Config Sync, l'organizzazione può registrare i propri cluster da cui sincronizzare la configurazione un repository Git, un processo noto come GitOps. Quando aggiungi nuovi cluster, sincronizzarsi automaticamente con la configurazione più recente e riconciliare continuamente stato del cluster con la configurazione nel caso in cui qualcuno introduca modifiche fuori banda.
Per saperne di più su Config Sync, consulta le relative documentazione.
Norme
In questa implementazione di riferimento viene utilizzato Policy Controller, che si basa su Open Policy Agent per intercettare e convalidare ogni richiesta inviata ai cluster Kubernetes completamente gestita. Puoi creare criteri utilizzando Linguaggio delle norme di recupero, che ti consente di controllare completamente non solo i tipi di risorse inviate ma anche la loro configurazione.
L'architettura nel seguente diagramma mostra un flusso di richiesta per l'utilizzo Policy Controller per creare una risorsa:
Puoi creare e definire le regole nel repository Config Sync, e queste modifiche vengono applicate al cluster. Dopodiché, le nuove richieste di risorse dal client dell'interfaccia a riga di comando o dell'API vengono convalidati in base ai vincoli Policy Controller.
Per ulteriori informazioni sulla gestione dei criteri, consulta Panoramica di Policy Controller.
Repository di infrastruttura
Il riferimento include un'implementazione dell'infrastruttura
utilizzando Terraform. Il repository gke-infrastructure-repo
contiene Infrastructure as Code per creare cluster GKE per gli ambienti di sviluppo, gestione temporanea e produzione e configurare 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 anche 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 Ambienti Google Cloud ripetibili su larga scala con pipeline Infra-As-Code di Cloud Build.
gke-infrastructure-repo
include i rami di sviluppo, gestione temporanea e produzione. Nel repository ci sono anche cartelle di sviluppo, gestione temporanea e produzione che corrispondono a questi rami. Nel repository esistono 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 di pull.
In genere, un utente che ha accesso al repository esamina le modifiche e quindi unisce la richiesta di pull per assicurarsi che solo le modifiche previste vengano promosse nel ramo di livello superiore. Per consentire ai singoli utenti di provare il progetto base, le regole di protezione dei rami sono state semplificate nell'architettura di riferimento, in modo che l'amministratore del repository sia in grado di ignorare la revisione e unire la richiesta di pull.
Quando viene effettuato un push a gke-infrastructure-repo
, richiama il trigger create-infra
. Questo trigger identifica il ramo in cui è avvenuto il push e va 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 viene eseguito il push del codice al ramo dev, il trigger esegue Terraform sulla cartella dev del ramo dev per creare un cluster GKE dev. Analogamente, quando viene eseguito il push al ramo staging
, il trigger esegue Terraform sulla cartella temporanea del ramo per creare un cluster GKE di gestione temporanea.
Esegui la pipeline per creare cluster GKE:
Nella console Google Cloud, vai alla pagina Cloud Build.
Vai alla pagina di 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.
- Esistono cinque trigger webhook di Cloud Build. Cerca l'attivatore con il nome
Fai clic sul nome del trigger. Si apre la definizione dell'attivatore.
Fai clic su APRI EDITOR per visualizzare i passaggi eseguiti dall'attivatore.
Gli altri trigger vengono utilizzati quando si esegue l'onboarding di un'applicazione in CI/CD moderna con GKE: applica il flusso di lavoro per sviluppatori
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 al ramo dev del repositorygke-infrastructure-repo
che ha dato il via a questa pipeline e creato il cluster GKE di sviluppo.Per creare un cluster GKE gestione temporanea, invia una richiesta di pull dal ramo dev al ramo gestione temporanea:
Vai a GitHub e vai al repository
gke-infrastructure-repo
.Fai clic su Richieste di pull, quindi su Nuova richiesta di pull.
Nel menu Base scegli gestione temporanea e nel menu Confronta scegli dev.
Fai clic su Crea richiesta di pull.
Se sei un amministratore del repository, unisci la richiesta di pull. In caso contrario, chiedi all'amministratore di unire la richiesta di pull.
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.
Per creare cluster GKE di produzione, invia un
pull request
dalla gestione temporanea al ramo di produzione:Vai a GitHub e vai al repository
gke-infrastructure-repo
.Fai clic su Richieste di pull, quindi su Nuova richiesta di pull.
Nel menu Base scegli prod e nel menu Confronta scegli gestione temporanea.
Fai clic su Crea richiesta di pull.
Se sei un amministratore del repository, unisci la richiesta di pull. In caso contrario, chiedi all'amministratore di unire la richiesta di pull.
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 dei cluster Kubernetes
Questa pagina elenca 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
):
Cluster di sviluppo
Il cluster di sviluppo (gke-dev-us-central1
) consente agli sviluppatori di accedere a un
che possono usare per iterare le loro applicazioni. È consigliabile
i team usano strumenti come
Skaffold
che forniscono un flusso di lavoro iterativo mediante il monitoraggio attivo
sviluppo e di riapplicarla agli ambienti di sviluppo man mano che le modifiche
in cui viene eseguito il deployment. Questo ciclo di iterazione è simile
ricaricamento a caldo.
Invece di essere specifico per un linguaggio di programmazione, il loop funziona con qualsiasi
che puoi creare con un'immagine Docker. Puoi eseguire il loop all'interno di un cluster Kubernetes.
In alternativa, gli sviluppatori possono seguire il loop CI/CD per un ambiente di sviluppo. Questo loop prepara le modifiche al codice per la promozione in ambienti superiori.
Nel prossimo documento di questa serie, Approccio CI/CD moderno con GKE: applica il flusso di lavoro per sviluppatori, utilizzi sia Skaffold sia 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, hai due cluster GKE per i tuoi ambienti di produzione. Per la ridondanza geografica o ad alta disponibilità, ti consigliamo di aggiungere più cluster ogni ambiente. Per tutti i cluster in cui viene eseguito il deployment delle applicazioni, è l'ideale per utilizzare cluster regionali. Questo approccio isola le tue applicazioni da errori a livello di zona e e interruzioni causate dagli upgrade del cluster o del pool di nodi.
Per sincronizzare delle risorse del cluster, ad esempio spazi dei nomi, quote e RBAC, ti consigliamo di utilizzare Config Sync. Per per ulteriori informazioni su come gestire queste risorse, consulta Repository di criteri e configurazione.
Applicare l'architettura di riferimento
Ora che hai esplorato l'architettura di riferimento, puoi esaminare una un flusso di lavoro basato su questa implementazione. Nel prossimo documento serie, Approccio CI/CD moderno con GKE: applica il flusso di lavoro per sviluppatori, crei una nuova applicazione, aggiungi una funzionalità ed esegui il deployment dell'applicazione gli ambienti di gestione temporanea e produzione.
Esegui la pulizia
Se vuoi provare il prossimo documento di questa serie, Approccio CI/CD moderno con GKE: applicazione del flusso di lavoro per sviluppatori, non eliminare il progetto o le risorse associati a questo riferimento dell'architettura. In caso contrario, per evitare addebiti sul tuo account Google Cloud le risorse che hai utilizzato nell'architettura di riferimento, puoi eliminare il progetto o rimuovere manualmente le risorse.
Elimina il progetto
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- 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
- Crea una nuova applicazione seguendo la procedura descritta in Approccio CI/CD moderno con GKE: applicazione del flusso di lavoro per sviluppatori.
- Informazioni su best practice per la configurazione della federazione delle identità.
Leggi Kubernetes e le sfide del deployment continuo del software.
Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.