Questo documento descrive un framework per l'implementazione di processi di integrazione/distribuzione continua (CI/CD) moderni su una piattaforma di distribuzione del software multi-team che utilizza Google Kubernetes Engine.
Puoi quindi eseguire l'iterazione sulla piattaforma per migliorare ulteriormente le prestazioni per lo sviluppo e le operazioni, inclusa la velocità di rilascio, l'affidabilità della piattaforma e il tempo di recupero dai guasti.
Questo documento fa parte di una serie:
CI/CD moderno con GKE: un framework di distribuzione del software (questo documento)
CI/CD moderno con GKE: crea un sistema CI/CD (architettura di riferimento)
CI/CD moderno con GKE: applica il flusso di lavoro degli sviluppatori
Questo documento è rivolto ad architetti aziendali e sviluppatori di applicazioni, nonché a team di sicurezza IT, DevOps e Site Reliability Engineering. Per comprendere i concetti di questo documento è utile avere una certa esperienza con gli strumenti e le procedure di deployment automatico.
Un caso per CI/CD moderno
CI/CD è un approccio allo sviluppo del software che consente di automatizzare le fasi di creazione, test e deployment dello sviluppo del software utilizzando una serie di strumenti e processi ripetibili.
Oltre all'automazione CI/CD, Kubernetes e i container hanno consentito alle imprese di ottenere miglioramenti senza precedenti nella velocità di sviluppo e deployment. Tuttavia, anche se l'adozione di Kubernetes e dei container è in crescita, molte organizzazioni non sfruttano appieno i vantaggi in termini di velocità di rilascio, stabilità ed efficienza operativa perché le loro pratiche CI/CD non sfruttano appieno Kubernetes o non risolvono problemi di operazioni e sicurezza.
Un approccio CI/CD veramente moderno deve comprendere più dell'automazione. Per beneficiare appieno dei miglioramenti in termini di velocità e sicurezza e sfruttare la potenza di Kubernetes e dei container, devi semplificare l'onboarding delle applicazioni, le pratiche CI/CD e i processi operativi.
Utilizzando l'infrastruttura coerente offerta dalla piattaforma GKE, metodi CI/CD uniformi e best practice di implementazione, la tua organizzazione può ottenere i seguenti vantaggi per lo sviluppo e le operazioni:
Riduzione del tempo di risposta per le modifiche.
Consenti ai team di operazioni e sicurezza di creare e aggiornare le migliori pratiche per il provisioning delle applicazioni e dei criteri di provisioning sulla piattaforma.
Semplifica l'onboarding delle applicazioni fornendo ai team progetti iniziali completamente funzionanti e di cui è possibile eseguire il deployment con le best practice della tua organizzazione.
Riduzione del tempo necessario per ripristinare il servizio.
Gestisci tutta la configurazione in modo dichiarativo utilizzando GitOps per controlli, rollback e revisioni semplificati.
Standardizza le metodologie di deployment e monitoraggio nell'organizzazione per ridurre il tempo necessario per identificare i fattori che contribuiscono a un problema che influisce sul servizio.
Aumento della frequenza di deployment.
Assicurati che gli sviluppatori di applicazioni possano eseguire l'iterazione in modo indipendente nelle proprie sandbox di sviluppo (o zone di destinazione) senza interferire tra loro.
Utilizza GitOps per il deployment, la gestione delle release migliorata e il monitoraggio delle modifiche.
Implementa guard rail in modo che i team di servizi possano eseguire il deployment di frequente.
Crea un processo di implementazione progressiva per eseguire il deployment in modo coerente negli ambienti di pre-produzione, in modo che gli sviluppatori abbiano la certezza di poter implementare le modifiche in produzione.
Per scoprire come vengono realizzati questi vantaggi e concetti con GKE e CI/CD, consulta gli altri documenti di questa serie:
Valutare l'idoneità per un approccio moderno
Prima di implementare procedure e strumenti CI/CD moderni con GKE, devi valutare se la tua organizzazione e i tuoi team sono pronti ad adottare una nuova piattaforma.
Caratteristiche organizzative
L'adozione di una piattaforma moderna richiede il seguente supporto da parte del leadership e dei team tecnici della tua attività:
Sponsor della leadership. L'adozione di una piattaforma di distribuzione del software è tipicamente un impegno importante intrapreso da più team cross-funzionali. Il procedura in genere comporta modifiche a ruoli e responsabilità, nonché alle pratiche di sviluppo software. Per adottare correttamente questi strumenti e queste tecniche, hai bisogno del supporto di uno o più membri del team di leadership. I sponsor della leadership più efficaci sono quelli che considerano questi cambiamenti come un processo continuo di miglioramento e vogliono responsabilizzare i loro team anziché gestirli.
Allineamento della strategia tecnica e aziendale. Ti consigliamo di allineare i team aziendali e tecnici alle quattro misure chiave della distribuzione del software definite da DevOps Research and Assessment (DORA): tempo di risposta per le modifiche, frequenza di deployment, tempo per ripristinare il servizio e tasso di errore delle modifiche. L'allineamento a queste misure offre ai team aziendali e tecnici un obiettivo comune, consentendo loro di calcolare congiuntamente il ritorno sull'investimento, regolare il tasso di variazione e modificare il livello di investimento.
Risorse. Per avere successo, i team che sviluppano pratiche CI/CD moderne e creano catene di strumenti hanno bisogno delle risorse necessarie: tempo, persone e infrastrutture. Questi team hanno bisogno di tempo per provare e selezionare i processi e gli strumenti migliori. Idealmente, questi team rappresentano molte funzioni diverse nel processo di distribuzione del software e possono integrare altre risorse dell'organizzazione. Infine, i team devono essere in grado di eseguire il provisioning dell'infrastruttura, incluse le risorse cloud e gli strumenti software.
Disponibilità ad adottare nuovi strumenti. Le tecniche e gli strumenti CI/CD moderni spesso vengono forniti con nuovi strumenti e processi. I team devono sperimentare con questi processi e strumenti e essere aperti ad adottarli. È necessario un ciclo di feedback per consentire ai team della piattaforma di ricevere informazioni dai team di applicazioni, operazioni e sicurezza che utilizzano la piattaforma.
Idoneità culturale. Per eseguire correttamente il deployment e adottare un sistema CI/CD moderno con GKE, l'organizzazione e i team tecnici che sviluppano il sistema devono essere pronti a cambiare il modo in cui operano e collaborano. Ad esempio, i team di sviluppo e operations devono essere disposti ad assumersi maggiori responsabilità per la sicurezza, mentre i team di sicurezza e operations devono essere disposti a semplificare le procedure di approvazione delle modifiche.
Capacità tecniche
L'adozione di un approccio CI/CD moderno richiede inoltre che i team siano preparati tecnicamente nel seguente modo:
Esperienza con i container. I team che adottano approcci CI/CD moderni devono avere una certa esperienza con i contenitori. Idealmente, questa esperienza include tecniche di sviluppo per la creazione di immagini container e la combinazione di container per creare sistemi più grandi.
Strategia di integrazione continua. I team devono avere una certa esperienza nell'utilizzo di strumenti di CI (come Jenkins, TeamCity, Bamboo e CircleCI) ed eseguire alcune operazioni di integrazione continua e di test automatico. Consigliamo alle organizzazioni di pianificare come migliorare ulteriormente queste procedure.
Automazione del deployment. I team devono avere una certa esperienza con l'automazione del deployment. Esempi di strumenti di deployment automatico includono script shell di base, Terraform, Chef o Puppet. Avere una conoscenza di base degli strumenti e delle procedure di deployment automatico è fondamentale per semplificare e automatizzare i deployment.
Architetture orientate ai servizi. Sebbene non sia un prerequisito per l'adozione di processi CI/CD moderni, l'adozione di più architetture modulari e orientate ai servizi deve essere un obiettivo a lungo termine delle organizzazioni che vogliono adottare tecniche e strumenti CI/CD moderni con GKE. È stato dimostrato che le architetture basate su servizi migliorano la velocità e l'affidabilità.
Controllo del codice sorgente moderno. Gli strumenti di controllo del codice sorgente moderni come Git consentono ai team di stabilire flussi di lavoro come lo sviluppo basato sul trunk, i branch di funzionalità e le richieste di unione.
Progettare un approccio CI/CD moderno con GKE
Questa sezione descrive una piattaforma di distribuzione del software e i relativi componenti. Per migliorare le prestazioni relative alla distribuzione del software, devi implementare CI/CD e altre best practice tecniche che consentano ai team di rilasciare rapidamente e operare in modo efficiente.
Questa sezione illustra anche l'infrastruttura necessaria per supportare il ciclo di vita del deployment del software e come gestirla in modo coerente con GKE. Infine, questa sezione fornisce un esempio di flusso di lavoro di distribuzione del software e mostra come i repository iniziali semplificano l'onboarding e l'implementazione delle best practice. Vengono esaminate le seguenti considerazioni di progettazione:
Piattaforma di distribuzione del software. Il framework e le funzionalità tecniche che costituiscono le basi di un processo di rilascio delle applicazioni affidabile e ad alta velocità.
Infrastruttura della piattaforma. I componenti dell'infrastruttura e le considerazioni di gestione necessari per creare la piattaforma ed eseguire le applicazioni.
Flusso di lavoro di distribuzione del software. In che modo i team collaborano per creare, testare e implementare il codice in modo più efficiente.
Repository di codice. Repository che svolgono diverse funzioni, tra cui l'archiviazione della logica di business effettiva, la configurazione specifica dell'applicazione e il codice per la creazione dell'infrastruttura. Potrebbero anche essere repository iniziali che facilitano l'adozione delle best practice e aiutano a mantenere la coerenza tra i processi automatizzati.
Zone di destinazione delle applicazioni. Entità logica che consente agli sviluppatori di eseguire il deployment e l'iterazione autonoma delle loro applicazioni utilizzando i guard rail che hai implementato.
Modello di funzionamento. Strumenti, procedure e metodi tecnici per gestire l'infrastruttura e le applicazioni che compongono la piattaforma.
Governance. Procedure e considerazioni necessarie per mantenere e gestire la piattaforma di distribuzione del software.
Piattaforme di distribuzione del software
Una piattaforma di distribuzione del software unifica gli strumenti e semplifica le procedure necessarie per creare, pubblicare, implementare e gestire le applicazioni.
La responsabilità della gestione della configurazione, della stabilità, del tempo di attività e della scalabilità di un'applicazione varia a seconda degli operatori, dei team di sicurezza e di sviluppo, ma tutti i componenti e i team devono lavorare insieme per velocizzare le release. Sebbene questo documento descriva metodi per migliorare la gestione del controllo del codice e l'osservabilità delle applicazioni, si concentra principalmente sull'integrazione continua (CI), sulla distribuzione continua (CD) e sulla gestione della configurazione.
Per creare una piattaforma di distribuzione del software completa, hai bisogno di ogni componente riportato nel seguente diagramma:
Ciascuno di questi componenti fornisce funzionalità al sistema e alle applicazioni in esecuzione sulla piattaforma:
Monitoraggio dell'infrastruttura. Il livello di monitoraggio di base necessario durante il provisioning per verificare il corretto funzionamento dei cluster, delle istanze di macchine virtuali (VM) e di altra infrastruttura necessaria per il funzionamento delle applicazioni.
Orchestrazione dei container. La piattaforma che coordina il deployment e il funzionamento delle applicazioni basate su container. Alcuni esempi di piattaforme per l'orchestrazione dei container sono Kubernetes, GKE o GKE Enterprise.
Registro dei contenitori. Lo spazio di archiviazione e controllo dell'accesso per le immagini container.
CI. Il processo di applicazione di attività automatiche a un'applicazione prima del deployment. Le attività di CI in genere includono compilazione, imballaggio e test. I tipi di attività variano in base all'applicazione e all'organizzazione.
CD. Processi di deployment altamente automatizzati e applicati con elevata frequenza. Alcuni esempi di metodologie includono approvazioni manuali, deployment Canary, deployment blue-green o deployment in sequenza.
Norme. Criteri di configurazione della sicurezza e dell'infrastruttura definiti dai team di operazioni e sicurezza e applicati e applicati continuamente dalla piattaforma.
Gestione del codice sorgente. Ad esempio, archiviazione con controllo delle versioni per codice, file di configurazione e definizioni dei criteri. In un sistema CI/CD moderno, la gestione del codice sorgente è in genere Git.
Gestione della configurazione. Il sistema utilizzato per memorizzare e applicare la configurazione dell'applicazione per diversi ambienti.
Osservabilità dell'applicazione. Il logging, il monitoraggio, gli avvisi e il monitoraggio a livello di applicazione utilizzati dai team di sviluppatori, operatori e sicurezza per risolvere i problemi e verificare il corretto funzionamento delle applicazioni.
Infrastruttura della piattaforma
Per creare una piattaforma di distribuzione del software scalabile, hai bisogno di cluster Kubernetes per ambienti di sviluppo e pre-produzione e di più cluster di produzione. I cluster possono avere molte funzioni diverse:
Sviluppo. In questi cluster, gli sviluppatori eseguono implementazioni ad hoc delle loro applicazioni per test e sperimentazione.
L'ambiente dell'applicazione.
Pre-produzione. Per ogni ambiente di preproduzione nel tuo workflow, devi avere un cluster Kubernetes per ospitare le tue applicazioni. Questi cluster devono essere simili ai cluster di produzione in modo da poter ridurre o eliminare le differenze tra gli ambienti e, di conseguenza, migliorare i tassi di successo del deployment.
Produzione. Questi cluster eseguono i carichi di lavoro di produzione. Dovresti utilizzare più cluster distribuiti geograficamente. In questo modo, viene migliorata l'affidabilità in caso di guasti dell'infrastruttura e vengono semplificati i problemi relativi alle operazioni del giorno 2, come gli upgrade e il scaling dei cluster.
Il seguente diagramma mostra l'architettura di alto livello:
In questa architettura, gestisci i cluster per ogni ambiente tramite Config Sync. La configurazione coerente del cluster è fondamentale perché offre agli sviluppatori, agli operatori e ai team di sicurezza la certezza che gli ambienti di preproduzione e di produzione funzionino in modo simile. Puoi utilizzare Config Sync per archiviare e applicare configurazioni comuni in tutto il tuo parco risorse di cluster. Una volta che la configurazione del cluster è standardizzata, verificabile e scalabile, puoi concentrarti sul flusso di lavoro di distribuzione del software, sull'onboarding e sul deployment delle applicazioni.
Gestisci i deployment nei cluster di sviluppo, di gestione temporanea e di produzione tramite le pipeline CI/CD dell'applicazione. La gestione del controllo del codice sorgente funge da punto di coordinamento per il codice e la configurazione dell'applicazione. Le pipeline CI/CD e le immagini container di un'applicazione sono isolate nell'ambiente dell'applicazione. Puoi inizializzare i repository di applicazioni e configurazione utilizzando i repository iniziali e gli strumenti automatici. Ad esempio, puoi utilizzare Cloud Build per eseguire Terraform per integrare e inizializzare automaticamente nuove applicazioni.
Esegui il deployment delle applicazioni nelle relative zone di destinazione su ogni cluster, in modo che siano isolate a livello di rete e di identità. Inizializzi le zone di destinazione delle applicazioni in più ambienti utilizzando Config Sync e utilizzi Cloud Service Mesh o Ingress multi-cluster per fare in modo che i cluster di produzione sembrino un unico cluster creando una rete mesh che si estende su più cluster.
Flusso di lavoro di distribuzione del software
Un componente fondamentale della piattaforma di distribuzione del software è il sistema CI/CD. Quando i creator di piattaforme iniziano a definire il processo CI/CD, devono assicurarsi che ogni componente produca o consumi elementi che rispettino un'interfaccia standardizzata. L'utilizzo di un'interfaccia standardizzata semplifica la sostituzione dei componenti quando sul mercato viene introdotta un'implementazione migliore.
Quando crei una piattaforma per le applicazioni containerizzate, puoi utilizzare le tre interfacce standardizzate tra i componenti: repository Git, immagini Docker e manifest Kubernetes. Queste interfacce ti consentono di creare una pipeline CI/CD riutilizzabile e flessibile con un flusso di lavoro di sviluppo, compilazione e rilascio, come mostrato nel seguente diagramma:
Questo flusso di lavoro funziona nel seguente modo:
Gli sviluppatori eseguono il commit del codice dell'applicazione nei repository di codice.
Il sistema CI testa il codice, crea un artefatto dell'immagine Docker e lo archivia in un registry.
Una volta che l'elemento è pronto per il deployment, viene aggiunto un riferimento alla configurazione dell'applicazione.
La configurazione dell'applicazione viene visualizzata in un formato leggibile da Kubernetes e archiviata in un repository di codice. Gli aggiornamenti a questo repository attivano una pipeline di deployment che esegue il deployment degli elementi in un ambiente di sviluppo integrato.
Al termine dei test nell'ambiente di sviluppo integrato, gli operatori promuovono il deployment nell'ambiente di pre-produzione.
Dopo aver verificato che l'applicazione funzioni come previsto nell'ambiente di pre-produzione, gli operatori ottengono le approvazioni nella pipeline di deployment e promuovono la release nell'ambiente di produzione.
Quando gli operatori apportano modifiche alle configurazioni di base, queste modifiche vengono applicate all'intera organizzazione. Quando gli operatori eseguono il commit delle modifiche ai propri repository, gli aggiornamenti della configurazione dell'applicazione (e i successivi deployment) possono essere attivati automaticamente. In alternativa, le modifiche degli operatori possono essere rilevate al successivo dispiegamento delle modifiche degli sviluppatori.
Parallelamente, gli esperti di sicurezza possono implementare e modificare i criteri che definiscono cosa può essere implementato, quindi eseguire il commit di questi criteri nel proprio repository.
Utilizzando una metodologia GitOps, puoi richiedere un approccio dichiarativo per eventuali modifiche ad applicazioni e cluster. Con questo approccio, tutte le modifiche sono soggette a revisione e controllo prima di poter essere applicate. In questo modello dichiarativo, archivi i file di configurazione in un repository Git, che ti consente di mantenere un log delle modifiche, eseguire il rollback dei deployment non riusciti e vedere il potenziale impatto delle modifiche proposte.
Nell'architettura di riferimento associata, utilizzi kustomize per controllare le configurazioni delle applicazioni nella tua organizzazione. Lo strumento kustomize
consente agli operatori di creare le cosiddette basi di configurazioni delle applicazioni che
i tuoi team di sviluppo possono modificare senza dover aggiungere o modificare alcun codice
nella base. Definiendo le configurazioni di base, i team della piattaforma possono creare e perfezionare le best practice per l'organizzazione. Gli operatori e gli sviluppatori possono eseguire l'iterazione dei propri deployment in modo indipendente, con gli sviluppatori che applicano le best practice impostate dagli operatori. Quando gli operatori devono implementare una nuova best practice per l'organizzazione, apportano la modifica alla base, che viene richiamata automaticamente con il successivo deployment degli sviluppatori.
Repository di codice
I repository di codice sorgente sono al centro del sistema CI/CD. Operatori, sviluppatori e tecnici della sicurezza hanno ciascuno i propri repository per propagare le modifiche nella piattaforma. L'utilizzo di un repository Git come base per tutte le modifiche nel sistema offre diversi vantaggi:
Auditabilità integrata. I commit contengono informazioni su quando, cosa e chi ha modificato il sistema.
Una procedura di rollback semplificata. La funzionalità di ripristino di Git ti consente di eseguire il rollback a uno stato precedente del sistema.
Controllo delle versioni. Puoi taggare i commit Git per indicare una versione dello stato del sistema.
Transazioni. Devi risolvere esplicitamente i conflitti di stato e esaminarli prima di poter integrare le modifiche nello stato.
Il seguente diagramma mostra come i vari team interagiscono con un repository centralizzato per tutte le modifiche:
Le sezioni seguenti spiegano come operatori, sviluppatori e tecnici della sicurezza utilizzano il repository Git in un sistema CI/CD moderno.
Repository di operatori
I repository gestiti dall'operatore contengono best practice per la configurazione di CI/CD e delle applicazioni per aiutare i team a integrare le applicazioni, adottando al contempo le best practice organizzative fin dall'inizio. Con gli operatori che gestiscono i repository, gli sviluppatori possono utilizzare gli aggiornamenti alle best practice dell'organizzazione con il minor numero possibile di interruzioni del flusso di lavoro.
Gli operatori possono codificare le best practice delle loro organizzazioni in due repository. Nel primo repository gli operatori gestiscono le best practice condivise per le pipeline CI/CD. In questo repository, gli operatori forniscono agli sviluppatori una libreria di attività predefinite che possono utilizzare per creare le proprie pipeline. I repository delle applicazioni degli sviluppatori ereditano automaticamente queste attività e la logica al loro interno. Non è necessario copiarle manualmente. Ecco alcuni esempi di attività che puoi standardizzare nell'intera organizzazione:
Creazione e archiviazione di artefatti
Metodologie di test per varie lingue
Passi per il deployment
Controlli dei criteri
Analisi della sicurezza
Il secondo repository gestito dagli operatori memorizza le best practice per la configurazione di un'applicazione. Nel contesto di GKE, le best practice prevedono di garantire un modo per gestire i manifest dichiarativi nel modello di risorse Kubernetes. Questi manifest descrivono lo stato previsto dell'applicazione. Gli operatori possono creare configurazioni di base per diversi tipi di applicazioni, offrendo agli sviluppatori un percorso semplificato per il deployment delle app in base alle best practice dell'organizzazione.
Repository delle applicazioni
I repository delle applicazioni memorizzano la logica di business dell'applicazione e qualsiasi configurazione specializzata necessaria per il corretto funzionamento dell'applicazione.
Poiché gli operatori creano e gestiscono le best practice in modo codificato, gli sviluppatori possono utilizzarle. A tale scopo, gli sviluppatori fanno riferimento alle attività per la CI/CD e alle basi di applicazioni create dagli operatori nei propri repository. Dopo che gli sviluppatori hanno apportato le modifiche, gli operatori possono personalizzare ulteriormente il deployment dell'applicazione aggiungendo configurazioni specifiche per l'ambiente, ad esempio URL di database o etichette e annotazioni delle risorse.
Ecco alcuni esempi di artefatti che puoi archiviare nei repository delle applicazioni:
Codice sorgente dell'applicazione
Un
Dockerfileche descrive come creare ed eseguire l'applicazioneLa definizione della pipeline CI/CD
Estensioni o modifiche alle basi di configurazione delle applicazioni create dagli operatori
Repository Infrastructure as Code
I repository Infrastructure as Code memorizzano il codice per creare l'infrastruttura necessaria per eseguire le applicazioni. L'infrastruttura potrebbe includere piattaforme di networking e orchestrazione dei container come GKE. In genere, questi repository sono di proprietà degli amministratori dell'infrastruttura. Gli operatori possono aggiornarli per implementare le best practice.
Ecco alcuni esempi di artefatti che puoi archiviare nei repository delle applicazioni:
- Codice in un linguaggio dichiarativo (Terraform, Pulumi) che rappresenta gli oggetti dell'infrastruttura.
Script shell o Python che completano le definizioni API dichiarative.
Estensioni o modifiche ai modelli di infrastruttura di base creati dal team di infrastruttura.
Repository di configurazione e criteri
Garantire una piattaforma coerente e con una maggiore sicurezza è una priorità sia per gli operatori sia per gli addetti alla sicurezza.
Configurazione
La configurazione centralizzata ti consente di propagare le modifiche alla configurazione in tutto il sistema. Ecco alcuni elementi di configurazione comuni che puoi gestire a livello centrale:
Spazi dei nomi Kubernetes
Quote
Controllo degli accessi basato sui ruoli (RBAC)
Criteri di rete
Devi applicare in modo coerente questi tipi di configurazioni in tutti i tuoi cluster in modo che i team di applicazioni non usino o abusino dell'infrastruttura. L'utilizzo di un repository Git per archiviare la configurazione può migliorare processi come il controllo e il deployment della configurazione tramite metodi come GitOps. Strumenti come Config Sync possono semplificare il processo di applicazione uniforme delle configurazioni all'intera infrastruttura.
Norme
Poiché gli sviluppatori possono estendere le configurazioni di base create dagli operatori, è necessario un modo per limitare le risorse create nei cluster che compongono la piattaforma. In alcuni casi, puoi creare un criterio che consenta agli sviluppatori di creare risorse solo se soddisfano requisiti specifici, ad esempio la creazione di oggetti Kubernetes Service che non possono essere configurati per il bilanciamento del carico esterno.
Nell'architettura di riferimento associata, utilizzi Policy Controller per applicare i criteri.
Repository di partenza
I repository iniziali favoriscono l'adozione di best practice di CI/CD, infrastruttura e sviluppo su tutta la piattaforma. I repository iniziali possono ridurre notevolmente il costo associato all'adozione delle best practice. Le best practice, a loro volta, contribuiscono ad aumentare la velocità di introduzione delle funzionalità, l'affidabilità e la produttività del team. Nell'architettura di riferimento associata, esistono diversi repository di partenza per le configurazioni CI, CD, Kubernetes, le applicazioni di partenza e l'infrastruttura Go, Java e Python.
Integrazione continua
In genere, le organizzazioni hanno un insieme standard di attività che vengono applicate alle applicazioni durante CI;integrazione continua. Ad esempio, nell'implementazione di riferimento, il set di base delle fasi di CI è costituito da: compilazione del codice e creazione di un'immagine container. Poiché queste fasi sono definite nel repository iniziale, vengono applicate uniformemente in tutta la piattaforma. I singoli team di applicazioni possono aggiungere passaggi aggiuntivi.
Distribuzione continua
Come per la CI, il processo di CD prevede in genere una serie standard di passaggi per eseguire il deployment delle applicazioni negli ambienti di sviluppo, pre-produzione e produzione. Indipendentemente dalle metodologie di deployment utilizzate, il repository iniziale consente ai team della piattaforma di applicarle in modo uniforme ad applicazioni ed ambienti. Nell'implementazione di riferimento, la procedura di deployment include rollout per i deployment di sviluppo e di pre-produzione, un deployment di produzione su più cluster e approvazioni manuali per il deployment di produzione utilizzando Cloud Deploy.
Configurazione dell'applicazione
Affinché una piattaforma di distribuzione del software sia efficace, è necessario un modo uniforme e coerente per applicare la configurazione dell'applicazione. Utilizzando strumenti come kustomize e i repository di partenza per le configurazioni Kubernetes, le piattaforme possono fornire una base coerente per la configurazione delle applicazioni. Ad esempio, nell'implementazione di riferimento, la configurazione di base kustomize inizializza i repository dell'ambiente dell'applicazione con un insieme di configurazioni di base di cui è nota la validità. I singoli team di applicazioni possono quindi adattare le configurazioni alle proprie esigenze.
Applicazioni iniziali
Le applicazioni iniziali possono aiutarti a ridurre l'overhead associato all'adozione di best practice, ad esempio l'osservabilità e le best practice per i contenitori.
Osservabilità. Per operare in modo efficiente e contribuire a garantire l'affidabilità, le applicazioni devono tenere conto di logging, metriche e tracciamenti. Le applicazioni iniziali aiutano i team a creare framework e strategie che promuovono l'osservabilità.
Best practice per i container. Quando crei applicazioni containerizzate, devi creare immagini container piccole e pulite. Le best practice per i container includono il confezionamento di una singola applicazione in un'immagine, la rimozione di strumenti non necessari dall'immagine e il tentativo attivo di produrre immagini piccole da immagini di base minime.
L'architettura di riferimento fornisce come punto di partenza una app Go di base, un'app Java di base e un'app Python di base. Devi aggiungere applicazioni iniziali personalizzate per le lingue, gli stack tecnologici e i tipi di applicazioni sviluppati dai tuoi team.
Repository di inizio dell'infrastruttura
I repository di partenza dell'infrastruttura sono dotati del codice precompilato necessario per creare diversi componenti dell'infrastruttura. Questi repository utilizzano modelli e moduli standard, come deciso dal team di infrastruttura.
Ad esempio, nell'implementazione di riferimento, il template-piattaforma contiene il codice di avvio per creare un progetto Google Cloud , un Virtual Private Cloud e un cluster GKE. Questo modello viene in genere utilizzato dai team di infrastruttura per gestire l'infrastruttura utilizzata da più team di applicazioni come risorsa condivisa. Analogamente, l'infra-template contiene il codice di infrastruttura di base iniziale che un'applicazione potrebbe richiedere, ad esempio un database Cloud Storage o Spanner. Questo modello viene in genere utilizzato dai team di applicazioni per gestire l'infrastruttura per le loro applicazioni.
Repository di modelli condivisi
I repository di modelli condivisi forniscono modelli di attività standard che chiunque in un'organizzazione può riutilizzare. Ad esempio, i moduli Infrastructure as Code come i moduli Terraform che possono essere utilizzati per creare risorse di infrastruttura come reti e calcolo.
Zone di destinazione delle applicazioni
Quando utilizzi CI/CD condiviso, configurazione dell'applicazione condivisa e criteri e configurazione coerenti nei cluster, puoi combinare queste funzionalità per creare zone di destinazione delle applicazioni.
Una landing zone è un'entità logica bloccata che consente agli sviluppatori di eseguire il deployment e di eseguire l'iterazione sulle loro applicazioni. Le zone di destinazione delle applicazioni utilizzano i guard rail che hai implementato per consentire agli sviluppatori di operare in autonomia. Per ogni applicazione, crea uno spazio dei nomi Kubernetes in ogni cluster di ogni ambiente (ad esempio, per la produzione, lo sviluppo o l'implementazione). Questa coerenza consente agli operatori di eseguire il debug e la manutenzione degli ambienti nel tempo.
Il seguente diagramma illustra il concetto di zone di destinazione:
Modello operativo
Quando utilizzi una piattaforma di distribuzione del software con CI/CD moderna, è importante mantenere gli ambienti, l'infrastruttura e i processi coerenti e aggiornati. Pertanto, devi pianificare e scegliere con attenzione il modello operativo per la piattaforma. Puoi scegliere tra vari modelli, ad esempio cluster come servizio, blueprint o un'infrastruttura multi-tenant.
Poiché è importante mantenere un'infrastruttura coerente, limitare l'espansione e consentire ai team di concentrarsi sulla pubblicazione di applicazioni, ti consigliamo di eseguire il deployment di un'infrastruttura multi-tenant. Il deployment di applicazioni su un'infrastruttura multi-tenant elimina la necessità per i team di applicazioni di gestire l'infrastruttura e consente ai team di operatori e sicurezza di concentrarsi sul mantenimento della coerenza dell'infrastruttura.
Considerazioni per l'infrastruttura multi-tenant
Quando crei una piattaforma di distribuzione del software multi-tenant, potresti prendere in considerazione diversi aspetti da integrare nella piattaforma:
Isolamento dei carichi di lavoro. Il concetto di zone di destinazione delle applicazioni è fornire un framework per l'isolamento dei carichi di lavoro. Le zone di destinazione sono una combinazione di spazi dei nomi, criteri di rete e RBAC. Tutti questi criteri devono essere gestiti e applicati centralmente tramite Config Sync.
Monitoraggio dell'utilizzo dei tenant. Per ottenere una suddivisione dei costi per singoli spaci dei nomi ed etichette in un cluster, puoi utilizzare la misurazione dell'utilizzo di GKE. La misurazione dell'utilizzo di GKE tiene traccia delle informazioni sulle richieste di risorse e sull'utilizzo delle risorse per i carichi di lavoro di un cluster, che puoi filtrare ulteriormente in base a spazi dei nomi ed etichette. Quando attivi la misurazione dell'utilizzo di GKE nel cluster multi-tenant, i record di utilizzo delle risorse vengono scritti in una tabella BigQuery. Puoi esportare le metriche specifiche del tenant nei set di dati BigQuery nel progetto del tenant corrispondente, in modo che i revisori possano analizzarle per determinare la suddivisione dei costi.
Quote delle risorse. Per garantire che tutti i tenant che condividono un cluster abbiano accesso equo alle risorse del cluster, devi applicare le quote delle risorse. Crea una quota di risorse per ogni spazio dei nomi in base al numero di pod di ciascun tenant e alla quantità di memoria e CPU richiesta da ciascun pod.
Più cluster per ogni ambiente. Per migliorare l'affidabilità dell'applicazione e della piattaforma, devi utilizzare più cluster per ogni ambiente di preproduzione e produzione. Con più cluster disponibili, puoi implementare le applicazioni singolarmente nei cluster per livelli aggiuntivi di convalida canary. Inoltre, la presenza di più cluster semplifica i problemi relativi al ciclo di vita della gestione e degli upgrade dei cluster.
Logging e monitoraggio specifici del tenant. Per esaminare le operazioni delle loro applicazioni, gli utenti devono avere accesso a log e metriche. In un ambiente multi-tenant, il logging e il monitoraggio devono essere specifici per l'applicazione. Per le metriche e il monitoraggio, puoi utilizzare Google Cloud Managed Service per Prometheus e Grafana per ogni spazio dei nomi. Per i log, devi creare un sink per esportare le voci di log nei set di dati BigQuery, quindi filtrare i set di dati in base al nome dello spazio dei nomi del tenant. I tenant possono quindi accedere ai dati esportati in BigQuery.
Per ulteriori informazioni su un'infrastruttura multi-tenant, consulta Best practice per l'architettura multi-tenancy aziendale.
Confini di isolamento
Una piattaforma di distribuzione del software viene creata e utilizzata da più team, pertanto è importante avere confini di isolamento adeguati tra i diversi componenti della piattaforma. I confini di isolamento consentono di creare una piattaforma solida fornendo le seguenti caratteristiche:
Scollegare le responsabilità. Ogni team gestisce le risorse nei propri confini di isolamento senza preoccuparsi del resto. Ad esempio, il team di infrastruttura è responsabile solo della manutenzione dei cluster GKE. Gli operatori o gli sviluppatori sono responsabili solo della manutenzione delle pipeline CI/CD e del codice dell'applicazione.
Controllo dell'accesso granulare. Se le risorse sono separate da confini di isolamento, utilizza controllo dell'accesso granulare per limitare l'accesso.
Riduce le aree interessate. Puoi apportare modifiche in modo indipendente a un componente senza influire sugli altri componenti.
Riduce gli errori manuali. Poiché il controllo dell'accesso è granulare, puoi evitare errori manuali come il deployment accidentale in un cluster di produzione da un ambiente di sviluppo.
Questi confini di isolamento potrebbero esistere tra applicazioni, infrastrutture e applicazioni diverse o anche tra i diversi ambienti di un'applicazione.
Governance
L'obiettivo principale delle piattaforme di distribuzione del software e dei sistemi CI/CD moderni è migliorare l'efficienza del processo di distribuzione del software complessivo. Per quanto riguarda la gestione della piattaforma, devi considerare due aspetti principali: l'onboarding delle applicazioni, che in genere rientra nella categoria della governance, e lo sviluppo e la manutenzione continua della piattaforma (ovvero il trattamento della piattaforma come un prodotto).
Onboarding e gestione delle applicazioni
L'obiettivo dell'adozione di strumenti e metodologie CI/CD moderni è semplificare il processo di rilascio e l'onboarding di nuovi servizi. L'onboarding di nuove applicazioni dovrebbe essere un processo semplice che puoi eseguire con un intervento minimo dei team di operazioni e sicurezza. Ciò non significa che i team di operazioni e sicurezza non siano coinvolti, ma che il loro contributo iniziale dal punto di vista del deployment e della sicurezza viene gestito automaticamente tramite la procedura di provisioning. Una volta completato l'onboarding, i team di operazioni e sicurezza vengono inclusi naturalmente nel processo di rilascio tramite richieste di unione, aggiornamenti dei criteri e applicazione delle best practice.
Ti consigliamo di creare alcune automazioni per integrare una nuova applicazione. Potrebbe essere inclusa la creazione di repository di codice, pipeline CI/CD, zone di destinazione e qualsiasi infrastruttura richiesta per l'applicazione. L'Automation scinde le complesse dipendenze dei team di sviluppo da altri team dell'organizzazione e offre agli sviluppatori l'autonomia di gestire un'applicazione in modalità self-service. In questo modo, gli sviluppatori possono iniziare a eseguire l'iterazione sul codice dell'applicazione molto rapidamente e non perdere tempo a svolgere attività diverse dalla scrittura del codice. L'automazione dovrebbe consentire agli sviluppatori di eseguire l'applicazione in un ambiente di sviluppo. Per portare l'applicazione in ambienti di livello superiore, è necessario coinvolgere altri team e seguire la procedura di revisione.
Nell'architettura di riferimento associata, questa automazione è indicata come Application Factory.
Piattaforma come prodotto
Il flusso di lavoro CI/CD è un prodotto software, tranne per il fatto che gli utenti del prodotto sono i team di sviluppo, operazioni e sicurezza. Tenendo presente questo, la piattaforma richiede gli stessi ruoli e processi di sviluppo software, come proprietari di prodotto, marketing (anche se rivolto all'interno), cicli di feedback degli utenti e cicli di sviluppo delle funzionalità.
Eseguire il deployment di CI/CD con GKE
Quando inizi a implementare CI/CD moderne con GKE nell'organizzazione, è fondamentale scegliere le migliori applicazioni pilota. I team di sviluppo, operativo e di sicurezza devono anche prendere in considerazione altri fattori durante il loro lavoro, che vengono descritti in questa sezione.
Selezionare un'applicazione pilota
Scegliere le prime applicazioni da spostare sulla piattaforma può essere un primo passo difficile. I candidati ideali per i progetti pilota sono i servizi che elaborano i dati o gestiscono le richieste, ma non li archiviano, ad esempio i livelli di memorizzazione nella cache, i frontend web o le applicazioni di elaborazione basate su eventi. In genere, queste applicazioni sono più resistenti a brevi interruzioni del servizio ed errori di deployment che possono verificarsi ogni volta che utilizzi nuove tecniche di gestione del deployment e della configurazione. Man mano che i team acquisiscono più esperienza con CI/CD e iniziano a trarre vantaggi in termini di affidabilità e velocità, puoi iniziare a spostare i servizi di base sulla piattaforma di distribuzione del software.
Considerazioni per gli sviluppatori
Quando lavori in un processo di sviluppo CI/CD moderno, le funzionalità, le modifiche e i deployment possono avvenire con maggiore frequenza e in modo più asincrono. I team di sviluppo devono capire in che modo le modifiche influiscono sui sistemi downstream o dipendenti e come vengono testate. I percorsi di comunicazione tra i team di sviluppo, operativi e di sicurezza devono essere fluidi. È buona pratica investire in pratiche di gestione delle versioni migliori sia per le applicazioni sia per i contratti di dati con cui i diversi servizi comunicano. Oltre a migliorare metodi di comunicazione e versionamento, l'implementazione di funzionalità in piccoli pezzi e l'utilizzo di flag e branch di funzionalità può migliorare il modo in cui testare e rilasciare le funzionalità.
Considerazioni per gli operatori
Con una piattaforma di distribuzione del software, i team operativi devono funzionare più come i team di sviluppo. Invece di creare funzionalità rivolte all'esterno, stanno sviluppando strumenti e processi interni che facilitano lo sviluppo, il deployment e il funzionamento di applicazioni rivolte all'esterno. Gli strumenti della piattaforma vengono utilizzati dal team dedicato, nonché dai team di sviluppo e sicurezza. Gli operatori devono creare strumenti per facilitare l'implementazione di nuove versioni delle applicazioni e anche il loro ripristino in caso di errori o guasti dell'applicazione. Gli operatori dovrebbero inoltre porre maggiore enfasi sulla creazione di sistemi di monitoraggio e invio di avvisi per rilevare in modo proattivo gli errori e inviare avvisi di conseguenza.
Considerazioni per il team di sicurezza
I team di sicurezza devono lavorare per rendere la sicurezza più una responsabilità condivisa tra loro e i team operativi e di sviluppo. Questo pattern è comunemente chiamato spostamento a sinistra per la sicurezza, in cui la sicurezza delle informazioni (InfoSec) è coinvolta all'inizio del processo di sviluppo, gli sviluppatori lavorano con strumenti preapprovati e i test di sicurezza sono automatizzati. Oltre a queste tecniche, puoi definire e applicare i criteri di sicurezza in modo programmatico con Policy Controller. La combinazione di tecniche e strumenti consente di applicare la sicurezza in modo più proattivo.
Passaggi successivi
Prova a implementare aspetti di questa architettura CI/CD moderna.
Scopri di più sulle best practice per la configurazione della federazione delle identità.
Leggi Kubernetes e le sfide della distribuzione continua del software.
Leggi informazioni sui pattern di monitoraggio e logging per cloud ibrido e multi-cloud.