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 le best practice CI/CD generali sono comunque valide. Per saperne di più, consulta DevOps tech: Integrazione continua e DevOps tech: Distribuzione continua.
Per un elenco di controllo riepilogativo di tutte le best practice di GKE, consulta il riepilogo dell'elenco di controllo nella parte inferiore di questa guida.
Per una panoramica consolidata di tutte le best practice di GKE, consulta Best practice per GKE.Integrazione continua
L'integrazione continua (CI) è una pratica in cui gli sviluppatori integrano tutte le modifiche al codice in un ramo principale il più spesso possibile. Lo scopo è consentire errori più rapidi esponendo i problemi il prima possibile nel processo. 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, come 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 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 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 non è possibile, crea due tipi di pipeline CI:
Pipeline rapide: queste pipeline vengono in genere eseguite in 10 minuti o meno. Queste pipeline sono per i rami di funzionalità e non sono pensate per essere complete. 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 su richieste di unione o pull e sui commit al ramo principale.
Testa 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 di 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. Il test consente anche di verificare che file specifici si trovino nella posizione corretta e abbiano il contenuto corretto.
Per testare le immagini container, puoi utilizzare il framework Container Structure Tests.
Stabilisci la sicurezza in anticipo nelle pipeline
Esegui controlli di sicurezza il prima possibile nel ciclo di vita dello sviluppo. Se individui i rischi per la sicurezza prima di creare artefatti o eseguire il deployment, puoi ridurre il tempo e i costi necessari per affrontare questi rischi.
Per facilitare il rilevamento precoce, puoi implementare le seguenti misure di sicurezza nelle pipeline:
Richiedi che gli esperti in materia esaminino il codice integrato nel tuo repository di produzione.
Implementa il linting e l'analisi statica del codice nelle prime fasi della pipeline. Questo test ti aiuta a trovare punti deboli come l'omissione dell'escape degli input, l'accettazione di dati di input non elaborati per le query SQL o le vulnerabilità nel codice.
Esegui la scansione dell'immagine container creata per rilevare le vulnerabilità con l'analisi delle vulnerabilità.
Impedisci il deployment delle immagini che contengono vulnerabilità nei tuoi cluster, 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 parte di diverse entità o sistemi. Ad esempio, queste attestazioni potrebbero includere quanto segue:
- Scansione delle vulnerabilità superata
- Test QA superato
- Approvazione del proprietario del prodotto
Distribuzione continua
La distribuzione continua (CD) ti consente di rilasciare il codice in qualsiasi momento. La 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.
Utilizza 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 applicazioni e ai cluster siano archiviate nei repository di origine e siano sempre accessibili.
L'utilizzo delle metodologie GitOps offre i seguenti vantaggi:
- Puoi esaminare le modifiche prima che vengano eseguite tramite richieste di unione o pull.
- Hai un'unica posizione che puoi utilizzare per fare riferimento allo stato delle applicazioni e dei cluster in qualsiasi momento.
- Gli snapshot dei cluster e delle applicazioni semplificano il ripristino in caso di errori.
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 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é ricrearle
Le immagini container non devono essere ricreate quando passano attraverso le diverse fasi di una pipeline CI/CD. La ricreazione può introdurre piccole differenze tra i rami di codice. Queste differenze possono causare il malfunzionamento dell'applicazione in produzione o l'aggiunta accidentale di codice non testato nell'immagine container di produzione. Per assicurarti che l'immagine container che hai testato sia quella di cui esegui il deployment, è consigliabile creare una sola volta e promuovere l'immagine nei tuoi ambienti. Questo consiglio presuppone che tu mantenga la configurazione specifica dell'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 applicazioni utilizzando diversi pattern. Il pattern di deployment che scegli 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 delle modifiche in un ambiente o in un sottoinsieme di utenti prima di rendere una funzionalità disponibile a livello generale.
Alcuni dei diversi pattern di deployment disponibili includono:
Ricreazione di 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 di aggiornamento in sequenza: aggiorni un sottoinsieme di istanze dell'applicazione in esecuzione anziché aggiornare tutte le istanze dell'applicazione in esecuzione contemporaneamente. Poi aggiorni progressivamente altre istanze dell'applicazione in esecuzione finché non sono tutte aggiornate.
Deployment blu/verde: esegui il deployment di un set aggiuntivo di istanze parallele alle istanze di produzione esistenti con una versione aggiornata dell'applicazione. Quando è tutto pronto per il deployment, trasferisci il traffico alle nuove istanze.
Separa i cluster per ambienti diversi
La separazione degli ambienti è una considerazione importante per qualsiasi target 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 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 porte e gli sviluppatori hanno un maggiore controllo sulla configurazione del 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 delle modifiche, come test di integrazione, carico, prestazioni o regressione.
Ambiente di produzione: in questo ambiente vengono eseguiti i workload di produzione e le applicazioni e i servizi rivolti agli utenti.
Mantieni gli ambienti di pre-produzione simili alla produzione
Idealmente, i cluster di pre-produzione sono identici ai cluster di produzione, ma per motivi di costi possono essere repliche ridimensionate. Mantenere i cluster simili garantisce 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 quando esegui il deployment in produzione.
L'infrastruttura dichiarativa e GitOps ti aiutano a ottenere una maggiore parità degli ambienti perché puoi duplicare più facilmente la configurazione del cluster sottostante. Per assicurarti che gli ambienti abbiano condizioni simili per criteri e configurazioni, puoi anche utilizzare strumenti come Config Sync.
Preparati agli errori in produzione
Nessun test può garantire il corretto comportamento dell'applicazione in produzione. Gli errori possono essere causati da casi limite con dati non considerati o da pattern di accesso degli utenti non 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 deployment più robuste consente di ridurre l'impatto dei problemi e di interessare un numero inferiore di utenti finali quando si verificano problemi in produzione.
Riepilogo dell'elenco di controllo
La seguente tabella riepiloga le attività che 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.