CI/CD moderno con Anthos: creare 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 Anthos, Skaffold, kustomize, Artifact Registry e GitLab.

Questo documento fa parte di una serie:

Questo documento è rivolto a architetti aziendali e sviluppatori di applicazioni, nonché ai team di sicurezza informatica, DevOps e di Site Reliability Engineering. Una certa esperienza con gli strumenti e i processi di deployment automatico è utile per comprendere i concetti in questo documento.

Flusso di lavoro CI/CD

Per creare un sistema CI/CD moderno, devi prima scegliere gli strumenti e i servizi che eseguono le funzioni principali del sistema. L'architettura di riferimento è incentrata sull'implementazione delle funzioni principali 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: GitLab
    • Archivia il codice di applicazione e configurazione.
    • Ti consente di rivedere le modifiche.
  • Per la gestione della configurazione delle applicazioni: kustomize
    • Definisce la configurazione desiderata di un'applicazione.
    • Consente di riutilizzare ed estendere le primitive o i progetti base di configurazione.
  • Per l'integrazione continua: GitLab
    • Testa e convalida il codice sorgente.
    • Crea gli artefatti utilizzati dall'ambiente di deployment.
  • Per la distribuzione continua: GitLab
    • Definisce il processo di implementazione del codice in tutti gli ambienti.
    • Consente un facile rollback per le modifiche non riuscite.
  • Per la configurazione dell'infrastruttura e il motore dei criteri: Anthos Config Management
    • Offre 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: cluster Anthos
    • Esegue gli artefatti creati durante CI;integrazione continua.
    • Offre metodologie di scalabilità, controllo di integrità e implementazione per i carichi di lavoro.
  • Per Container Registry: Artifact Registry
    • Archivia gli artefatti (immagini container) creati durante CI;integrazione continua.

Architettura

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

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

Infrastruttura della piattaforma

L'infrastruttura per questa architettura di riferimento è costituita da cluster Kubernetes per supportare lo sviluppo, gli strumenti condivisi e gli ambienti applicativi. 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, configuri i singoli repository per operatori, sviluppatori e tecnici della sicurezza.

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

I repository includono quelli per le best practice e per la configurazione delle applicazioni e delle piattaforme.

In questo flusso di lavoro, gli operatori possono gestire le best practice per la configurazione CI/CD e delle applicazioni nel repository degli operatori. Quando i tuoi sviluppatori possono integrare le applicazioni nel repository di sviluppo, ricevono automaticamente best practice, logica di business e qualsiasi configurazione specializzata necessaria per il corretto funzionamento dell'applicazione. Nel frattempo, il tuo 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

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 ambienti e carichi di lavoro diversi.

Ogni spazio dei nomi include un account di servizio utilizzato dal sistema CI/CD per il deployment di risorse Kubernetes come pod e servizi. Per rispettare il principio del privilegio minimo, ti consigliamo di concedere all'account di servizio solo l'accesso al proprio spazio dei nomi. Puoi definire l'accesso all'account di servizio in Anthos Config Management e implementarlo utilizzando i ruoli di controllo dell'accesso basati sui ruoli (RBAC) di Kubernetes. Una volta adottato 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 da altri spazi dei nomi.

Obiettivi

  • Eseguire il deployment dell'infrastruttura dell'architettura di riferimento.
  • Esplora l'infrastruttura.
  • Esplora i repository del codice e le pipeline.
  • Esplora un esempio di zona di destinazione dell'applicazione.

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.

Al termine di questo tutorial, puoi evitare una fatturazione continua eliminando le risorse che hai creato. Per scoprire di più, vedi Pulizia.

Prima di iniziare

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

    Vai al selettore progetti

  2. Verifica che la fatturazione sia attivata per il tuo progetto Google Cloud. Scopri come verificare se la fatturazione è abilitata per un progetto.

  3. In Google Cloud Console, attiva Cloud Shell.

    Attiva Cloud Shell

Esegui il deployment dell'architettura di riferimento

  1. In Cloud Shell, clona il repository Git:

    git clone https://github.com/GoogleCloudPlatform/solutions-modern-cicd-anthos.git
cd solutions-modern-cicd-anthos

  2. Imposta le variabili di ambiente per questo progetto:

    export PROJECT_ID=PROJECT_ID
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format 'value(projectNumber)')
export REGION="us-central1"

gcloud config set compute/region ${REGION}
gcloud config set core/project ${PROJECT_ID}

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

  3. Abilita le API Cloud Build, Anthos, Service Usage, Cloud Key Management Service (Cloud KMS), Autorizzazione binaria, Secret Manager e Container Analysis:

    gcloud services enable cloudbuild.googleapis.com
gcloud services enable anthos.googleapis.com
gcloud services enable serviceusage.googleapis.com
gcloud services enable cloudkms.googleapis.com
gcloud services enable binaryauthorization.googleapis.com
gcloud services enable secretmanager.googleapis.com
gcloud services enable containeranalysis.googleapis.com

  4. Aggiornare i ruoli e le autorizzazioni di Identity and Access Management (IAM) per l'account di servizio Cloud Build:

    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role roles/owner
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role roles/containeranalysis.admin

  5. Esegui Cloud Build per eseguire il deployment dei cluster:

    gcloud builds submit --substitutions=_PROJECT_ID=${PROJECT_ID}

    Questo processo richiede circa 30 minuti. Al termine, puoi esplorare l'infrastruttura.

Esplora l'infrastruttura

In questa sezione esplorerai i componenti principali del sistema CI/CD, tra cui l'infrastruttura, i repository di codice e una zona di destinazione di esempio.

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

    Vai alla pagina Cluster Kubernetes

    Questa pagina elenca i cluster utilizzati per lo sviluppo (dev-us-west1), gli strumenti condivisi (gitlab) e gli ambienti applicativi (staging-us-west2, prod-us-central1, prod-us-east1):

    I dettagli dei cluster includono località, dimensioni del cluster e core totali.

Cluster di sviluppo

Il cluster di sviluppo (dev-us-west1) 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 alla ricarica a caldo, ma anziché essere specifico per il linguaggio di programmazione, funziona con qualsiasi applicazione che puoi creare con un'immagine Docker. Puoi eseguire il loop all'interno di un cluster Kubernetes.

Nel documento successivo di questa serie, CI/CD moderno con Anthos: applicare il flusso di lavoro degli sviluppatori, utilizzerai Skaffold per creare il ciclo di sviluppo.

Cluster di strumenti condivisi

Qualsiasi sistema di distribuzione del software utilizza una combinazione di strumenti per supportare il ciclo di vita dello sviluppo del software. Seguendo il principio del privilegio minimo, l'implementazione di riferimento fornisce un cluster dedicato per l'archiviazione degli strumenti (gitlab). Ti consigliamo di eseguire il deployment di ogni strumento nel proprio spazio dei nomi.

In questa implementazione del riferimento, utilizzi GitLab per la gestione del codice sorgente e l'integrazione continua. Puoi installare GitLab nel cluster degli strumenti utilizzando il modulo Terraform su GKE per Terraform.

Cluster dell'ambiente dell'applicazione

Nell'architettura di riferimento sono inclusi anche i cluster (staging-us-west2, prod-us-central1, prod-us-east1) per eseguire le tue applicazioni sia per il deployment di pre-produzione (gestione temporanea) che per quello di produzione. Devi eseguire il deployment delle tue applicazioni in almeno un cluster in ogni ambiente. Per i sistemi di ridondanza geografica o ad alta disponibilità (HA), ti consigliamo di aggiungere più cluster a ogni ambiente. Per tutti i cluster in cui è stato eseguito il deployment delle applicazioni, è preferibile utilizzare i cluster a livello di regione. Questo approccio isola le applicazioni dagli errori a livello di zona e da eventuali interruzioni causate dagli upgrade dei cluster o dei pool di nodi.

Consigliamo di utilizzare Anthos Config Management per sincronizzare la configurazione delle risorse del cluster come spazi dei nomi, quote e RBAC. Per ulteriori dettagli su come gestire le risorse, consulta la sezione Repository di criteri e configurazione più avanti in questo documento.

Esplora i repository di codice

In questa sezione esplorerai i repository del codice.

Accedi all'istanza GitLab

  1. In Cloud Shell, recupera l'URL GitLab:

    echo "https://gitlab.endpoints.${PROJECT_ID}.cloud.goog"

    Copia l'URL perché ti serve per un passaggio successivo.

  2. Recupera GitLab User e Password, che sono memorizzati in Secret Manager:

    export GITLAB_USER=$(gcloud secrets versions access latest --secret="gitlab-user")
export GITLAB_PASSWORD=$(gcloud secrets versions access latest --secret="gitlab-password")

echo "User: ${GITLAB_USER}"
echo "Password: ${GITLAB_PASSWORD}"

    Copia queste credenziali perché ti occorrono per un passaggio successivo.

  3. In un browser web, vai all'URL GitLab che hai copiato in precedenza.

  4. Utilizzando le credenziali User e Password che hai copiato, accedi alla tua istanza GitLab.

    Viene visualizzata la pagina Progetti per la tua istanza GitLab.

Esplora i repository operator, starter e di configurazione

L'operatore, il starter e il repository di configurazione sono elementi in cui operatori e amministratori della piattaforma definiscono le best practice comuni per la creazione e il funzionamento della piattaforma. Questi repository si trovano tutti nel gruppo platform-admins.

  1. Nell'istanza GitLab, fai clic su Gruppi, quindi seleziona I tuoi gruppi.

  2. Fai clic su amministratori-piattaforma.

    Viene visualizzato un elenco di repository:

    Ogni repository nell'elenco include una breve descrizione.

Repository operatori

L'architettura di riferimento include i repository shared-kustomize-bases e shared-ci-cd operator.

  • Il repository shared-kustomize-bases contiene i manifest di base di Kubernetes per le applicazioni in esecuzione su Kubernetes nella piattaforma. Gli operatori possono aggiornare i manifest in base alle esigenze, che vengono raccolti automaticamente senza che i team delle applicazioni aggiornino le configurazioni delle singole applicazioni.
  • Il repository shared-ci-cd archivia le best practice per l'esecuzione dei passaggi CI e CD sulla piattaforma. Analogamente alle configurazioni delle applicazioni, gli operatori possono aggiornare e aggiungere fasi alle best practice, mentre le singole pipeline delle applicazioni vengono aggiornate automaticamente.

In questa implementazione del riferimento, gli operatori utilizzano kustomize per gestire le configurazioni di base nel repository shared-kustomize-bases. Gli sviluppatori sono quindi liberi di estendere i manifest con modifiche specifiche dell'applicazione (come i nomi delle risorse e i file di configurazione) nel loro repository delle applicazioni. Lo strumento kustomize supporta la configurazione come dati. Con questa metodologia, gli input e gli output kustomize sono risorse Kubernetes. Puoi utilizzare gli output di una modifica dei manifest per un'altra.

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

La configurazione delle applicazioni viene effettuata in più repository gestiti da team separati.

La configurazione come modello dei dati in kustomize ha un vantaggio importante: quando gli operatori aggiornano la configurazione di base, gli aggiornamenti vengono automaticamente consumati dalla pipeline di deployment dello sviluppatore alla prossima 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 base

Nei repository di base, i tuoi operatori possono codificare e documentare le best practice come CI, raccolta delle metriche, logging e sicurezza per le applicazioni. Nel riferimento sono inclusi esempi di repository di base per le applicazioni Go e Java.

I repository iniziale di golang-template e java-template contengono boilerplate code che puoi utilizzare per creare nuove applicazioni. I repository golang-template-env e java-template-env contengono la configurazione di base necessaria per la CD. Sviluppatori e operatori utilizzano questi repository di avvio durante la creazione di nuove applicazioni.

Nel documento successivo di questa serie, CI/CD moderno con Anthos: applicare il flusso di lavoro degli sviluppatori, utilizzerai i repository golang-template e golang-template-env per creare una nuova applicazione.

Repository di criteri e configurazione

Nel riferimento è inclusa un'implementazione di un repository di configurazione e criteri utilizzando Anthos Config Management. Il repository anthos-config-management contiene la configurazione e i criteri di cui 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 nei team operativi e di sviluppo.

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

Configurazione

In questa implementazione del riferimento, utilizzi Anthos Config Management 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.

Con Anthos Config Management, 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 apporti modifiche fuori banda.

Per ulteriori informazioni su Anthos Config Management, consulta la relativa documentazione.

Criterio

In questa implementazione del riferimento, Anthos Config Management utilizza il 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 controllare completamente non solo i tipi di risorse inviate al cluster, ma anche la loro configurazione.

L'architettura nel diagramma seguente 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 client API.

Puoi creare e definire le regole nel repository di Anthos Config Management e queste modifiche vengono applicate al cluster. Dopodiché, le nuove richieste di risorse dall'interfaccia a riga di comando o dai client API vengono convalidate dai vincoli del Policy Controller.

Per ulteriori informazioni sulla gestione dei criteri con Anthos Config Management, consulta la panoramica di Policy Controller.

Esplora i repository di applicazioni

  1. Nell'istanza GitLab, fai clic su Gruppi, quindi seleziona I tuoi gruppi.

  2. Fai clic su petabank.

    Vengono mostrati i repository di configurazione delle applicazioni e del codice dell'applicazione per l'applicazione petabank:

    Sono elencati due repository di codice con brevi descrizioni.

In questa architettura di riferimento, ogni applicazione ha due repository: un repository di codice e un repository di configurazione.

Il repository del codice dell'applicazione contiene quanto segue:

  • Codice sorgente applicazione
  • Un Dockerfile che descrive come creare ed eseguire l'applicazione
  • La definizione della pipeline CI/CD che utilizza attività condivise create dagli operatori
  • kustomize patch per ogni ambiente delle applicazioni

Il repository di configurazione delle applicazioni contiene i manifest di Kubernetes con rendering completo necessari per il deployment dell'applicazione. Questo repository contiene un ramo per ogni ambiente in cui verrà eseguito il deployment dell'applicazione.

Esplora le zone di destinazione delle applicazioni

L'infrastruttura dell'architettura di riferimento include anche esempi di zone di destinazione delle applicazioni. In questa sezione esplorerai una zona di destinazione di esempio. Per ulteriori informazioni sulle zone di destinazione, consulta CI/CD moderno con Anthos: un framework di distribuzione del software.

  1. Nella console Google Cloud, vai alla pagina Carichi di lavoro di GKE.

    Vai alla pagina Carichi di lavoro

  2. Nel menu a discesa Cluster, seleziona staging-us-west2.

  3. Nel menu a discesa Spazio dei nomi, seleziona petabank.

    Viene visualizzato un elenco di risorse Kubernetes per l'applicazione petabank:

    La sezione Carichi di lavoro mostra due risorse di deployment per l'architettura di riferimento.

  4. Per visualizzare la risorsa di servizio Kubernetes per l'applicazione petabank, fai clic su Servizi e Ingress.

Lo spazio dei nomi contiene le risorse per l'applicazione petabank, un runner GitLab per le attività CI/CD e un deployment e un servizio Kubernetes per l'applicazione petabank. Seguendo il principio del privilegio minimo, i criteri RBAC e di rete sono definiti nel repository anthos-config-management archiviato in GitLab. Puoi applicare la configurazione e i criteri utilizzando Anthos Config Management.

Applica 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 moderno con Anthos: applica il flusso di lavoro degli sviluppatori, crei una nuova applicazione, aggiungi una funzionalità, quindi esegui 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 Anthos: applicazione del flusso di lavoro degli sviluppatori, non eliminare il progetto o le risorse associate a questa architettura di riferimento. Altrimenti, 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 builds submit --substitutions=_PROJECT_ID=${PROJECT_ID} --config cloudbuild-destroy.yaml
gcloud endpoints services delete gitlab.endpoints.${PROJECT_ID}.cloud.goog
gcloud endpoints services delete registry.endpoints.${PROJECT_ID}.cloud.goog

Passaggi successivi