Best practice per l'integrazione e la distribuzione continue in Google Kubernetes Engine

Questa guida descrive un insieme di best practice per l'integrazione e la distribuzione continue (CI/CD) in Google Kubernetes Engine (GKE). Queste pratiche coprono una vasta gamma di argomenti, dal controllo del codice sorgente alle strategie di deployment. Queste best practice sono specifiche per GKE e si applicano ancora le best practice generali per CI/CD. Per ulteriori informazioni, consulta Tecnologia DevOps: integrazione continua e Tecnologia DevOps: distribuzione continua.

Integrazione continua

L'integrazione continua (CI) è una pratica in cui gli sviluppatori integrano il più spesso possibile tutte le modifiche al codice in un ramo principale. L'obiettivo è consentire errori più rapidi esponendo i problemi il prima possibile. In genere, le pipeline CI sono attivate dagli sviluppatori che eseguono il push di modifiche al codice. La pipeline prevede passaggi per convalidare queste modifiche come analisi tramite lint, test e creazione. In genere, una pipeline CI genera un artefatto di cui puoi eseguire il deployment nelle fasi successive del processo di deployment.

Crea pipeline che consentono l'iterazione rapida

Il tempo che intercorre tra il momento in cui uno sviluppatore apporta una modifica al codice e il momento in cui hai una versione in esecuzione dell'applicazione deve essere il più breve possibile. Questa velocità è particolarmente importante durante lo sviluppo di rami di funzionalità che prevedono l'iterazione rapida da parte degli sviluppatori. Idealmente, le pipeline CI dovrebbero essere eseguite in meno di 10 minuti. Se ciò non è possibile, crea due tipi di pipeline CI:

  • pipeline rapide: queste pipeline in genere vengono eseguite in 10 minuti o meno. Queste pipeline sono destinate a rami di funzionalità e non sono pensate per essere complete. Le pipeline rapide possono causare artefatti instabili.

  • pipeline complete: l'esecuzione di queste pipeline può richiedere più di 10 minuti ed esegue test e controlli più completi. Le pipeline complete vengono eseguite durante richieste di unione o pull e commit nel ramo principale.

Segui le best practice per la creazione dei container

Per creare immagini più piccole e più resilienti e per semplificare la creazione e l'esecuzione dei container, segui le best practice per la creazione dei container.

Testa le immagini container

Come parte delle tue pipeline CI, assicurati di eseguire tutti i test richiesti sul codice e sugli artefatti della build. Questi test devono includere test di unità, funzionalità, integrazione e carico o prestazioni.

È importante anche testare la struttura delle immagini container create. Il test della struttura garantisce che tutti i comandi vengano eseguiti come previsto all'interno del container. I test consentono inoltre di verificare che file specifici si trovino nella posizione corretta e abbiano i contenuti corretti.

Per testare le immagini container, puoi utilizzare il framework di test della struttura dei container.

Stabilisci la sicurezza fin dalle prime fasi delle pipeline

Effettuare controlli e saldi di sicurezza il prima possibile nel ciclo di vita dello sviluppo. Individuando i rischi per la sicurezza prima di creare artefatti o di eseguirne il deployment, puoi ridurre il tempo e i costi spesi per affrontarli.

Per ottenere il rilevamento precoce, puoi implementare le seguenti misure di sicurezza nelle tue pipeline:

  • Richiedi che gli esperti in materia esaminino qualsiasi codice integrato nel tuo repository di produzione.

  • Implementa l'analisi tramite lint e del codice statico nelle prime fasi della pipeline. Questo test consente di individuare punti deboli, ad esempio l'assenza di escape degli input, l'accettazione di dati di input non elaborati per le query SQL o vulnerabilità nel codice.

  • Analizza l'immagine del container creata per individuare eventuali vulnerabilità con l'analisi delle vulnerabilità.

  • Utilizza Autorizzazione binaria per impedire il deployment nei cluster delle immagini che contengono vulnerabilità. Autorizzazione binaria richiede un abbonamento a GKE Enterprise. Per aumentare l'affidabilità delle immagini prodotte, Autorizzazione binaria consente anche di richiedere attestations da parte di entità o sistemi diversi. Ad esempio, queste attestazioni potrebbero includere quanto segue:

    • Analisi delle vulnerabilità superata
    • Test del QA superato
    • Autorizzazione dal proprietario del prodotto

Distribuzione continua

La distribuzione continua (CD) consente di rilasciare il codice in qualsiasi momento. CD opera sull'artefatto prodotto dalle pipeline CI. Le pipeline CD possono essere eseguite molto più a lungo delle pipeline CI, soprattutto se utilizzi strategie di deployment più elaborate, come i deployment blu/verde.

Utilizza la metodologia GitOps

GitOps è il concetto di infrastruttura dichiarativa archiviata nei repository Git e degli strumenti CI/CD per eseguire il deployment dell'infrastruttura nel tuo ambiente. Quando utilizzi una metodologia GitOps, ti assicuri che tutte le modifiche alle applicazioni e ai cluster siano archiviate in repository di origine e siano sempre accessibili.

L'utilizzo delle metodologie GitOps offre i seguenti vantaggi:

  • Puoi esaminare le modifiche prima di eseguirne il deployment tramite richieste di unione o pull.
  • Hai un'unica località da utilizzare in qualsiasi momento per fare riferimento allo stato delle applicazioni e dei cluster.
  • Gli snapshot dei cluster e delle applicazioni semplificano il ripristino in caso di errori.

Per saperne di più sulla metodologia GitOps e sui diversi pattern che puoi utilizzare nei tuoi repository di codice sorgente, consulta i concetti di GitOps.

Alcuni strumenti comuni utilizzati per l'infrastruttura dichiarativa sono Terraform di Hashicorp e Config Connector di Google Cloud. Per esercitarti nella gestione dell'infrastruttura con GitOps e altri strumenti, prova il tutorial Gestire l'infrastruttura come codice con Terraform, Cloud Build e GitOps. Per scoprire come gestire le applicazioni in stile GitOps, prova la distribuzione continua in stile GitOps con Cloud Build.

Promuovi le immagini container anziché ricreare le immagini container

Le immagini container non devono essere ricreate in quanto passano attraverso le diverse fasi di una pipeline CI/CD. La ricostruzione può introdurre lievi differenze tra i rami di codice. Queste differenze possono causare un errore in produzione dell'applicazione o l'aggiunta accidentale di codice non testato nell'immagine del container di produzione. Per assicurarti che l'immagine container che hai testato sia l'immagine container di cui esegui il deployment, ti consigliamo di crearla una volta e promuoverla nei tuoi ambienti. Questo suggerimento presuppone che tu sia mantenere la configurazione specifica per l'ambiente separata dai pacchetti, come consigliato nelle best practice per la creazione dei container.

Valuta l'utilizzo di pattern di deployment e test più avanzati

GKE offre la flessibilità necessaria per eseguire il deployment e testare le applicazioni utilizzando diversi pattern. Il pattern di deployment scelto dipende in gran parte dai tuoi obiettivi aziendali. Ad esempio, potresti dover eseguire il deployment delle modifiche senza tempi di inattività o eseguire il deployment di modifiche a un ambiente o a un sottoinsieme di utenti prima di rendere una funzionalità disponibile pubblicamente.

Ecco alcuni dei diversi pattern di deployment disponibili:

  • Ricreare un deployment: fai fare lo scale down completo della versione dell'applicazione esistente prima di fare lo scale up della nuova versione dell'applicazione.

  • Deployment dell'aggiornamento in sequenza: puoi aggiornare un sottoinsieme di istanze dell'applicazione in esecuzione anziché aggiornare contemporaneamente tutte le istanze dell'applicazione in esecuzione. Successivamente, aggiorni progressivamente più istanze dell'applicazione in esecuzione fino a quando non vengono aggiornate.

  • Deployment blu/verde: esegui il deployment di un set parallelo aggiuntivo di istanze nelle tue istanze di produzione esistenti con una versione aggiornata dell'applicazione. Puoi passare al traffico verso le nuove istanze quando è tutto pronto per il deployment.

Per scoprire di più su queste strategie, consulta Strategie di deployment e test delle applicazioni.

Cluster separati per ambienti diversi

La separazione degli ambienti è una considerazione importante per qualsiasi destinazione del deployment. Idealmente, dovresti avere cluster separati per ciascuno dei seguenti ambienti:

  • Ambiente di sviluppo: è l'ambiente in cui gli sviluppatori eseguono il deployment delle applicazioni per test e sperimentazione. Questi deployment richiedono l'integrazione con altre parti dell'applicazione o del sistema (ad esempio un database). I cluster per questo ambiente in genere hanno meno gate e gli sviluppatori hanno un maggiore controllo sulla propria configurazione dei cluster.

  • Ambienti di pre-produzione (gestione temporanea o QA): questi ambienti devono assomigliare il più possibile all'ambiente di produzione. Vengono utilizzati per eseguire test su larga scala di modifiche come test di integrazione, carico, prestazioni o regressione.

  • Ambiente di produzione: è l'ambiente in cui vengono eseguiti i carichi di lavoro di produzione e le applicazioni e i servizi rivolti agli utenti.

Per saperne di più su questi ambienti, consulta la sezione Ambienti in Kubernetes e le sfide della distribuzione continua del software.

Mantieni gli ambienti di pre-produzione vicini alla produzione

Idealmente, i cluster di pre-produzione sono identici a quelli di produzione, ma ai fini dei costi è possibile fare lo scale down delle repliche dei cluster di pre-produzione. Mantenere i cluster simili assicura che qualsiasi test venga eseguito sulle stesse condizioni o su condizioni simili a quello in produzione. La parità tra cluster di pre-produzione e produzione riduce anche la probabilità di errori imprevisti dovuti alle differenze ambientali durante il deployment in produzione.

L'infrastruttura dichiarativa e GitOps ti aiutano a ottenere una parità più vicina degli ambienti perché puoi duplicare più facilmente la configurazione del cluster sottostante. Per garantire che i tuoi ambienti abbiano condizioni simili per i criteri e le configurazioni, puoi anche utilizzare strumenti come Config Sync.

Preparati agli errori in produzione

Nessun numero di test può garantire il corretto comportamento dell'applicazione in produzione. Gli errori possono essere causati da casi limite con dati che non sono stati considerati o da pattern di accesso da parte dei tuoi utenti che non sono stati testati. È importante monitorare l'applicazione in produzione e disporre di meccanismi automatici di rollback e deployment in modo da poter reagire rapidamente a bug o interruzioni del servizio e risolverli. L'utilizzo di strategie di deployment più efficaci consente di ridurre l'impatto dei problemi e di avere un impatto su un numero inferiore di utenti finali quando si verificano dei problemi in produzione.

Riepilogo elenco di controllo

La seguente tabella riassume le attività consigliate quando utilizzi una pipeline CI/CD in GKE:

Area Attività
Integrazione continua
Distribuzione continua

Passaggi successivi