Questo documento descrive un framework per l'implementazione di processi moderni di integrazione continua/distribuzione continua (CI/CD) su una piattaforma di distribuzione 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, inclusi la velocità di rilascio, l'affidabilità della piattaforma e il tempo di ripristino dagli errori.
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 è destinato ad architetti aziendali e sviluppatori di applicazioni, nonché a team di sicurezza IT, DevOps e Site Reliability Engineering. Una certa esperienza con gli strumenti e i processi di deployment automatico è utile per comprendere i concetti descritti in questo documento.
Un caso per CI/CD moderno
CI/CD è un approccio di sviluppo software che ti consente di automatizzare le fasi di creazione, test e deployment dello sviluppo software utilizzando una serie di strumenti e processi ripetibili.
Oltre all'automazione CI/CD, Kubernetes e i container hanno consentito alle aziende 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 si rendono conto appieno dei vantaggi in termini di velocità di rilascio, stabilità ed efficienza operativa perché le loro pratiche CI/CD non sfruttano appieno Kubernetes o non risolvono i problemi operativi e di sicurezza.
Un approccio CI/CD veramente moderno deve comprendere più della semplice automazione. Per realizzare appieno i miglioramenti in termini di velocità e sicurezza e per utilizzare 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 operativi e di sicurezza di creare e aggiornare le best practice per il provisioning delle applicazioni e delle policy di provisioning sulla piattaforma.
Semplifica l'onboarding delle applicazioni fornendo ai team progetti iniziali completamente funzionanti e implementabili che incorporano le best practice della tua organizzazione.
Riduzione del tempo necessario per ripristinare il servizio.
Gestisci tutta la configurazione in modo dichiarativo utilizzando GitOps per semplificare il controllo, il rollback e la revisione.
Standardizza le metodologie di deployment e monitoraggio in tutta l'organizzazione per ridurre il tempo necessario a 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 iterazioni in modo indipendente nelle proprie sandbox di sviluppo (o landing zone) senza interferire tra loro.
Utilizza GitOps per il deployment, una migliore gestione delle release e il monitoraggio delle modifiche.
Implementa misure di salvaguardia in modo che i team di assistenza siano autorizzati a eseguire spesso il deployment.
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 eseguire il deployment delle modifiche in produzione.
Per scoprire come questi vantaggi e concetti vengono realizzati con GKE e CI/CD, consulta gli altri documenti di questa serie:
Valuta la preparazione per un approccio moderno
Prima di implementare strumenti e processi CI/CD moderni con GKE, devi valutare se la tua organizzazione e i tuoi team sono pronti ad adottare una nuova piattaforma.
Tratti organizzativi
L'adozione di una piattaforma moderna richiede il seguente supporto da parte della leadership aziendale e dei team tecnici:
Sponsor della leadership. L'adozione di una piattaforma di distribuzione del software è in genere un grande sforzo intrapreso da più team cross-funzionali. Il processo di solito comporta modifiche a ruoli e responsabilità, nonché alle pratiche di sviluppo software. Per adottare con successo questi strumenti e queste tecniche, devi ricevere un forte sostegno da uno o più membri del team di leadership. Gli 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 tuoi team aziendali e tecnici alle quattro misure chiave di distribuzione del software definite da DevOps Research and Assessment (DORA): lead time per le modifiche, frequenza di deployment, tempo per ripristinare il servizio e tasso di errore delle modifiche. L'allineamento su queste misure offre ai team aziendali e tecnici un obiettivo comune, consentendo loro di calcolare congiuntamente il ritorno sull'investimento, adeguare il tasso di variazione e modificare il livello di investimento.
Risorse. Per avere successo, i team che sviluppano pratiche CI/CD moderne e creano toolchain hanno bisogno delle risorse necessarie: tempo, persone e infrastruttura. 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 coinvolgere 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.
Apertura all'adozione di nuovi strumenti. Le moderne tecniche e strumenti CI/CD spesso sono accompagnati da nuovi strumenti e processi. I team devono sperimentare questi processi e strumenti ed essere aperti ad adottarli. È necessario un ciclo di feedback in modo che i team della piattaforma possano ricevere feedback dai team di applicazioni, operazioni e sicurezza che utilizzano la piattaforma.
Preparazione culturale. Per riuscire a eseguire il deployment e l'adozione di 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 lavorano insieme. Ad esempio, i team di sviluppo e operazioni devono essere disposti ad assumersi una maggiore responsabilità per la sicurezza, mentre i team di sicurezza e operazioni 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 nei seguenti modi:
Esperienza con i container. I team che adottano approcci CI/CD moderni hanno bisogno di una certa esperienza con i container. 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 esperienza nell'utilizzo di strumenti CI (come Jenkins, TeamCity, Bamboo e CircleCI) e nell'esecuzione di alcune attività di integrazione continua e test automatici. Consigliamo alle organizzazioni di pianificare come migliorare ulteriormente questi processi.
Automazione del deployment. I team devono avere una certa esperienza con l'automazione del deployment. Esempi di strumenti di deployment automatizzato includono script shell di base, Terraform, Chef o Puppet. Avere una conoscenza di base degli strumenti e dei processi 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 architetture più modulari e orientate ai servizi deve essere un obiettivo a lungo termine delle organizzazioni che vogliono adottare strumenti e tecniche CI/CD moderni con GKE. È stato dimostrato che le architetture basate sui servizi migliorano la velocità e l'affidabilità.
Controllo del codice sorgente moderno. Strumenti di controllo del codice sorgente moderni come Git consentono ai team di stabilire workflow come lo sviluppo basato sul trunk, i rami delle 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 di distribuzione del software, devi implementare CI/CD e altre best practice tecniche che consentono ai team di eseguire rilasci rapidamente e operare in modo efficiente.
Questa sezione descrive anche l'infrastruttura necessaria per supportare il ciclo di vita della distribuzione del software e come gestire in modo coerente questa infrastruttura 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 esaminati i seguenti aspetti legati alla progettazione:
Piattaforma di distribuzione del software. Il framework e le funzionalità tecniche che costituiscono le basi di un processo di rilascio di applicazioni affidabile e ad alta velocità.
Infrastruttura della piattaforma. I componenti dell'infrastruttura e le considerazioni sulla gestione necessarie per creare la piattaforma ed eseguire le applicazioni.
Flusso di lavoro di distribuzione del software. Come i team collaborano per creare, testare ed eseguire il deployment del 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 creare l'infrastruttura. Potrebbero anche essere repository iniziali che facilitano l'adozione delle best practice e contribuiscono a mantenere la coerenza nei processi automatizzati.
Zone di destinazione dell'applicazione. Entità logica che consente agli sviluppatori di eseguire il deployment e l'iterazione autonomi delle loro applicazioni utilizzando le protezioni che hai implementato.
Modello operativo. Strumenti, processi e metodi tecnici per gestire l'infrastruttura e le applicazioni che compongono la piattaforma.
Governance. Processi e considerazioni che devi 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 i processi necessari per creare, distribuire, eseguire il deployment e gestire le applicazioni.
La responsabilità della manutenzione della configurazione, della stabilità, dell'uptime e della scalabilità di un'applicazione varia a seconda degli operatori, della sicurezza e dei team di sviluppo, ma tutti i componenti e i team devono collaborare per accelerare le release. Sebbene questo documento descriva i metodi per migliorare la gestione del controllo del codice sorgente 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 nel seguente diagramma:
Ciascuno di questi componenti fornisce funzionalità al sistema e alle applicazioni in esecuzione sulla piattaforma:
Monitoraggio dell'infrastruttura. Il livello base di monitoraggio necessario durante il provisioning per verificare il corretto funzionamento di cluster Google Kubernetes Engine (GKE), istanze di macchine virtuali (VM) e altre infrastrutture necessarie per il funzionamento delle applicazioni.
Orchestrazione dei container. La piattaforma che coordina il deployment e il funzionamento delle applicazioni basate su container. Esempi di piattaforme per l'orchestrazione dei container sono Kubernetes, GKE o GKE Enterprise.
Container Registry. L'archiviazione e il controllo dell'accesso per le immagini container.
CI. Il processo di applicazione delle attività automatizzate a un'applicazione prima del deployment. Le attività di CI in genere includono la creazione, il packaging e il 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 blu/verde o deployment in sequenza.
Norme. Policy di configurazione della sicurezza e dell'infrastruttura definite dai team addetti alle operazioni e alla sicurezza e applicate e applicate continuamente dalla piattaforma.
Gestione del codice sorgente. Ad esempio, l'archiviazione con controllo delle versioni per codice, file di configurazione e definizioni dei criteri. In un moderno sistema CI/CD, la gestione del codice sorgente è in genere Git.
Gestione della configurazione. Il sistema utilizzato per archiviare e applicare la configurazione dell'applicazione per ambienti diversi.
Osservabilità dell'applicazione. La registrazione, il monitoraggio, gli avvisi e la tracciabilità a livello di applicazione che gli sviluppatori, gli operatori e i team di sicurezza utilizzano 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 gli ambienti di sviluppo, pre-produzione e più cluster di produzione. I cluster possono svolgere molte funzioni diverse:
Sviluppo. In questi cluster, gli sviluppatori eseguono implementazioni ad hoc delle loro applicazioni per test e sperimentazioni.
L'ambiente dell'applicazione.
Pre-produzione. Per ogni ambiente di pre-produzione 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 tuoi carichi di lavoro di produzione. Devi utilizzare più cluster distribuiti geograficamente. In questo modo migliora l'affidabilità in caso di errori dell'infrastruttura e semplifica le operazioni del giorno 2, come gli upgrade e lo 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 dei cluster è fondamentale perché consente ai team di sviluppo, operatori e sicurezza di avere la certezza che gli ambienti di pre-produzione e produzione funzionino in modo simile. Puoi utilizzare Config Sync per archiviare e applicare configurazioni comuni in tutto il parco risorse di cluster. Una volta standardizzata, verificabile e scalabile la configurazione del cluster, puoi concentrarti sul flusso di lavoro di distribuzione del software e sull'onboarding e il deployment delle applicazioni.
Gestisci i deployment nei cluster di sviluppo, gestione temporanea e produzione tramite le pipeline CI/CD dell'applicazione. Il sistema di 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 per un'applicazione sono isolate nell'ambiente dell'applicazione. Inizializzi i repository di applicazioni e configurazioni utilizzando repository iniziali e strumenti automatizzati. Ad esempio, puoi utilizzare Cloud Build per eseguire Terraform per eseguire l'onboarding e inizializzare automaticamente nuove applicazioni.
Esegui il deployment delle applicazioni nelle rispettive landing zone su ogni cluster, in modo che le applicazioni siano isolate a livello di rete e identità. Inizializzi le zone di destinazione delle applicazioni in tutti gli ambienti utilizzando Config Sync e utilizzi Cloud Service Mesh o Multi Cluster Ingress per far sembrare i cluster di produzione un unico cluster creando un mesh di rete 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 builder di piattaforme iniziano a definire il processo CI/CD, devono assicurarsi che ogni componente produca o utilizzi artefatti che rispettino un'interfaccia standardizzata. L'utilizzo di un'interfaccia standardizzata semplifica la sostituzione dei componenti quando sul mercato viene lanciata un'implementazione migliore.
Quando crei una piattaforma per 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 workflow 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 immagine Docker e lo archivia in un registro.
Quando l'artefatto è 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 artefatti in un ambiente di sviluppo integrato.
Una volta completati i 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 a tutta l'organizzazione. Man mano che gli operatori eseguono il commit delle modifiche ai propri repository, gli aggiornamenti della configurazione dell'applicazione (e le implementazioni successive) possono essere attivati automaticamente. In alternativa, le modifiche degli operatori possono essere rilevate la volta successiva che gli sviluppatori implementano le modifiche.
Parallelamente, gli ingegneri della sicurezza possono implementare e modificare i criteri che definiscono cosa può essere implementato e poi eseguirne il commit nel repository dei criteri.
Utilizzando una metodologia GitOps, puoi richiedere un approccio dichiarativo per qualsiasi modifica ad applicazioni e cluster. Con questo approccio, tutte le modifiche sono soggette a audit e revisione prima di poter essere applicate. In questo modello dichiarativo, memorizzi 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 cambiare alcun codice nella
base. Definendo le configurazioni di base, i team della piattaforma possono creare e ripetere
le best practice per l'organizzazione. Operatori e sviluppatori possono eseguire iterazioni sui deployment in modo indipendente, con gli sviluppatori che applicano le best practice configurate dagli operatori. Quando gli operatori devono implementare una nuova best practice per l'organizzazione, apportano la modifica nella base e la modifica viene inserita automaticamente nel successivo deployment degli sviluppatori.
repository di codice
I repository del codice sorgente sono al centro del sistema CI/CD. Operatori, sviluppatori e ingegneri 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:
Controllabilità 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 tornare 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 rivederli prima di poter integrare le modifiche nello stato.
Il seguente diagramma mostra come interagiscono vari team con un repository centralizzato per tutte le modifiche:
Le sezioni seguenti spiegano come operatori, sviluppatori e ingegneri della sicurezza utilizzano il repository Git in un moderno sistema CI/CD.
Repository di operatori
I repository gestiti dall'operatore contengono best practice per CI/CD e configurazione delle applicazioni per aiutare i tuoi team a eseguire l'onboarding delle applicazioni adottando fin dall'inizio le best practice dell'organizzazione. Con gli operatori che gestiscono i repository, gli sviluppatori possono utilizzare gli aggiornamenti alle best practice dell'organizzazione con il minor impatto possibile sul loro flusso di lavoro.
Gli operatori possono codificare le best practice delle loro organizzazioni in due repository. Il primo repository è quello in cui gli operatori mantengono le best practice della pipeline CI/CD condivisa. In questo repository, gli operatori forniscono agli sviluppatori una libreria di attività predefinite che possono utilizzare per creare le loro pipeline. I repository delle applicazioni degli sviluppatori ereditano automaticamente queste attività e la logica al loro interno; le attività non devono essere copiate manualmente. Ecco alcuni esempi di attività che puoi standardizzare in tutta l'organizzazione:
Creazione e archiviazione di artefatti
Metodologie di test per varie lingue
Passi per il deployment
Controlli delle norme
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, fornendo agli sviluppatori un percorso semplificato per il deployment delle loro app in base alle best practice dell'organizzazione.
Repository delle applicazioni
I repository delle applicazioni archiviano la logica di business dell'applicazione e qualsiasi configurazione specializzata necessaria per il corretto funzionamento dell'applicazione.
Man mano che gli operatori creano e mantengono le best practice in modo codificato, gli sviluppatori possono utilizzarle. A questo scopo, gli sviluppatori fanno riferimento alle attività per CI/CD e alle basi dell'applicazione che gli operatori hanno creato nei propri repository. Dopo che gli sviluppatori hanno apportato le modifiche, gli operatori possono personalizzare ulteriormente il deployment dell'applicazione aggiungendo configurazioni specifiche dell'ambiente, ad esempio URL di database o etichette e annotazioni delle risorse.
Ecco alcuni esempi di artefatti che puoi archiviare nei repository di applicazioni:
Codice sorgente dell'applicazione
Un
Dockerfileche descrive come creare ed eseguire l'applicazioneDefinizione 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 archiviano 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 di applicazioni:
- Codice del 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 dell'infrastruttura.
Repository di configurazione e policy
Garantire una piattaforma coerente e con maggiore sicurezza è una priorità assoluta sia per gli operatori sia per gli ingegneri della sicurezza.
Configurazione
La configurazione centralizzata consente di propagare le modifiche alla configurazione in tutto il sistema. Alcuni elementi di configurazione comuni che puoi gestire centralmente includono quanto segue:
Spazi dei nomi Kubernetes
Quote
Controlli dell'accesso basati 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 delle applicazioni non utilizzino in modo improprio o abusivo l'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 nell'infrastruttura.
Norme
Poiché gli sviluppatori possono estendere le configurazioni di base create dagli operatori, è necessario un modo per vincolare le risorse create nei cluster che compongono la piattaforma. In alcuni casi, potresti creare una policy che consenta agli sviluppatori di creare risorse solo se soddisfano requisiti specifici, ad esempio la creazione di oggetti del servizio Kubernetes che non possono essere configurati per il bilanciamento del carico esterno.
Nell'architettura di riferimento associata, utilizzi Policy Controller per applicare i criteri.
Repository iniziali
I repository iniziali facilitano l'adozione di best practice di CI/CD, infrastruttura e sviluppo sulla piattaforma. I repository iniziali possono ridurre notevolmente i costi associati all'adozione delle best practice. Le best practice, a loro volta, contribuiscono ad aumentare la velocità delle funzionalità, l'affidabilità e la produttività del team. Nell'architettura di riferimento associata, sono disponibili più repository di avvio per configurazioni CI, CD e Kubernetes, applicazioni e infrastrutture di avvio Go, Java e Python.
Integrazione continua
Le organizzazioni in genere hanno un insieme standard di attività che vengono applicate alle applicazioni duranteCI9;integrazione continua. Ad esempio, nell'implementazione di riferimento, l'insieme di base di fasi CI è il seguente: compila il codice e crea un'immagine container. Poiché queste fasi sono definite nel repository iniziale, vengono applicate in modo uniforme in tutta la piattaforma. I singoli team di applicazioni possono aggiungere passaggi aggiuntivi.
Distribuzione continua
Analogamente a CI, il processo per CD in genere prevede una serie standard di passaggi per 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 applicare uniformemente queste metodologie a tutte le applicazioni e gli ambienti. Nell'implementazione di riferimento, il processo di deployment include implementazioni di sviluppo e pre-produzione, un'implementazione di produzione in più cluster e approvazioni manuali per l'implementazione 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 repository di avvio 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 noto e valido. I singoli team di applicazioni possono quindi adattare le
configurazioni alle loro esigenze.
Applicazioni di base
Le applicazioni iniziali possono aiutarti a ridurre l'overhead associato all'adozione delle best practice, ad esempio l'osservabilità e le best practice per i container.
Osservabilità. Per funzionare in modo efficiente e 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 packaging di una singola applicazione in un'immagine, la rimozione degli strumenti non necessari dall'immagine e il tentativo attivo di produrre immagini di piccole dimensioni da immagini di base minimali.
L'architettura di riferimento fornisce un'app Go di base, un'app Java di base e un'app Python di base come punto di partenza. Devi aggiungere applicazioni iniziali personalizzate per le lingue, gli stack tecnologici e i tipi di applicazioni sviluppati dai tuoi team.
Repository di base dell'infrastruttura
I repository di avvio dell'infrastruttura includono il codice precompilato necessario per creare diversi componenti dell'infrastruttura. Questi repository utilizzano modelli e moduli standard come deciso dal team dell'infrastruttura.
Ad esempio, nell'implementazione di riferimento, il platform-template contiene il codice iniziale per creare un progetto Google Cloud , un Virtual Private Cloud e un cluster GKE. Questo modello viene in genere utilizzato dai team dell'infrastruttura per gestire l'infrastruttura utilizzata da più team di applicazioni come risorsa condivisa. Allo stesso modo, infra-template contiene il codice di base dell'infrastruttura 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 delle 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, moduli Infrastructure as Code come i moduli Terraform che possono essere utilizzati per creare risorse dell'infrastruttura come reti e risorse di calcolo.
Zone di destinazione delle applicazioni
Quando utilizzi CI/CD condivisa, configurazione dell'applicazione condivisa e criteri e configurazione coerenti tra i cluster, puoi combinare queste funzionalità per creare landing zone delle applicazioni.
Una landing zone è un'entità logica bloccata che consente agli sviluppatori di eseguire il deployment e l'iterazione delle loro applicazioni. Le zone di destinazione delle applicazioni utilizzano le misure di protezione che hai implementato in modo che gli sviluppatori possano operare in autonomia. Per ogni applicazione, crea uno spazio dei nomi Kubernetes in ogni cluster di ogni ambiente (ad esempio, per produzione, sviluppo o gestione temporanea). Questa coerenza aiuta gli operatori a eseguire il debug e la manutenzione degli ambienti nel tempo.
Il seguente diagramma illustra il concetto di zone di destinazione:
Modello operativo
Quando gestisci una piattaforma di distribuzione del software con CI/CD moderno, è 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, come cluster as a service, blueprint o un'infrastruttura multi-tenant.
Poiché è importante mantenere un'infrastruttura coerente, limitare la proliferazione e consentire ai team di concentrarsi sulla distribuzione delle applicazioni, ti consigliamo di eseguire il deployment di un'infrastruttura multi-tenant. Il deployment delle 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, ci sono diverse cose che potresti prendere in considerazione di integrare nella piattaforma:
Isolamento del carico di lavoro. Il concetto di zone di destinazione delle applicazioni è quello di fornire un framework per isolare i carichi di lavoro. Le landing zone 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 del tenant. Per ottenere suddivisioni dei costi per singoli spazi dei nomi ed etichette in un cluster, puoi utilizzare la misurazione dell'utilizzo di GKE. La misurazione dell'utilizzo 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 abiliti la misurazione dell'utilizzo di GKE sul cluster multi-tenant, i record di utilizzo delle risorse vengono scritti in una tabella BigQuery. Puoi esportare metriche specifiche del tenant nei set di dati BigQuery nel progetto tenant corrispondente e gli revisori possono quindi analizzare queste metriche per determinare le suddivisioni dei costi.
Quote delle risorse. Per garantire che tutti i tenant che condividono un cluster abbiano un 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 che ogni tenant esegue il deployment e alla quantità di memoria e CPU richiesta da ogni pod.
Più cluster per ogni ambiente. Per migliorare l'affidabilità dell'applicazione e della piattaforma, devi utilizzare più cluster per ogni ambiente di pre-produzione e produzione. Con più cluster disponibili, puoi implementare le applicazioni singolarmente nei cluster per ulteriori livelli di convalida canary. Inoltre, la presenza di più cluster attenua i problemi relativi al ciclo di vita della gestione e degli upgrade dei cluster.
Logging e monitoraggio specifici per il tenant. Per esaminare il funzionamento delle loro applicazioni, i tenant hanno bisogno di accedere 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 e poi filtrare i set di dati per spazio dei nomi tenant. Gli inquilini possono quindi accedere ai dati esportati in BigQuery.
Per saperne di più su un'infrastruttura multi-tenant, consulta Best practice per architettura multi-tenancy aziendale.
Confini di isolamento
Una piattaforma di distribuzione del software è creata e utilizzata da più team, il che rende importante disporre di limiti di isolamento adeguati tra i diversi componenti della piattaforma. I confini di isolamento contribuiscono a creare una piattaforma solida fornendo le seguenti caratteristiche:
Separazione delle responsabilità. Ogni team gestisce le risorse nei propri confini di isolamento senza preoccuparsi del resto. Ad esempio, il team dell'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 limiti di isolamento, utilizza controllo dell'accesso granulare per limitare l'accesso.
Riduce le aree interessate. Puoi apportare modifiche a un componente in modo indipendente senza influire sugli altri.
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 possono 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 moderni sistemi CI/CD è migliorare l'efficienza dell'intero processo di distribuzione del software. Per quanto riguarda la gestione della piattaforma, devi considerare due aspetti principali: l'onboarding delle applicazioni, che rientra generalmente nella categoria della governance, e lo sviluppo e la manutenzione continui della piattaforma (ovvero trattare la piattaforma come un prodotto).
Inserimento 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 deve essere un processo semplice che puoi eseguire con un input minimo da parte dei team operativi e di sicurezza. Ciò non significa che i team operativi e di sicurezza non siano coinvolti, ma che il loro input iniziale dal punto di vista del deployment e della sicurezza viene gestito automaticamente tramite il processo di provisioning. Una volta eseguito l'onboarding, i team operativi e di sicurezza vengono inclusi naturalmente nel processo di rilascio tramite richieste di unione, aggiornamenti delle norme e applicazione delle best practice.
È consigliabile creare un'automazione per integrare una nuova applicazione. Ciò potrebbe includere la creazione di repository di codice, pipeline CI/CD, landing zone e qualsiasi infrastruttura richiesta per l'applicazione. L'Automation disaccoppia le complesse dipendenze dei team di sviluppo da altri team dell'organizzazione e offre agli sviluppatori l'autonomia di gestire autonomamente un'applicazione. 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, devono essere coinvolti altri team e deve essere seguito il processo di revisione.
Nell'architettura di riferimento associata, questa automazione è denominata Application Factory.
Piattaforma come prodotto
Il flusso di lavoro CI/CD è un prodotto software, tranne per il fatto che gli utenti del prodotto sono team di sviluppo, operazioni e sicurezza. Tenendo presente questo, la piattaforma richiede gli stessi ruoli e processi di sviluppo software, come i product owner, il marketing (anche se rivolto internamente), i cicli di feedback degli utenti e i cicli di sviluppo delle funzionalità.
Esegui il deployment di CI/CD con GKE
Quando inizi a eseguire il deployment di CI/CD moderne con GKE nell'organizzazione, la scelta delle migliori applicazioni pilota è fondamentale. I team di sviluppo, operazioni e sicurezza devono considerare anche altri fattori durante il loro lavoro, che vengono discussi in questa sezione.
Selezionare una domanda di partecipazione al programma pilota
La scelta delle prime applicazioni da spostare sulla piattaforma può essere un primo passo difficile. I servizi che elaborano dati o gestiscono richieste, ma non archiviano dati, sono buoni candidati per i progetti pilota, ad esempio livelli di memorizzazione nella cache, frontend web o applicazioni di elaborazione basate su eventi. In genere, queste applicazioni sono più resistenti a brevi periodi di inattività e a 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 maggiore esperienza con CI/CD e iniziano a riscontrare vantaggi in termini di affidabilità e velocità, puoi iniziare a spostare i servizi principali sulla piattaforma di distribuzione del software.
Considerazioni per gli sviluppatori
Quando lavori in un processo di sviluppo CI/CD moderno, funzionalità, modifiche e implementazioni possono verificarsi sia con maggiore frequenza sia in modo più asincrono. I team di sviluppo devono rendersi conto di come le modifiche influiscono sui sistemi downstream o dipendenti e di come vengono testate. I percorsi di comunicazione tra i team di sviluppo, operativi e di sicurezza devono essere fluidi. È consigliabile investire in pratiche di controllo delle versioni migliori sia per le applicazioni sia per i contratti di dati con cui comunicano i diversi servizi. Oltre a migliorare i metodi di comunicazione e il controllo delle versioni, l'implementazione delle funzionalità in piccoli pezzi e l'utilizzo di rami e flag delle funzionalità possono migliorare il modo in cui testi e rilasci le funzionalità.
Considerazioni per gli operatori
Con una piattaforma di distribuzione del software, i team delle operazioni devono funzionare più come i team di sviluppo. Anziché creare funzionalità rivolte all'esterno, creano strumenti e processi interni che facilitano lo sviluppo, l'implementazione e il funzionamento di applicazioni rivolte all'esterno. Gli strumenti della piattaforma vengono utilizzati dal team interno, nonché dai team di sviluppo e sicurezza. Gli operatori devono creare strumenti per facilitare l'implementazione di nuove versioni delle applicazioni e anche il rollback in caso di errori dell'applicazione o errori di deployment. Gli operatori dovrebbero anche concentrarsi maggiormente sulla creazione di sistemi di monitoraggio e avviso per rilevare in modo proattivo i guasti e inviare avvisi di conseguenza.
Considerazioni per il team della sicurezza
I team di sicurezza devono lavorare per rendere la sicurezza una responsabilità più condivisa tra loro e i team operativi e di sviluppo. Questo pattern è comunemente chiamato spostamento a sinistra in materia di sicurezza, in cui la sicurezza delle informazioni (InfoSec) è coinvolta fin dalle prime fasi 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 programmaticamente i criteri di sicurezza con Policy Controller. La combinazione di tecniche e strumenti rende l'applicazione della sicurezza più proattiva.
Passaggi successivi
Prova a implementare aspetti di questa moderna architettura CI/CD.
Scopri di più sulle best practice per la configurazione della federazione delle identità.
Leggi Kubernetes and the challenges of continuous software delivery.
Leggi di più sui pattern di logging e monitoraggio per cloud ibrido e multi-cloud.