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 best practice CI/CD generali rimangono valide. Per ulteriori informazioni, vedi Tecnologia DevOps: integrazione continua e Tecnologia DevOps: distribuzione continua.

Integrazione continua

Integrazione continua (CI) è una pratica in cui gli sviluppatori integrano tutte le modifiche al codice in un il più spesso possibile. È pensato per consentire errori più rapidi l'individuazione dei problemi il prima possibile durante il processo. 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 produce in genere un artefatto di cui puoi eseguire il deployment nelle fasi successive 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 il momento in cui dell'applicazione in esecuzione 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 CI dovrebbero essere eseguite in meno di 10 minuti. Se non è possibile, crea due tipi di pipeline CI:

  • Pipeline rapide: queste pipeline in genere vengono eseguite entro 10 minuti. Queste pipeline sono per 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 eseguono test e controlli più completi. Le pipeline complete vengono eseguite su richieste di unione o pull e commit nel ramo principale.

Testare 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 fin dalle prime fasi delle pipeline

Avere controlli di sicurezza e bilanciamenti il prima possibile nel ciclo di vita ciclo di lancio di Android. 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:

  • Richiedere agli esperti in materia di rivedere qualsiasi codice integrato nel tuo di produzione.

  • Implementa l'analisi tramite lint 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.

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

  • Impedisci il deployment delle immagini che contengono vulnerabilità nel tuo mediante Autorizzazione binaria. Autorizzazione binaria richiede 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
    • Autorizzazione del proprietario del prodotto

Distribuzione continua

Distribuzione continua (CD) di rilasciare il codice in qualsiasi momento. CD opera sull'artefatto prodotto da CI pipeline di dati. Le pipeline CD possono essere eseguite molto più a lungo delle pipeline CI, in particolare se utilizzi strategie di deployment più elaborate, come di 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 dell'infrastruttura nel tuo ambiente. Quando una metodologia GitOps, ti assicuri che tutte le modifiche alle applicazioni i cluster sono archiviati in repository di origine e sono sempre accessibili.

L'utilizzo delle metodologie GitOps offre i seguenti vantaggi:

  • Puoi esaminare le modifiche prima che ne venga eseguito il deployment mediante unione o pull richieste.
  • Hai un'unica sede che puoi utilizzare per fare riferimento allo stato del tuo di applicazioni e cluster in qualsiasi momento.
  • Gli snapshot di cluster e applicazioni semplificano il ripristino quando in cui sono presenti errori.

Per saperne di più sulla metodologia GitOps e sui diversi pattern che che puoi utilizzare nei repository di origine, 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 tutorial di Google Cloud. Per scoprire come gestire le applicazioni in stile GitOps, prova la Distribuzione continua in stile GitHub 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 presuppone che tu stia mantenendo la configurazione specifica dell'ambiente separata 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.

Alcuni dei diversi pattern di deployment disponibili includono seguenti:

  • 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 set parallelo aggiuntivo di istanze alle istanze di produzione esistenti con una versione aggiornata della tua applicazione. Puoi trasferire il traffico alle nuove istanze quando pronti per il deployment.

Per saperne 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 deployment target. 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 di deployment richiedono l'integrazione con altre parti dell'applicazione come 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 QA): questi ambienti devono assomigliare il più possibile all'ambiente di produzione. Sono utilizzata per eseguire test su larga scala delle modifiche, come integrazione, caricamento delle prestazioni o dei test di regressione.

  • Ambiente di produzione: è l'ambiente in cui vengono svolti carichi di lavoro e applicazioni e 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 ai fini dei costi è possibile fare lo scale down delle repliche dei cluster di pre-produzione. Conservare cluster simili assicura che tutti i test vengano eseguiti sullo stesso cluster o su cluster simili a ciò che è in produzione. Parità tra pre-produzione e produzione riduce anche la probabilità di errori imprevisti dovuti e le differenze ambientali quando si esegue 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 e configurazioni, puoi anche usare 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 o considerati pattern di accesso non testati dagli utenti. È 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 deployment più solide consente di ridurre l'impatto e interessano meno utenti finali quando sorgono problemi in produzione.

Riepilogo elenco di controllo

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

Area Tasks
Integrazione continua
Distribuzione continua

Passaggi successivi