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

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 esegue il bootstrap della piattaforma di distribuzione del software.

Esplorare i repository di codice

In questa sezione esplorerai i repository di codice.

Accedere a GitHub

1. In un browser web, vai su 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 Repository.

Esplora i repository di avvio, operatore, configurazione e infrastruttura

I repository di avvio, operatore, configurazione e infrastruttura sono quelli 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.

Repository iniziali

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

Repository di base delle applicazioni

Nei repository di avvio delle applicazioni, gli operatori possono codificare e documentare le 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 iniziali per applicazioni Go, Python e Java.

I repository di avvio delle 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 avvio dell'applicazione forniti dall'architettura di riferimento contengono:

• kustomize 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 di CI.

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

Nel prossimo documento 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 base dell'infrastruttura

Nei repository di base dell'infrastruttura, gli operatori e gli amministratori dell'infrastruttura possono codificare e documentare le best practice, ad esempio pipeline CI/CD, IaC, raccolta di metriche, logging e sicurezza per l'infrastruttura. L'architettura di riferimento include esempi di repository di base dell'infrastruttura che utilizzano Terraform. Il repository di avvio dell'infrastruttura infra-template contiene codice boilerplate per Terraform che puoi utilizzare per creare le risorse dell'infrastruttura richieste da un'applicazione, come 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à. Con l'architettura di riferimento viene fornito un repository denominato terraform-modules. Il repository include codice Terraform basato su modelli per creare varie risorse dell'infrastruttura.

Repository di operatori

Nell'architettura di riferimento, i repository degli operatori sono gli stessi dei repository di avvio delle applicazioni. Gli operatori gestiscono i file richiesti per CI'integrazione continua e la CD nei repository di avvio delle applicazioni. L'architettura di riferimento include i repository app-template-python, app-template-java e app-template-golang.

• Si tratta di modelli iniziali che contengono i manifest Kubernetes di base per le applicazioni in esecuzione in Kubernetes sulla piattaforma. Gli operatori possono aggiornare i manifest nei modelli iniziali 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 di CI e CD rispettivamente sulla piattaforma. Analogamente alle 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 avvio. Gli sviluppatori sono quindi liberi di estendere i manifest con modifiche specifiche dell'applicazione, come nomi delle 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 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 successiva esecuzione senza alcuna modifica da parte dello sviluppatore.

Per saperne di più sull'utilizzo di kustomize per gestire i manifest Kubernetes, consulta la kustomize.

Repository di configurazione e policy

L'architettura di riferimento include 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 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 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 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 l'ultima configurazione 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, utilizzi Policy Controller, basato su Open Policy Agent, per intercettare e convalidare ogni richiesta ai cluster Kubernetes nella 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 richiesta per l'utilizzo di Policy Controller per creare una risorsa:

Crea e definisci le regole nel repository Config Sync e queste modifiche vengono applicate al cluster. Dopodiché, le nuove richieste di risorse dai client CLI o API vengono convalidate rispetto ai vincoli dal Policy Controller.

Per ulteriori informazioni sulla gestione delle policy, consulta la panoramica di Policy Controller.

Repository dell'infrastruttura

Il riferimento include un'implementazione del repository dell'infrastruttura utilizzando Terraform. Il repository gke-infrastructure-repo contiene l'infrastruttura come codice per creare cluster GKE per gli ambienti di sviluppo, gestione temporanea e produzione e configurare Config Sync su questi cluster 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 cartelle di sviluppo, gestione temporanea e produzione in ogni ramo.

Esplorare 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 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 dell'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 rami di sviluppo, gestione temporanea e produzione. Nel repository sono presenti anche le cartelle dev, staging e production che corrispondono a questi rami. Esistono regole di protezione dei rami nel repository che garantiscono che il codice possa essere inviato solo al ramo di sviluppo. Per eseguire il push del codice nei rami di staging e produzione, devi creare una richiesta di pull.

In genere, una persona che ha accesso al repository esamina le modifiche e poi unisce la richiesta pull per assicurarsi che solo le modifiche previste vengano promosse nel ramo superiore. Per consentire agli utenti 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 ignorare la revisione e unire la richiesta di pull.

Quando viene eseguito un push su gke-infrastructure-repo, viene richiamato il trigger create-infra. Questo trigger identifica il ramo in cui è stato eseguito il push e passa alla cartella corrispondente nel repository di 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 nella cartella dev del ramo dev per creare un cluster GKE di sviluppo. Allo stesso modo, quando viene eseguito un push sul ramo staging, il trigger esegue Terraform nella cartella di staging del ramo di staging per creare un cluster GKE di staging.

Esegui la pipeline per creare cluster GKE:

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

   Vai alla pagina Cloud Build

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

2. Fai clic sul nome del trigger. Viene aperta la definizione del trigger.

3. Fai clic su APRI EDITOR per visualizzare i passaggi eseguiti dal trigger.

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

   

4. Nella Google Cloud console, 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 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 di 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 di pull.

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

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

   Vai alla pagina della 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 una pull request dal ramo di staging al ramo 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 di pull.

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

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

    Vai alla pagina della 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), lo staging (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 uno spazio dei nomi che possono utilizzare per eseguire l'iterazione delle 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 rapido. Tuttavia, anziché essere specifico per un linguaggio di programmazione, il ciclo funziona con qualsiasi applicazione che puoi creare con un'immagine Docker. Puoi eseguire il ciclo 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 in ambienti di livello superiore.

Nel documento successivo di questa serie, CI/CD moderno con GKE: applicare 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 lo staging. 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 gli ambienti di produzione. Per i sistemi di georedundancy o 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 protegge le tue applicazioni da errori a livello di zona e da eventuali interruzioni causate da upgrade del 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 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 sviluppatori basato su questa implementazione. Nel documento successivo di questa serie, CI/CD moderno con GKE: applicare il flusso di lavoro degli sviluppatori, crei una nuova applicazione, aggiungi una funzionalità e poi esegui il deployment dell'applicazione negli ambienti di staging e produzione.