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

Questa guida descrive una serie di best practice per l'integrazione continua e 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 ulteriori informazioni, vedi 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 ramo 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 sono di solito attivati dal push delle modifiche al codice da parte degli sviluppatori. La pipeline prevede passaggi convalidare modifiche come analisi tramite lint, test e creazione. Una pipeline CI tipicamente produce un artefatto che puoi eseguire il deployment nelle fasi successive della procedura di deployment.

Creazione di pipeline che consentono l'iterazione rapida

Il tempo che intercorre tra il momento in cui uno sviluppatore apporta una modifica al codice e quello 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 caratteristiche che comportano 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 causare artefatti instabili.

  • Pipeline complete: l'esecuzione di queste pipeline può richiedere più di 10 minuti, ed eseguono 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 tue pipeline CI, assicurati di eseguire tutti i test richiesti sui tuoi il codice e gli artefatti della build. Questi test dovrebbero includere unità, funzionalità, integrazione e test 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 del container. Il test consente anche di verificare che file specifici siano nel la posizione corretta e avere i contenuti corretti.

Per testare le immagini container, puoi utilizzare Test della struttura del container il modello di machine learning.

Stabilisci la sicurezza nelle prime fasi delle pipeline

Implementa controlli e verifiche di sicurezza il più presto possibile nel ciclo di vita dello sviluppo. Individuando i rischi per la sicurezza prima di creare artefatti o eseguire il deployment, puoi ridurre i tempi e i costi spesi per far fronte a questi rischi.

Per consentire un rilevamento precoce, puoi implementare le seguenti funzionalità di sicurezza misure 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. Questo il test aiuta a individuare i punti deboli, quali il mancato passaggio degli input, l'accettazione dati di input non elaborati per query SQL o vulnerabilità nel codice.

  • Esegui la scansione dell'immagine del container compilata per rilevare eventuali vulnerabilità con la scansione delle vulnerabilità.

  • Impedisci il deployment delle immagini che contengono vulnerabilità nel tuo mediante Autorizzazione binaria. L'autorizzazione binaria richiede un abbonamento a GKE Enterprise. Per darti maggiore affidabilità delle immagini prodotte, Autorizzazione binaria consente anche di richiedere attestazioni di entità o sistemi diversi. Ad esempio, queste attestazioni potrebbero includere le seguenti:

    • Analisi delle vulnerabilità superata
    • Test QA superato
    • Firmare il recesso dal ruolo di 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/verde.

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 tuoi 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 ripristino quando sono presenti errori.

Per scoprire di più sulla metodologia GitOps e sui diversi pattern che puoi utilizzare nei tuoi repository di origine, consulta Concetti di GitOps.

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

Promuovi anziché ricreare le immagini container

Le immagini container non devono essere ricreate mentre attraversano le diverse fasi. di una pipeline CI/CD. La ricostruzione può introdurre piccole differenze nel codice rami. Queste differenze possono causare errori nell'applicazione in produzione Causa l'aggiunta accidentale di codice non testato nel container di produzione dell'immagine. Per assicurarti che l'immagine container che hai testato sia l'immagine container che deployment, è meglio crearla una sola volta e promuoverla negli 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à per eseguire il deployment delle applicazioni utilizzando diversi pattern. Il pattern di deployment che scegli molto dipende dai tuoi obiettivi commerciali. Ad esempio, potresti dover eseguire il deployment senza tempi di inattività o senza dover eseguire il deployment di modifiche a un ambiente o a un sottoinsieme di utenti. prima di rendere una funzione disponibile a livello generale.

Di seguito sono riportati alcuni dei diversi pattern di implementazione a tua disposizione:

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

  • Implementazione dell'aggiornamento in sequenza: aggiorni un sottoinsieme di di tutte le istanze dell'applicazione anziché aggiornare l'intera applicazione contemporaneamente. Quindi aggiorni progressivamente di app 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: è l'ambiente in cui vengono gli sviluppatori distribuiscono applicazioni a scopo di 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 barriere e gli sviluppatori hanno un maggiore controllo la 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 carichi di lavoro di produzione e le applicazioni e i servizi rivolti agli utenti.

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

Mantieni 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 replicati con scale down. Conservare cluster simili assicura che tutti i test vengano eseguiti sullo stesso cluster o su cluster simili a ciò che è in 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 consentono di raggiungere una maggiore parità di dei tuoi ambienti perché puoi duplicare più facilmente la configurazione nel cluster sottostante. Per assicurarti 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 e produzione. Gli errori possono essere causati da casi perimetrali con dati che non erano pattern di accesso considerati o di accesso da parte degli utenti che non sono stati testati. È importante per monitorare l'applicazione in produzione e fare in modo che il rollback in modo da poter reagire e correggere rapidamente 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 piattaforma CI/CD in GKE:

Area Tasks
Integrazione continua
Distribuzione continua
anziché ricostruire i container.

Passaggi successivi