Questa guida descrive un insieme di best practice per l'integrazione continua e la distribuzione continua (CI/CD) in Google Kubernetes Engine (GKE). Queste pratiche coprono un'ampia 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 di CI/CD. Per saperne di più, consulta Tecnologia DevOps: integrazione continua e Tecnologia DevOps: distribuzione continua.
Integrazione continua
L'integrazione continua (CI) è una pratica in cui gli sviluppatori integrano tutte le modifiche apportate al codice in un ramo principale il più spesso possibile. Lo scopo è quello di consentire errori più rapidi rivelando i problemi il prima possibile nella procedura. Le pipeline CI vengono in genere attivate dagli sviluppatori che eseguono il push delle modifiche al codice. La pipeline prevede passaggi per convalidare queste modifiche, ad esempio linting, test e creazione. Una pipeline CI in genere produce un artefatto che puoi eseguire il deployment nelle fasi successive del processo di deployment.
Crea pipeline che consentano un'iterazione rapida
Il tempo che intercorre tra la modifica del codice da parte di uno sviluppatore e la disponibilità di una versione in esecuzione dell'applicazione deve essere il più breve possibile. Questa velocità è particolarmente importante durante lo sviluppo su rami di funzionalità che prevedono un'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 per i rami delle funzionalità e non sono pensate per essere esaustive. Le pipeline rapide possono potenzialmente generare artefatti instabili.
Pipeline complete: l'esecuzione di queste pipeline può richiedere più di 10 minuti e vengono eseguiti test e controlli più completi. Le pipeline complete vengono eseguite in caso di richieste di unione o pull e commit al ramo principale.
Testare le immagini container
Nell'ambito delle pipeline CI, assicurati di eseguire tutti i test richiesti sul codice e sugli artefatti di build. Questi test devono includere test delle unità, funzionali, di integrazione e di carico o delle prestazioni.
È anche importante 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 ti consentono anche di verificare che file specifici si trovino nella posizione corretta e abbiano i contenuti corretti.
Per testare le immagini container, puoi utilizzare il framework Container Structure Tests.
Stabilire la sicurezza nelle prime fasi delle pipeline
Disponi di controlli di sicurezza ed equilibri il prima possibile nel ciclo di vita dello sviluppo. Se trovi i rischi per la sicurezza prima di creare artefatti o eseguire il deployment, puoi ridurre il tempo e i costi necessari per affrontarli.
Per contribuire a ottenere un rilevamento tempestivo, puoi implementare le seguenti misure di sicurezza nelle pipeline:
Richiedi che gli esperti della materia esaminino il codice integrato nel tuo repository di produzione.
Implementa il linting e l'analisi statica del codice nelle prime fasi della pipeline. Questi test ti aiutano a trovare punti deboli come l'assenza di escape degli input, l'accettazione di dati di input non elaborati per le query SQL o vulnerabilità nel codice.
Esegui la scansione dell'immagine container creata per rilevare le vulnerabilità con l'analisi delle vulnerabilità.
Impedisci il deployment nei tuoi cluster di immagini che contengono vulnerabilità utilizzando Autorizzazione binaria. Autorizzazione binaria richiede un abbonamento a GKE Enterprise. Per offrirti una maggiore sicurezza nelle immagini prodotte, Autorizzazione binaria ti consente anche di richiedere attestazioni da diverse entità o sistemi. Ad esempio, queste attestazioni potrebbero includere quanto segue:
- Analisi delle vulnerabilità superata
- Test QA superati
- Approvazione del proprietario del prodotto
Distribuzione continua
La distribuzione continua (CD) ti consente di rilasciare il codice in qualsiasi momento. CD opera sull'artefatto prodotto dalle pipeline CI. Le pipeline CD possono essere eseguite per un periodo di tempo molto più lungo rispetto alle pipeline CI, soprattutto se utilizzi strategie di deployment più elaborate, come i deployment blu/verde.
Utilizzare la metodologia GitOps
GitOps è il concetto di infrastruttura dichiarativa archiviata nei repository Git e gli strumenti CI/CD per eseguire il deployment di questa infrastruttura nel tuo ambiente. Quando utilizzi una metodologia GitOps, ti assicuri che tutte le modifiche alle tue applicazioni e ai tuoi cluster siano archiviate nei repository di origine e siano sempre accessibili.
L'utilizzo delle metodologie GitOps offre i seguenti vantaggi:
- Puoi rivedere le modifiche prima che vengano implementate tramite richieste di unione o pull.
- Hai una posizione unica che puoi utilizzare per fare riferimento allo stato delle tue applicazioni e dei tuoi cluster in qualsiasi momento.
- Gli snapshot dei cluster e delle applicazioni semplificano il ripristino in caso di errori.
Per scoprire di più sulla metodologia GitOps e sui diversi pattern che puoi utilizzare nei repository di origine, consulta la sezione 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 l'esercitazione Gestione dell'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.
Promuovere le immagini container anziché ricompilarle
Le immagini container non devono essere ricompilate quando passano attraverso le diverse fasi di una pipeline CI/CD. La ricompilazione può introdurre piccole differenze tra i rami di codice. Queste differenze possono causare errori nell'applicazione in produzione o l'aggiunta accidentale di codice non testato nell'immagine del container di produzione. Per assicurarti che l'immagine container che hai testato sia quella che esegui il deployment, è consigliabile creare una sola volta e promuovere lungo i tuoi ambienti. Questi consigli presuppongono che tu mantenga la configurazione specifica per l'ambiente separata dai pacchetti.
Valuta la possibilità di utilizzare pattern di deployment e test più avanzati
GKE ti offre la flessibilità di eseguire il deployment e testare le tue applicazioni utilizzando diversi pattern. Il pattern di deployment che scegli dipende in gran parte dai tuoi obiettivi commerciali. Ad esempio, potresti dover eseguire il deployment delle modifiche senza tempi di inattività o eseguire il deployment delle modifiche in un ambiente o in un sottoinsieme di utenti prima di rendere disponibile una funzionalità a livello generale.
Di seguito sono riportati alcuni dei diversi pattern di deployment disponibili:
Ricreazione di un deployment: riduci completamente le dimensioni della versione dell'applicazione esistente prima di aumentare le dimensioni della nuova versione dell'applicazione.
Deployment di aggiornamento in sequenza: aggiorni un sottoinsieme di istanze dell'applicazione in esecuzione anziché aggiornarle tutte contemporaneamente. Quindi, aggiorni progressivamente altre istanze dell'applicazione in esecuzione finché non sono tutte aggiornate.
Deployment blu/verde: esegui il deployment di un set parallelo aggiuntivo di istanze nelle istanze di produzione esistenti con una versione aggiornata della tua applicazione. Trasferisci il traffico alle nuove istanze quando sono pronte per il deployment.
Cluster separati per ambienti diversi
La separazione degli ambienti è un aspetto importante da considerare per qualsiasi destinazione di deployment. Idealmente, dovresti avere cluster separati per ciascuno dei seguenti ambienti:
Ambiente di sviluppo: questo ambiente è quello in cui gli sviluppatori eseguono il deployment delle applicazioni per test e sperimentazioni. 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 porte e gli sviluppatori hanno un maggiore controllo sulla configurazione del cluster.
Ambienti di pre-produzione (gestione temporanea o controllo qualità): 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, rendimento o regressione.
Ambiente di produzione: questo ambiente è quello in cui vengono eseguiti i workload di produzione e i servizi e le applicazioni rivolti agli utenti.
Per saperne di più su questi ambienti, consulta la sezione Ambienti in Kubernetes e le sfide della distribuzione continua del software.
Mantenere gli ambienti di pre-produzione vicini alla produzione
Idealmente, i cluster di pre-produzione sono identici ai cluster di produzione, ma per motivi di costo possono essere repliche ridimensionate. Mantenere i cluster simili garantisce che i test vengano eseguiti nelle stesse condizioni o in condizioni simili a quelle di produzione. La parità tra i cluster di pre-produzione e produzione riduce anche la probabilità di errori imprevisti dovuti a differenze ambientali durante il deployment in produzione.
L'infrastruttura dichiarativa e GitOps ti aiutano a ottenere una parità più stretta dei tuoi ambienti perché puoi duplicare più facilmente la configurazione del cluster sottostante. Per garantire che gli ambienti abbiano condizioni simili per criteri e configurazioni, puoi anche utilizzare strumenti come Config Sync.
Prepararsi agli errori in produzione
Nessun test può garantire il corretto comportamento della tua applicazione in produzione. Gli errori possono essere causati da casi limite con dati non presi in considerazione o da pattern di accesso da parte degli utenti che non sono stati testati. È importante monitorare l'applicazione in produzione e disporre di meccanismi di rollback e deployment automatici per poter reagire rapidamente e correggere bug o interruzioni. L'utilizzo di strategie di implementazione più solide consente di ridurre l'impatto dei problemi e di interessare un numero inferiore di utenti finali quando si verificano problemi in produzione.
Riepilogo della lista di controllo
La seguente tabella riassume le attività che ti consigliamo di eseguire quando utilizzi una pipeline CI/CD in GKE:
| Area | Tasks |
|---|---|
| Integrazione continua |
|
| Distribuzione continua |
|
Passaggi successivi
- Scopri le best practice per l'architettura multi-tenancy aziendale.
- Scopri di più su CI/CD su Google Cloud.