Questo documento descrive un framework per implementare i moderni processi di integrazione continua/distribuzione continua (CI/CD) 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, tra cui velocità di rilascio, affidabilità della piattaforma e 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 moderni con GKE: applica il flusso di lavoro degli sviluppatori
Questo documento è destinato agli enterprise architect e agli sviluppatori di applicazioni, nonché ai team che si occupano di sicurezza IT, DevOps e Site Reliability Engineering. Una certa esperienza con processi e strumenti di deployment automatizzati è utile per comprendere i concetti contenuti in questo documento.
Un caso per CI/CD moderno
CI/CD è un approccio di sviluppo software che consente di automatizzare le fasi di creazione, test e deployment dello sviluppo di software utilizzando una serie di strumenti e processi ripetibili.
Oltre all'automazione CI/CD, Kubernetes e i container hanno permesso alle aziende di ottenere miglioramenti senza precedenti in termini di velocità di sviluppo e deployment. Tuttavia, anche con la crescita di Kubernetes e dell'adozione dei container, molte organizzazioni non realizzano pienamente i vantaggi in termini di velocità di rilascio, stabilità ed efficienza operativa perché le loro pratiche CI/CD non sfruttano appieno Kubernetes né rispondono alle operazioni e ai problemi di sicurezza.
Un approccio CI/CD davvero moderno deve comprendere qualcosa di più dell'automazione. Per implementare completamente i miglioramenti in termini di velocità e sicurezza e 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, i metodi uniformi CI/CD e le best practice nell'implementazione, la tua organizzazione può ottenere i seguenti vantaggi in termini di sviluppo e 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 dei criteri di provisioning su tutta la piattaforma.
Semplifica l'onboarding delle applicazioni fornendo ai team progetti di base completamente funzionanti e di cui è possibile eseguire il deployment, che includono le best practice della tua organizzazione.
Riduzione del tempo necessario per ripristinare il servizio.
Gestisci tutte le configurazioni in modo dichiarativo utilizzando GitOps per semplificare audit, rollback e revisione.
Standardizza le metodologie di deployment e monitoraggio in tutta l'organizzazione per ridurre il tempo necessario per identificare i fattori che contribuiscono a un problema che influisce sui servizi.
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 migliorata delle release e il monitoraggio delle modifiche.
Implementare sistemi di protezione in modo che i team di servizio possano eseguire frequenti deployment.
Crea un processo di lancio progressivo per il deployment coerente in ambienti di pre-produzione, offrendo agli sviluppatori la fiducia necessaria per eseguire il deployment delle 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 la preparazione per un approccio moderno
Prima di implementare moderni strumenti e processi CI/CD con GKE, devi valutare se la tua organizzazione e i tuoi team sono pronti ad adottare una nuova piattaforma.
Trait organizzativi
L'adozione di una piattaforma moderna richiede il seguente supporto da parte dei team di responsabilizzazione e tecnici aziendali:
Sponsor dalla leadership. L'adozione di una piattaforma di distribuzione del software è in genere un grande impegno da parte di più team interfunzionali. Il processo di solito comporta modifiche ai ruoli e alle responsabilità, nonché alle pratiche di sviluppo del software. Per adottare questi strumenti e tecniche con successo, hai bisogno di un forte sostegno da parte di uno o più membri del team di leader. Gli sponsor della leadership più efficaci sono coloro che vedono questi cambiamenti come un processo continuo di miglioramento e vogliono dare maggiori possibilità ai propri team anziché gestirli.
Allineamento tra strategia tecnica e strategia aziendale. Consigliamo ai team aziendali e tecnici di allinearsi alle quattro principali misure di distribuzione del software definite da DevOps Research and Assessment (DORA): tempo di risposta per le modifiche, frequenza di deployment, tempi di ripristino del servizio e tasso di errore delle modifiche. L'allineamento con queste misure offre ai team aziendali e ai team tecnici un obiettivo comune, che consente 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 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 recuperare altre risorse da tutta l'organizzazione. Infine, i team devono poter eseguire il provisioning dell'infrastruttura, compresi strumenti software e risorse cloud.
Apertura nell'adozione di nuovi strumenti. Le tecniche e gli strumenti CI/CD moderni spesso compongono nuovi strumenti e processi. I team devono sperimentare con questi processi e strumenti ed essere disposti ad adottare questi strumenti. È necessario un ciclo di feedback in modo che i team della piattaforma possano sentire le informazioni dai team dell'applicazione, delle operazioni e della sicurezza che utilizzano la piattaforma.
Preparazione culturale. Per riuscire a eseguire 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 operativi e di sviluppo devono essere disposti ad assumersi una maggiore responsabilità in materia di sicurezza, mentre i team operativi e di sicurezza devono essere disposti a snellire i processi di approvazione dei cambiamenti.
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 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 hanno bisogno di una certa esperienza nell'utilizzo degli strumenti di CI (come Jenkins, TeamCity, Bamboo e CircleCI) e di eseguire alcune integrazione continua e test automatici. Consigliamo alle organizzazioni di pianificare come migliorare ulteriormente questi processi.
Automazione del deployment. I team hanno bisogno di una certa esperienza nell'automazione del deployment. Esempi di strumenti di deployment automatizzati includono gli script shell di base, Terraform, Chef o Puppet. Avere una conoscenza di base degli strumenti e dei processi di deployment automatizzato è 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. Le architetture basate sui servizi hanno dimostrato di migliorare velocità e affidabilità.
Controllo del codice sorgente moderno. I moderni strumenti di controllo del codice sorgente come Git consentono ai team di stabilire flussi di lavoro come lo sviluppo basato su trunk, i rami di funzionalità e le richieste di unione.
Progetta CI/CD moderni con GKE
Questa sezione descrive una piattaforma di distribuzione del software e i suoi componenti. Per migliorare le prestazioni di 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 inoltre l'infrastruttura necessaria per supportare il ciclo di vita di distribuzione del software e come gestire in modo coerente l'infrastruttura con GKE. Infine, questa sezione fornisce un esempio di flusso di lavoro di distribuzione del software e mostra come i repository di base 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 sulla gestione necessarie per creare la piattaforma ed eseguire le tue applicazioni.
Flusso di lavoro di distribuzione del software. Come collaborano i team per creare, testare ed eseguire il deployment del codice in modo più efficiente.
Repository di codice. Repository che eseguono diverse funzioni, tra cui l'archiviazione della logica di business effettiva, la configurazione specifica per l'applicazione e il codice per creare l'infrastruttura. Potrebbero anche essere repository di base che semplificano l'adozione di best practice e aiutano a mantenere la coerenza nei processi automatizzati.
Zone di destinazione delle applicazioni. Entità logica che consente agli sviluppatori di eseguire il deployment e l'iterazione delle loro applicazioni in modo autonomo utilizzando i guard rail che metti in atto.
Modello operativo. Strumenti tecnici, processi e metodi per la gestione dell'infrastruttura e delle applicazioni che compongono la piattaforma.
Governance. Processi e considerazioni necessarie per gestire e gestire la piattaforma di distribuzione del software.
Piattaforme di distribuzione del software
Una piattaforma di distribuzione del software unifica gli strumenti e ottimizza i processi necessari per creare, distribuire, sottoporre a deployment e utilizzare le applicazioni.
La responsabilità del mantenimento della configurazione, della stabilità, del tempo di attività e della scalabilità di un'applicazione varia a seconda degli operatori, della sicurezza e dei team di sviluppatori, ma tutti i componenti e i team devono collaborare per velocizzare le release. Sebbene questo documento descriva i metodi per migliorare la gestione del controllo del codice sorgente e l'osservabilità delle applicazioni, è incentrato principalmente sull'integrazione continua (CI), sulla distribuzione continua (CD) e sulla gestione della configurazione.
Per creare una piattaforma di distribuzione del software completa, è necessario ogni componente nel seguente diagramma:
Ognuno di questi componenti fornisce funzionalità al sistema e alle applicazioni in esecuzione sulla piattaforma:
Monitoraggio dell'infrastruttura. Il livello di base del monitoraggio necessario durante il provisioning per verificare il corretto funzionamento dei cluster Google Kubernetes Engine (GKE), delle istanze di macchine virtuali (VM) e di altre infrastrutture necessarie per il funzionamento delle applicazioni.
Orchestrazione dei container. La piattaforma che coordina il deployment e il funzionamento di applicazioni basate su container. Kubernetes, GKE o GKE Enterprise sono esempi di piattaforme per l'orchestrazione dei container.
Container Registry. Lo spazio di archiviazione e controllo dell'accesso per le immagini container.
CI. il processo di applicazione di attività automatizzate a un'applicazione prima del deployment. Le attività di CI di solito includono creazione, pacchettizzazione e test. I tipi di attività variano in base all'applicazione e all'organizzazione.
CD. Processi di deployment altamente automatizzati e applicati con alta frequenza. Le metodologie di esempio includono approvazioni manuali, deployment canary, deployment blu/verde o deployment in sequenza.
Norme. Criteri di configurazione di sicurezza e infrastruttura definiti dai team operativi e di sicurezza e applicati continuamente e applicati dalla piattaforma.
Gestione del codice sorgente. ad esempio archiviazione con controllo della versione per codice, file di configurazione e definizioni di criteri. In un sistema CI/CD moderno, la gestione del codice sorgente è in genere Git.
Gestione della configurazione. Sistema utilizzato per archiviare e applicare la configurazione dell'applicazione in ambienti diversi.
Osservabilità delle applicazioni. Logging, monitoraggio, avviso e tracciamento a livello di applicazione utilizzati da sviluppatore, operatore e team di sicurezza per risolvere i problemi e verificare il corretto funzionamento delle applicazioni.
Infrastruttura della piattaforma
Per creare una piattaforma di distribuzione del software scalabile, sono necessari cluster Kubernetes per lo sviluppo, gli ambienti di pre-produzione e più cluster di produzione. I cluster possono svolgere molte funzioni diverse:
Sviluppo. In questi cluster, gli sviluppatori eseguono deployment ad hoc delle loro applicazioni per test e sperimentazioni.
L'ambiente applicativo.
Pre-produzione. Per ogni ambiente di pre-produzione del flusso di lavoro, devi avere un cluster Kubernetes per ospitare le tue applicazioni. Questi cluster dovrebbero essere simili ai cluster di produzione per poter ridurre o eliminare le differenze tra gli ambienti e, di conseguenza, migliorare le percentuali di successo dei deployment.
Produzione. Questi cluster eseguono i carichi di lavoro di produzione. Dovresti usare più cluster distribuiti geograficamente. Ciò consente di migliorare l'affidabilità in seguito a guasti dell'infrastruttura e di ridurre i problemi delle operazioni day-2, come la scalabilità e gli upgrade dei cluster.
Il seguente diagramma mostra l'architettura di alto livello:
In questa architettura, puoi gestire i cluster per ogni ambiente tramite Config Sync. Una configurazione coerente del cluster è fondamentale perché dà ai team di sviluppo, operatore e sicurezza la certezza che gli ambienti di pre-produzione e produzione funzionino in modi simili. Puoi utilizzare Config Sync per archiviare e applicare configurazioni comuni a tutto il parco risorse di cluster. Dopo che la configurazione del cluster è standardizzata, verificabile e scalabile, puoi concentrarti sul flusso di lavoro di distribuzione del software e sull'onboarding e sul deployment delle applicazioni.
Puoi gestire i tuoi deployment nei cluster di sviluppo, gestione temporanea e 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 per un'applicazione sono isolate nell'ambiente di quell'applicazione. Inizializziamo i repository di applicazioni e configurazione usando repository di base e strumenti automatizzati. Ad esempio, puoi utilizzare Cloud Build per eseguire Terraform per integrare e inizializzare nuove applicazioni automaticamente.
Puoi eseguire il deployment delle applicazioni nelle rispettive zone di destinazione su ciascun cluster, in modo da isolare la rete e l'identità. Puoi inizializzare le zone di destinazione delle applicazioni in più ambienti utilizzando Config Sync e utilizzare Anthos Service Mesh o Ingress multi-cluster per far sembrare i cluster di produzione come un unico cluster creando un mesh di rete che copre molti cluster.
Flusso di lavoro di distribuzione del software
Un componente fondamentale della piattaforma di distribuzione del software è il sistema CI/CD. Quando gli sviluppatori di piattaforme iniziano a definire il processo CI/CD, devono assicurarsi che ogni componente produca o utilizzi artefatti conformi a un'interfaccia standardizzata. L'uso di un'interfaccia standardizzata semplifica la sostituzione dei componenti quando arriva sul mercato una migliore implementazione.
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 flusso di lavoro di sviluppo, creazione e rilascio, come illustrato nel seguente schema:
Questo flusso di lavoro funziona come segue:
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 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 funziona come previsto nell'ambiente di pre-produzione, gli operatori ottengono le approvazioni nella pipeline di deployment e promuovono la release nell'ambiente di produzione.
Le modifiche apportate dagli operatori alle configurazioni di base vengono applicate in tutta l'organizzazione. Man mano che gli operatori eseguono il commit di modifiche ai propri repository, gli aggiornamenti della configurazione delle applicazioni (e i deployment successivi) possono essere attivati automaticamente. Oppure, le modifiche degli operatori possono essere applicate la volta successiva che gli sviluppatori eseguono il deployment delle modifiche.
Parallelamente, i tecnici della sicurezza possono implementare e modificare i criteri che definiscono ciò di cui è possibile eseguire il deployment, quindi eseguire il commit di tali criteri nel loro repository di 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 controllo e revisione prima di poter essere applicate. In questo modello dichiarativo, archivi i file di configurazione in un repository Git, che ti permette 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 cosiddette basi di configurazioni delle applicazioni che i tuoi team di sviluppo possono modificare senza dover aggiungere o modificare alcun codice nella base. Definendo le configurazioni di base, i team delle piattaforme possono creare e iterare le best practice per l'organizzazione. Gli operatori e gli sviluppatori possono eseguire l'iterazione dei 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 modifiche alla base e la modifica viene applicata automaticamente insieme al deployment successivo degli sviluppatori.
Repository di codice
I repository di codice sorgente sono il fulcro del sistema CI/CD. Operatori, sviluppatori e ingegneri della sicurezza dispongono ciascuno dei propri repository per propagare le modifiche alla piattaforma. L'utilizzo di un repository Git come base per tutte le modifiche al sistema offre diversi vantaggi:
Controlli integrati. I commit contengono informazioni su quando, cosa e chi ha modificato il sistema.
Un processo di rollback semplificato. La funzionalità di ripristino di Git 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 ed esaminarli prima di poter integrare le modifiche nello stato.
Il seguente diagramma mostra in che modo i vari team interagiscono con un repository centralizzato per tutte le modifiche:
Le seguenti sezioni spiegano come operatori, sviluppatori e tecnici di sicurezza utilizzano il repository Git in un sistema CI/CD moderno.
Repository operatori
I repository gestiti dall'operatore contengono best practice per CI/CD e configurazione delle applicazioni per aiutare i tuoi team a fare l'onboarding delle applicazioni adottando al contempo best practice per l'organizzazione fin dall'inizio. Con gli operatori che gestiscono i repository, gli sviluppatori possono usufruire di qualsiasi aggiornamento delle best practice dell'organizzazione con il minor numero possibile di interruzioni del flusso di lavoro.
Gli operatori possono codificare le best practice della loro organizzazione in due repository. Nel primo repository gli operatori mantengono le best practice per le pipeline CI/CD condivise. In questo repository, gli operatori forniscono agli sviluppatori una libreria di attività predefinite che possono utilizzare per creare le loro pipeline. I repository di applicazioni degli sviluppatori ereditano automaticamente queste attività e la logica al loro interno; non è necessario copiare manualmente le attività. Ecco alcuni esempi di attività che puoi standardizzare in tutta l'organizzazione:
Creazione e archiviazione di artefatti
Metodologie di test per varie lingue
Procedura di deployment
Controlli delle norme
Analisi della sicurezza
Il secondo repository gestito dagli operatori archivia le best practice per la configurazione di un'applicazione. Nel contesto di GKE, le best practice includono la garanzia di 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 app in base alle best practice dell'organizzazione.
Repository di applicazioni
I repository di applicazioni archiviano 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 usarle. A questo scopo, gli sviluppatori fanno riferimento alle attività per 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 dell'ambiente come URL del 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
Le estensioni o le modifiche alle basi di configurazione dell'applicazione create dagli operatori
Infrastructure as Code Repository
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 linguaggio dichiarativo (Terraform, Pulumi) che rappresenta gli oggetti dell'infrastruttura.
Script shell o Python che completano le definizioni dell'API dichiarative.
Estensioni o modifiche ai modelli dell'infrastruttura di base creati dal team dell'infrastruttura.
Repository di configurazione e criteri
Garantire una piattaforma coerente e ottimizzata per la sicurezza è una priorità assoluta sia per gli operatori che per i tecnici 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:
Spazi dei nomi Kubernetes
Quote
Controlli dell'accesso basati sui ruoli (RBAC)
Criteri di rete
Dovresti applicare in modo coerente questi tipi di configurazioni in tutti i cluster, in modo che i team delle applicazioni non facciano un uso improprio o illecito dell'infrastruttura. L'utilizzo di un repository Git per archiviare la configurazione può migliorare processi come il controllo e il deployment della configurazione con metodi come GitOps. Strumenti come Config Sync possono semplificare il processo di applicazione uniforme delle configurazioni in tutta l'infrastruttura.
Criterio
Poiché gli sviluppatori possono estendere le configurazioni di base create dagli operatori, devi poter limitare le risorse create nei cluster che compongono la piattaforma. In alcuni casi, potresti creare un criterio che consente agli sviluppatori di creare risorse solo se queste soddisfano requisiti specifici, ad esempio creando oggetti di servizio Kubernetes che non possono essere configurati per il bilanciamento del carico esterno.
Nell'architettura di riferimento associata, utilizzerai Policy Controller per applicare i criteri.
Repository di base
I repository Starter favoriscono l'adozione di best practice per CI/CD, infrastruttura e sviluppo su tutta la piattaforma. I repository Starter possono ridurre notevolmente i costi associati all'adozione delle best practice. Le best practice, a loro volta, consentono di aumentare la velocità delle funzionalità, l'affidabilità e la produttività dei team. Nell'architettura di riferimento associata sono presenti diversi repository di avvio per CI, CD, configurazioni di Kubernetes, Go, Java e Python di partenza, le applicazioni e l'infrastruttura.
Integrazione continua
Le organizzazioni in genere prevedono un insieme standard di attività applicate alle applicazioni durante la CI. Ad esempio, nell'implementazione di riferimento, il set di base di fasi CI è il seguente: compilazione del codice e creazione di un'immagine container. Poiché queste fasi sono definite nel repository di base, vengono applicate in modo uniforme in tutta la piattaforma. I singoli team che si occupano della candidatura possono aggiungere ulteriori passaggi.
Distribuzione continua
Analogamente alla CI, il processo per CD prevede in genere 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 di base consente ai team della piattaforma di applicare queste metodologie in modo uniforme in tutte le applicazioni e gli ambienti. Nell'implementazione di riferimento, il processo di deployment include implementazioni di sviluppo, deployment di pre-produzione, un deployment di produzione in più cluster e approvazioni manuali per il deployment di produzione mediante 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 base 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 di kustomize inizializza i repository dell'ambiente applicativo con un set di configurazioni di base noto. I singoli team delle applicazioni possono
adattare le configurazioni alle proprie esigenze.
Applicazioni di base
Le applicazioni Starter possono aiutarti a ridurre l'overhead associato all'adozione di best practice, ad esempio osservabilità e best practice per i container.
Osservabilità. Per gestire in modo efficiente un'applicazione e garantire l'affidabilità, le applicazioni devono tenere conto di logging, metriche e tracciamento. Le applicazioni di base aiutano i team a creare in framework e strategie che promuovono l'osservabilità.
Best practice per i container. Quando crei applicazioni containerizzate, devi creare immagini container di piccole dimensioni. Le best practice per i container includono la pacchettizzazione di una singola applicazione in un'immagine, la rimozione degli strumenti superflui dall'immagine e il tentativo attivo di produrre immagini di piccole dimensioni da immagini di base minime. Per maggiori informazioni, consulta le best practice per la creazione dei container.
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. Ti consigliamo di aggiungere applicazioni iniziali personalizzate per i linguaggi, gli stack tecnologici e i tipi di applicazioni sviluppati dai tuoi team.
Repository di partenza per l'infrastruttura
I repository di base dell'infrastruttura includono il codice già scritto necessario per creare diversi componenti dell'infrastruttura. Questi repository utilizzano modelli e moduli standard, in base a quanto deciso dal team dell'infrastruttura.
Ad esempio, nell'implementazione di riferimento, 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 delle applicazioni come risorsa condivisa. Allo stesso modo, infra-template contiene il codice dell'infrastruttura iniziale di base che un'applicazione potrebbe richiedere, ad esempio un database Spanner o Cloud Storage. Questo modello viene in genere utilizzato dai team addetti all'applicazione per gestire l'infrastruttura per le loro applicazioni.
Repository di modelli condivisi
I repository di modelli condivisi forniscono modelli di attività standard che tutti gli utenti di un'organizzazione possono riutilizzare. Ad esempio, moduli Infrastructure as Code come i moduli Terraform che possono essere utilizzati per creare risorse di infrastruttura, come reti e computing.
Zone di destinazione dell'applicazione
Quando utilizzi CI/CD e configurazione di applicazioni condivise, nonché criteri e configurazioni coerenti nei cluster, puoi collegare queste funzionalità per creare zone di destinazione delle applicazioni.
Una zona di destinazione è un'entità logica bloccata che consente agli sviluppatori di eseguire il deployment delle loro applicazioni e di eseguirne l'iterazione. Le zone di destinazione dell'applicazione usano i sistemi di protezione da te predisposti per consentire agli sviluppatori di operare in modo autonomo. Per ogni applicazione, crei uno spazio dei nomi Kubernetes in ogni cluster di ogni ambiente (ad esempio per produzione, sviluppo o gestione temporanea). 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 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, ad esempio clusters as a service, progetti 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 di applicazioni in un'infrastruttura multi-tenant elimina la necessità per i team delle applicazioni di gestire l'infrastruttura e consente ai team degli operatori e della sicurezza di concentrarsi sulla coerenza dell'infrastruttura.
Considerazioni sull'infrastruttura multi-tenant
Quando crei una piattaforma di distribuzione del software multi-tenant, esistono diversi aspetti che potresti considerare di integrare nella piattaforma:
Isolamento del carico di lavoro. Le zone di destinazione delle applicazioni sono fornite un framework per isolare i 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 la suddivisione dei costi per singoli spazi 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 ulteriormente filtrare in base a spazi dei nomi ed etichette. Quando abiliti la misurazione dell'utilizzo di GKE sul cluster multi-tenant, i record sull'utilizzo delle risorse vengono scritti in una tabella BigQuery. Puoi esportare metriche specifiche per il tenant in set di dati BigQuery nel progetto tenant corrispondente, e i revisori possono analizzarle 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. Creare una quota di risorse per ogni spazio dei nomi in base al numero di pod di cui viene eseguito il deployment di ciascun tenant e alla quantità di memoria e CPU richiesta da ogni pod.
Più cluster per ogni ambiente. Per migliorare l'affidabilità delle applicazioni e della piattaforma, devi utilizzare più cluster per ogni ambiente di pre-produzione e produzione. Data la disponibilità di più cluster, puoi implementare le applicazioni singolarmente nei cluster per ottenere livelli aggiuntivi di convalida canary. Inoltre, avere più cluster riduce 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, i tenant devono accedere a log e metriche. In un ambiente multi-tenant, il logging e il monitoraggio devono essere specifici dell'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, dopodiché puoi filtrare i set di dati in base allo spazio dei nomi tenant. I tenant possono quindi accedere ai dati esportati in BigQuery.
Per maggiori informazioni su un'infrastruttura multi-tenant, consulta Best practice per architettura multi-tenancy aziendale.
Confini di isolamento
Una piattaforma di distribuzione del software viene creata e utilizzata da più team, il che rende importante stabilire limiti di isolamento adeguati tra i diversi componenti della piattaforma. I confini di isolamento aiutano a creare una piattaforma solida fornendo le seguenti caratteristiche:
Responsabilità del disaccoppiamento. 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 in base a limiti di isolamento, utilizza un controllo granulare degli accessi per limitarne l'accesso.
Riduce le aree colpite. Puoi apportare modifiche a un componente in modo indipendente 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 possono esistere tra diverse applicazioni, infrastrutture e applicazioni 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 del processo complessivo di distribuzione del software. Per gestire la piattaforma, devi tenere conto di due aspetti principali: l'onboarding delle applicazioni, che in genere rientra nella categoria di governance, lo sviluppo e la manutenzione costanti della piattaforma (ovvero, trattare la piattaforma come un prodotto).
Onboarding e gestione delle applicazioni
L'obiettivo dell'adozione di una metodologia e di strumenti CI/CD moderni è semplificare il processo di rilascio e l'onboarding di nuovi servizi. L'onboarding delle nuove applicazioni deve essere un processo semplice che puoi eseguire con un input minimo da parte dei team operativi e di sicurezza. Questo 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 attraverso il processo di provisioning. Una volta completato l'onboarding, i team operativi e di sicurezza sono inclusi naturalmente nel processo di rilascio tramite richieste di unione, aggiornamenti dei criteri e applicazione delle best practice.
È consigliabile creare un'automazione per l'onboarding di una nuova applicazione. Ciò può includere la creazione di repository di codice, pipeline CI/CD, zone di destinazione e qualsiasi infrastruttura richiesta per l'applicazione. L'Automation disaccoppia le complesse dipendenze dei team di sviluppo da altri team dell'organizzazione e fornisce agli sviluppatori l'autonomia per il self-service di un'applicazione. In questo modo gli sviluppatori possono iniziare a eseguire l'iterazione del codice dell'applicazione molto rapidamente, senza perdere tempo nell'esecuzione di 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 più elevati, è necessario coinvolgere altri team e seguire il processo di revisione.
Nell'architettura di riferimento associata, questa automazione è denominata Application Manufacturer.
Piattaforma come prodotto
Il flusso di lavoro CI/CD è un prodotto software, ad eccezione del fatto che gli utenti del prodotto sono team di sviluppo, operazioni e sicurezza. Tenendo conto di questo, la piattaforma richiede gli stessi ruoli e processi di sviluppo software, come i proprietari dei prodotti, il marketing (anche se rivolto verso l'interno), 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 moderni con GKE nell'organizzazione, scegliere le migliori applicazioni pilota è fondamentale. I team di sviluppo, operatività e sicurezza devono considerare anche altri fattori durante il loro lavoro, di cui parleremo in questa sezione.
Selezione di un'applicazione per il progetto pilota
Scegliere le prime applicazioni da spostare sulla piattaforma può essere un primo passo difficile. I servizi migliori per i progetti pilota sono servizi che elaborano i dati o gestiscono le richieste ma non li archiviano, ad esempio livelli di memorizzazione nella cache, frontend web o applicazioni di elaborazione basata su eventi. In genere, queste applicazioni sono più resistenti a piccoli tempi di inattività ed errori di deployment che possono verificarsi ogni volta che utilizzi nuove tecniche di deployment e gestione della configurazione. Man mano che i team acquisiscono maggiore esperienza con CI/CD e iniziano a usufruire dei 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, le funzionalità, le modifiche e i deployment possono avvenire sia con maggiore frequenza che in modo più asincrono. I team di sviluppo devono rendersi conto dell'impatto dei cambiamenti sui sistemi downstream o dipendenti e in che modo vengono testati. I percorsi di comunicazione tra i team di sviluppo, operazioni e sicurezza devono essere fluidi. È buona norma investire in pratiche di controllo delle versioni migliori sia per le applicazioni sia per i contratti sui dati mediante i quali comunicano i diversi servizi. Oltre al miglioramento dei metodi di comunicazione e del controllo delle versioni, l'implementazione delle funzionalità in piccole parti e l'utilizzo di rami e flag delle funzionalità può migliorare le modalità di test e rilascio delle funzionalità.
Considerazioni sull'operatore
Con una piattaforma di distribuzione del software, i team operativi devono funzionare in modo più simile ai team di sviluppo. Invece di creare funzionalità rivolte all'esterno, stanno creando 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 proprio team e dai team di sviluppo e sicurezza. Gli operatori devono creare strumenti che agevolino l'implementazione di nuove versioni delle applicazioni e il loro ripristino in caso di errori dell'applicazione o di deployment. Gli operatori dovrebbero inoltre porre maggiore enfasi sulla creazione di sistemi di monitoraggio e avviso per rilevare in modo proattivo gli errori e creare avvisi di conseguenza.
Considerazioni del team di sicurezza
I team di sicurezza dovrebbero far sì che la sicurezza diventi una responsabilità condivisa tra loro e i team operativi e di sviluppo. Questo schema viene comunemente chiamato shifting left sulla sicurezza, in cui la sicurezza delle informazioni (InfoSec) viene coinvolta nelle 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 in modo programmatico i criteri di sicurezza con Policy Controller. La combinazione di tecniche e strumenti rende l'applicazione della sicurezza in una posizione più proattiva.
Passaggi successivi
Prova a implementare gli aspetti di questa moderna architettura CI/CD.
Scopri di più sulle best practice per la configurazione della federazione delle identità.
Leggi Kubernetes e le sfide della distribuzione continua del software.
Leggi i pattern di logging e monitoraggio ibridi e multi-cloud.