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 comunque 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 al codice in un branco principale il più spesso possibile. Ha lo scopo di consentire errori più rapidi esponendo i problemi il prima possibile durante la procedura. Le pipeline CI vengono solitamente attivate dagli sviluppatori che eseguono il push delle modifiche al codice. La pipeline prevede passaggi per convalidare queste modifiche, come linting, test e build. Una pipeline CI tipicamente produce un artefatto che puoi eseguire il deployment nelle fasi successive della procedura di deployment.
Crea pipeline che consentano l'iterazione rapida
Il tempo che intercorre tra la modifica del codice da parte di uno sviluppatore 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 nei rami delle funzionalità che richiedono un'iterazione rapida da parte degli sviluppatori. Idealmente, le pipeline di CI dovrebbero essere eseguite in meno di 10 minuti. Se non è possibile, crea due tipi di pipeline CI:
Pipeline rapide: in genere vengono eseguite in 10 minuti o meno. Queste pipeline sono destinate ai branch di funzionalità e non sono pensate per essere complete. Le pipeline rapide possono potenzialmente generare elementi 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 su richieste di merge o pull e sui commit nel ramo principale.
Testa le immagini container
Nell'ambito delle pipeline CI, assicurati di eseguire tutti i test richiesti sul codice e sugli elementi di build. Questi test devono includere test di unità, funzionali, di integrazione e di carico o prestazioni.
È inoltre 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 dei contenitori, puoi utilizzare il framework Container Structure Tests.
Stabilisci la sicurezza nelle prime fasi delle pipeline
Esegui controlli e verifiche di sicurezza il più presto possibile nel ciclo di vita dello sviluppo. Individuando i rischi per la sicurezza prima di creare gli elementi o eseguire il deployment, puoi ridurre il tempo e i costi spesi per gestirli.
Per contribuire a un rilevamento precoce, puoi implementare le seguenti misure di sicurezza nelle tue pipeline:
Richiedi agli esperti in materia di esaminare qualsiasi 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 la mancata applicazione di escape agli input, l'accettazione di dati di input non elaborati per le query SQL o le vulnerabilità nel codice.
Esegui la scansione dell'immagine del container compilata per rilevare eventuali vulnerabilità con la scansione delle vulnerabilità.
Impedisci il deployment di immagini contenenti vulnerabilità nei tuoi cluster utilizzando Autorizzazione binaria. L'autorizzazione binaria richiede un abbonamento a GKE Enterprise. Per offrirti una maggiore affidabilità delle immagini prodotte, Autorizzazione binaria ti consente anche di richiedere attestazioni da parte di entità o sistemi diversi. Ad esempio, queste attestazioni potrebbero includere quanto segue:
- Analisi delle vulnerabilità superata
- Test di QA superati
- Firmare il modulo di presa in carico del proprietario del prodotto
Distribuzione continua
La distribuzione continua (CD) ti consente di rilasciare il codice in qualsiasi momento. Il CD opera sull'elemento prodotto dalle pipeline di CI. Le pipeline CD possono essere eseguite per molto più tempo rispetto alle pipeline CI, soprattutto se utilizzi strategie di deployment più elaborate come i deployment blu/verdi.
Utilizza la metodologia GitOps
GitOps è il concetto di infrastruttura dichiarativa archiviata nei repository Git e gli strumenti CI/CD per eseguire il deployment dell'infrastruttura nel tuo ambiente. Quando utilizzi una metodologia GitOps, ti assicuri che tutte le modifiche alle tue applicazioni e ai cluster vengano memorizzate nei repository di codice sorgente 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 un'unica posizione 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 recupero in caso di errori.
Per scoprire di più sulla metodologia GitOps e sui diversi pattern che puoi utilizzare nei tuoi 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 con la gestione dell'infrastruttura con GitOps e altri strumenti, prova il tutorial 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.
Promuovi le immagini container anziché ricostruirle
Le immagini dei container non devono essere ricostruite man mano che 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 l'arresto anomalo dell'applicazione in produzione o l'aggiunta accidentale di codice non testato nell'immagine del contenitore di produzione. Per assicurarti che l'immagine container che hai testato sia quella che hai eseguito il deployment, è meglio eseguirne la compilazione una volta e promuoverla nei tuoi ambienti. Questo consiglio assume 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 modello di implementazione scelto dipende in gran parte dagli obiettivi della tua attività. Ad esempio, potrebbe essere necessario implementare le modifiche senza tempi di riposo o in un ambiente o in un sottoinsieme di utenti prima di rendere disponibile una funzionalità a livello generale.
Ecco alcuni dei diversi pattern di implementazione a tua disposizione:
Ricreata un deployment: riduci completamente il livello della versione dell'applicazione esistente prima di aumentare il livello della nuova versione dell'applicazione.
Deployment con aggiornamento in sequenza: aggiorni un sottoinsieme di istanze dell'applicazione in esecuzione anziché tutte le istanze dell'applicazione in esecuzione contemporaneamente. Aggiorna poi progressivamente altre istanze dell'applicazione in esecuzione finché non sono state aggiornate tutte.
Deployment blu/verde: esegui il deployment di un ulteriore insieme parallelo di istanze nelle istanze di produzione esistenti con una versione aggiornata della tua applicazione. Quando è tutto pronto, puoi trasferire il traffico alle nuove istanze.
Cluster separati per ambienti diversi
La separazione degli ambienti è un aspetto importante per qualsiasi destinazione di deployment. Idealmente, dovresti avere cluster separati per ciascuno dei seguenti ambienti:
Ambiente di sviluppo: in questo ambiente gli sviluppatori eseguono il deployment delle applicazioni per i test e la sperimentazione. Questi deployment richiedono l'integrazione con altre parti dell'applicazione o del sistema (ad esempio un database). I cluster per questo ambiente tipicamente hanno meno gate e gli sviluppatori hanno un maggiore controllo sulla configurazione del cluster.
Ambienti di pre-produzione (gestione temporanea o controllo qualità): questi ambienti devono essere il più possibile simili all'ambiente di produzione. Vengono utilizzati per eseguire test su larga scala di modifiche come test di integrazione, di carico, di rendimento o di regressione.
Ambiente di produzione: in questo ambiente vengono eseguiti i workload 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 del continuous software delivery.
Mantieni gli ambienti di pre-produzione simili a quelli di produzione
Idealmente, i cluster di pre-produzione sono identici ai cluster di produzione, ma per motivi di costo possono essere replicati con scale down. Mantenendo i cluster simili, puoi assicurarti che tutti i test vengano eseguiti nelle stesse condizioni o in condizioni simili a quelle di produzione. La parità tra i cluster di pre-produzione e di 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 tuo cluster sottostante. Per assicurarti che i tuoi ambienti abbiano condizioni simili per i criteri e le configurazioni, puoi anche utilizzare strumenti come Config Sync.
Prepararsi agli errori in produzione
Nessun numero di test può garantire il corretto comportamento della tua applicazione in produzione. Gli errori possono essere causati da casi limite con dati che non sono stati considerati o da pattern di accesso 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 del servizio. L'utilizzo di strategie di implementazione più efficaci ti consente di ridurre l'impatto dei problemi e di interessare un numero minore di utenti finali quando si verificano problemi in produzione.
Riepilogo elenco di controllo
La seguente tabella riassume le attività consigliate 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.