CI/CD moderna con GKE: un framework di distribuzione del software

Standard

---

Questo documento descrive un framework per l'implementazione di processi moderni 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 la velocità di rilascio, l'affidabilità della piattaforma e i tempi 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 moderna con GKE: crea un sistema CI/CD (architettura di riferimento)

• Approccio CI/CD moderno con GKE: applica il flusso di lavoro per sviluppatori

Questo documento è destinato agli Enterprise Architect e agli sviluppatori di applicazioni, nonché ai team di sicurezza IT, DevOps e Site Reliability Engineering. Una certa esperienza con gli strumenti e i processi di deployment automatizzati è utile per comprendere i concetti trattati 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 del 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. Eppure, anche con la crescita dell'adozione di Kubernetes e dei container, molte organizzazioni non comprendono appieno i vantaggi in termini di velocità di rilascio, stabilità ed efficienza operativa perché le loro pratiche CI/CD non sfruttano appieno Kubernetes né affrontano operazioni e problemi di sicurezza.

Un approccio CI/CD davvero moderno deve includere qualcosa in più dell'automazione. Per implementare 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, i metodi CI/CD uniformi e le best practice di implementazione, la tua organizzazione può usufruire dei seguenti vantaggi in termini di sviluppo e operazioni:

• Riduzione dei tempi di risposta per le modifiche.

  • Consenti ai team operativi e di sicurezza di creare e aggiornare best practice per il provisioning delle applicazioni e i criteri di provisioning sulla piattaforma.

  • Semplifica l'onboarding delle applicazioni fornendo ai team progetti di base completamente funzionanti e di cui è possibile eseguire il deployment, in cui sono integrate 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.

  • Standardizzare 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.

  • Usa GitOps per il deployment, per una migliore gestione delle release e per il monitoraggio delle modifiche.

  • Implementare sistemi di protezione in modo che i team di servizio abbiano la possibilità di eseguire con frequenza il deployment.

  • Crea un processo di implementazione progressiva per eseguire il deployment in modo coerente negli ambienti di pre-produzione, dando agli sviluppatori la sicurezza necessaria per eseguire il deployment delle modifiche in produzione.

Per vedere come vengono realizzati questi vantaggi e concetti con GKE e CI/CD, vedi gli altri documenti di questa serie:

• Approccio CI/CD moderno con GKE: creazione di un sistema CI/CD

• Approccio CI/CD moderno con GKE: applicazione del flusso di lavoro per sviluppatori

Valutare l'idoneità 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.

Caratteristiche organizzative

L'adozione di una piattaforma moderna richiede il seguente supporto da parte dei team tecnici e di leadership aziendale:

• Sponsor leader. L'adozione di una piattaforma di distribuzione del software è in genere un grande impegno intrapreso da più team interfunzionali. Il processo di solito comporta modifiche ai ruoli e alle responsabilità, nonché alle pratiche di sviluppo del software. Per adottare con successo questi strumenti e tecniche, hai bisogno del forte supporto di uno o più membri del team di leadership. Gli sponsor dei dirigenti più efficaci sono quelli che considerano questi cambiamenti come un processo continuo di miglioramento e vogliono potenziare i propri team anziché gestirli.

• Allineamento della strategia tecnica e di business. Consigliamo ai team aziendali e tecnici di allinearsi alle quattro misure di distribuzione del software principali definite da DORA (DevOps Research and Assessment): tempo di risposta per le modifiche, frequenza di deployment, tempo per ripristinare il servizio e tasso di errore delle modifiche. Allinearsi 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 la creazione di catene di strumenti hanno bisogno delle risorse necessarie: tempo, persone e infrastruttura. Questi team hanno bisogno di tempo per provare a 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, comprese risorse cloud e strumenti software.

• Apertura all'adozione di nuovi strumenti. Le tecniche e gli strumenti CI/CD moderni hanno spesso nuovi strumenti e processi. I team devono sperimentare con questi processi e strumenti ed essere aperti ad adottarli. È necessario un loop di feedback affinché i team della piattaforma possano ascoltare le opinioni dei team dedicati all'applicazione, alle operazioni e alla sicurezza che la utilizzano.

• Recupero culturale. Per avere successo nell'implementazione e nell'adozione di un moderno sistema CI/CD 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 operativi e di sviluppo devono essere disposti ad assumersi una maggiore responsabilità per la sicurezza, mentre i team operativi e di sicurezza devono essere disposti a snellire i processi 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 devono avere 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 CI (come Jenkins, TeamCity, Bamboo e CircleCI) e nell'esecuzione di 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 familiarità con l'automazione dei deployment. Esempi di strumenti di deployment automatizzato includono gli script shell di base, Terraform, Chef o Puppet. Avere una conoscenza di base degli strumenti e dei processi di deployment automatizzati è 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 velocità e affidabilità.

• Controllo del codice sorgente moderno. I moderni strumenti di controllo del codice sorgente come Git consentono ai team di creare flussi di lavoro come lo sviluppo basato su trunk, i rami delle caratteristiche e le richieste di unione.

Progetta una CI/CD moderna 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 di operare in modo efficiente.

Questa sezione illustra inoltre l'infrastruttura necessaria per supportare il ciclo di vita della distribuzione 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 di base semplificano l'onboarding e l'implementazione delle best practice. Vengono esaminate le seguenti considerazioni sulla progettazione:

• Piattaforma di distribuzione del software. Il framework e le funzionalità tecniche alla base di un processo di rilascio delle applicazioni affidabile e ad alta velocità.

• Infrastruttura della piattaforma. I componenti dell'infrastruttura e le considerazioni relative alla 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 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 dell'applicazione e il codice per creare l'infrastruttura. Potrebbero anche essere repository di partenza che facilitano 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 applicazioni in modo autonomo utilizzando i guard rail impostati.

• Modello operativo. Strumenti, processi e metodi tecnici per gestire l'infrastruttura e le applicazioni che compongono la piattaforma.

• Governance. I processi e le 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 snellisce i processi necessari per creare, distribuire, sottoporre a deployment e gestire le applicazioni.

La responsabilità di mantenere la configurazione, la stabilità, l'uptime e la scalabilità di un'applicazione varia a seconda degli operatori, dei team di sicurezza e degli 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, 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, è necessario ciascun componente nel seguente diagramma:

Ciascuno di questi componenti fornisce funzionalità al sistema e alle applicazioni in esecuzione sulla piattaforma:

• Monitoraggio dell'infrastruttura. Il livello di base di monitoraggio necessario durante il provisioning per verificare il corretto funzionamento di cluster, istanze di macchine virtuali (VM) e altre infrastrutture necessarie per il funzionamento delle applicazioni Google Kubernetes Engine (GKE).

• 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. Il controllo dell'archiviazione e dell'accesso per le immagini container.

• CI. Il processo di applicazione di attività automatizzate a un'applicazione prima del deployment. Le attività di CI includono in genere 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 frequenza. Le metodologie di esempio includono le approvazioni manuali, i deployment canary, i deployment blu/verde o i deployment in sequenza.

• Norme. Criteri di configurazione della sicurezza e dell'infrastruttura definiti dai team operativi e di sicurezza e applicati e applicati continuamente 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 è Git.

• Gestione della configurazione. Il sistema utilizzato per archiviare e applicare la configurazione dell'applicazione per diversi ambienti.

• Osservabilità dell'applicazione. Il logging, il monitoraggio, gli avvisi e il tracciamento a livello di applicazione utilizzati da sviluppatori, operatori 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 gli ambienti di sviluppo, 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 proprie applicazioni a scopo di test e sperimentazione.

• 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 assomigliare a quelli di produzione, in modo da poter ridurre o eliminare le differenze tra gli ambienti e, di conseguenza, migliorare le percentuali di successo del deployment.

  • Produzione. Questi cluster eseguono i carichi di lavoro di produzione. Dovresti usare più cluster distribuiti geograficamente. Ciò migliora l'affidabilità dai guasti dell'infrastruttura e riduce i problemi operativi della seconda fase, come gli upgrade e la scalabilità dei cluster.

Il seguente diagramma mostra l'architettura generale:

In questa architettura, gestisci i cluster per ogni ambiente tramite Config Sync. Una configurazione coerente del cluster è fondamentale perché garantisce a sviluppatori, operatori e team di sicurezza che gli ambienti di pre-produzione e produzione operano in modo simile. Puoi utilizzare Config Sync per archiviare e applicare configurazioni comuni nel tuo parco 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.

Puoi gestire i 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 di un'applicazione sono isolate nell'ambiente dell'applicazione. Inizializza i repository di applicazioni e configurazione usando repository di base e strumenti automatizzati. Ad esempio, puoi utilizzare Cloud Build per eseguire Terraform al fine di integrare e inizializzare nuove applicazioni automaticamente.

Esegui il deployment delle applicazioni nelle rispettive zone di destinazione su ciascun cluster, in modo che le applicazioni siano isolate da rete e identità. Inizializza le zone di destinazione delle applicazioni tra gli ambienti utilizzando Config Sync e utilizzi Cloud Service Mesh o Multi Cluster Ingress per far sì che i cluster di produzione sembrino un unico cluster creando un mesh di rete che comprende più cluster.

Flusso di lavoro di distribuzione del software

Un componente fondamentale della piattaforma di distribuzione del software è il sistema CI/CD. Quando gli builder di piattaforme iniziano a definire il processo CI/CD, devono garantire che ogni componente produca o utilizzi artefatti che ottemperano a un'interfaccia standardizzata. L'uso di un'interfaccia standardizzata semplifica la sostituzione dei componenti quando si tratta di 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 di Kubernetes. Queste interfacce consentono di creare una pipeline CI/CD riutilizzabile e flessibile con un flusso di lavoro di sviluppo, creazione e rilascio, come mostra il seguente diagramma:

Questo flusso di lavoro funziona nel seguente modo:

1. Gli sviluppatori eseguono il commit del codice dell'applicazione nei repository di codice.

2. Il sistema CI testa il codice, crea un artefatto dell'immagine Docker e archivia l'artefatto in un registro.

3. Quando l'artefatto è pronto per il deployment, viene aggiunto un riferimento alla configurazione dell'applicazione.

4. La configurazione dell'applicazione viene resa in un formato leggibile da Kubernetes e archiviata in un Gli aggiornamenti a questo repository attivano una pipeline di deployment che esegue il deployment degli artefatti in un ambiente di sviluppo integrato.

5. Al termine del test nell'ambiente di sviluppo integrato, gli operatori promuovono il deployment nell'ambiente di pre-produzione.

6. 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 il rilascio nell'ambiente di produzione.

7. Le modifiche apportate agli operatori alle configurazioni di base vengono applicate all'intera organizzazione. Quando gli operatori eseguono il commit delle modifiche nei propri repository, gli aggiornamenti della configurazione dell'applicazione (e i deployment successivi) possono essere attivati automaticamente. Oppure, le modifiche degli operatori possono essere rilevate al successivo deployment delle modifiche.

8. Parallelamente, i tecnici della sicurezza possono implementare e modificare i criteri che definiscono gli elementi di cui è possibile eseguire il deployment, quindi 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 controllo e revisione prima di essere applicate. In questo modello dichiarativo, archivi i file di configurazione in un repository Git, che ti consente di gestire 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. Definendo le configurazioni di base, i team delle piattaforme possono creare e replicare le best practice per l'organizzazione. Operatori e sviluppatori possono eseguire l'iterazione dei deployment in modo indipendente, applicando le best practice impostate dagli operatori. Quando gli operatori hanno bisogno di implementare una nuova best practice per l'organizzazione, apportano la modifica alla base e la modifica viene automaticamente applicata con il deployment successivo degli sviluppatori.

Repository di codice

I repository di codice sorgente sono il cuore 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 al sistema offre diversi vantaggi:

• Verificabilità integrata. I commit contengono informazioni su quando, cosa e chi ha modificato il sistema.

• Un processo di rollback semplificato. 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 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 sezioni seguenti spiegano come operatori, sviluppatori e tecnici della sicurezza utilizzano il repository Git in un moderno sistema CI/CD.

Repository 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 al contempo le best practice dell'organizzazione fin dall'inizio. Con gli operatori che gestiscono i repository, gli sviluppatori possono utilizzare 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 propria organizzazione in due repository. Il primo repository è il luogo in cui gli operatori mantengono le best practice condivise per le pipeline CI/CD. In questo repository, gli operatori forniscono agli sviluppatori una libreria di attività predefinite da utilizzare per creare le proprie pipeline. I repository di 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

• 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 prevedono la garanzia di un modo per gestire i manifest dichiarativi nel modello di risorse di 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 di applicazioni

I repository di applicazioni archiviano la logica di business dell'applicazione e qualsiasi configurazione specializzata necessaria al corretto funzionamento dell'applicazione.

Poiché gli operatori creano e gestiscono le best practice in modo codificato, gli sviluppatori possono utilizzarle. Per farlo, gli sviluppatori fanno riferimento alle attività per CI/CD e alle basi dell'applicazione 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 di risorse e annotazioni.

Ecco alcuni esempi di artefatti che puoi archiviare nei repository di applicazioni:

• Codice sorgente dell'applicazione

• Un Dockerfile che descrive come creare ed eseguire l'applicazione

• Definizione della pipeline CI/CD

• Le estensioni o le modifiche alle basi di configurazione dell'applicazione create dagli operatori

Repository Infrastructure as Code

I repository Infrastructure as Code archiviano il codice per creare l'infrastruttura richiesta per eseguire le applicazioni. L'infrastruttura potrebbe includere piattaforme di networking e di 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 integrano le definizioni dichiarative dell'API.

• Estensioni o modifiche ai modelli dell'infrastruttura di base creati dal team dell'infrastruttura.

Repository di criteri e configurazione

Garantire una piattaforma coerente e ottimizzata per la sicurezza è una priorità assoluta sia per gli operatori che per gli ingegneri della sicurezza.

Configurazione

La configurazione centralizzata 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 di accesso basato sui ruoli (RBAC)

• Criteri di rete

Dovresti applicare in modo coerente questi tipi di configurazioni a tutti i cluster per evitare che i team dedicati alle applicazioni facciano un uso improprio o illecito dell'infrastruttura. L'utilizzo di un repository Git per archiviare la configurazione può migliorare processi come l'auditing e il deployment della configurazione tramite 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, è necessario trovare un modo per 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, puoi utilizzare Policy Controller per applicare i criteri.

Repository di avvio

I repository di base favoriscono l'adozione di best practice per CI/CD, infrastruttura e sviluppo su tutta la piattaforma. I repository di base possono ridurre notevolmente il costo associato all'adozione delle best practice. Le best practice contribuiscono ad aumentare la velocità delle funzionalità, l'affidabilità e la produttività dei team. Nell'architettura di riferimento associata sono presenti più repository di base per configurazioni CI, CD, Kubernetes, applicazioni e infrastrutture Go, Java e Python.

Integrazione continua

Le organizzazioni in genere dispongono di un insieme standard di attività che viene applicato alle applicazioni durante la CI. Ad esempio, nell'implementazione di riferimento, il set di base di fasi CI è il seguente: compila il codice e crea un'immagine container. Poiché queste fasi sono definite nel repository di base, vengono applicate in modo uniforme in tutta la piattaforma. I singoli team delle applicazioni possono aggiungere passaggi aggiuntivi.

Distribuzione continua

Come per CI continua, il processo per CD prevede in genere una serie di passaggi standard 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 tali metodologie in modo uniforme nelle applicazioni e negli ambienti. Nell'implementazione di riferimento, il processo di deployment include implementazioni per sviluppo, deployment di pre-produzione e produzione in più cluster e approvazioni manuali per il deployment in 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 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 delle best practice, ad esempio osservabilità e best practice per i container.

• Osservabilità. Per far funzionare un'applicazione in modo efficiente e contribuire a garantire l'affidabilità, le applicazioni devono tenere conto di logging, metriche e tracciamenti. Le applicazioni di base aiutano i team a creare frame 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 la pacchettizzazione 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. Per saperne di più, consulta le best practice per la creazione di 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 di base personalizzate per i linguaggi, gli stack tecnologici e i tipi di applicazioni sviluppati dai tuoi team.

Repository di base dell'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 di avvio 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 Cloud Storage o un database Spanner. Questo modello viene in genere utilizzato dai team delle applicazioni per gestire l'infrastruttura delle 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 di infrastruttura come reti e computing.

Zone di destinazione dell'applicazione

Quando utilizzi CI/CD condivisi, configurazione di applicazioni condivise e criteri e configurazione coerenti tra i 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 e l'iterazione delle proprie applicazioni. Le zone di destinazione delle applicazioni utilizzano i guard rail predisposti per consentire agli sviluppatori di operare in modo autonomo. Per ogni applicazione, puoi creare uno spazio dei nomi Kubernetes in ogni cluster di ciascun 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 utilizzi una piattaforma di distribuzione del software con CI/CD moderni, è 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 as a Service", blueprint o infrastruttura multi-tenant.

Poiché è importante mantenere un'infrastruttura coerente, limitare la proliferazione e consentire ai team di concentrarsi sulla distribuzione delle applicazioni, 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 delle applicazioni di gestire l'infrastruttura e consente a operatore e team di sicurezza di concentrarsi sul mantenere coerente l'infrastruttura.

Considerazioni sull'infrastruttura multi-tenant

Quando crei una piattaforma di distribuzione del software multi-tenant, puoi prendere in considerazione diverse cose:

• Isolamento del carico di lavoro. Le zone di destinazione delle applicazioni offrono 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 ripartizioni 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 e sull'utilizzo delle risorse per i carichi di lavoro di un cluster, che puoi filtrare ulteriormente per spazi dei nomi ed etichette. Quando abiliti la misurazione dell'utilizzo di GKE nel cluster multi-tenant, i record di utilizzo delle risorse vengono scritti in una tabella BigQuery. Puoi esportare metriche specifiche per il tenant nei set di dati BigQuery nel progetto tenant corrispondente. I revisori possono quindi analizzare queste metriche per determinare le ripartizioni 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 di cui ciascun tenant e alla quantità di memoria e CPU richieste 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 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 semplifica i problemi relativi al ciclo di vita della gestione e degli upgrade del cluster.

• Logging e monitoraggio specifici per 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 in set di dati BigQuery, quindi filtrare i set di dati in base allo spazio dei nomi tenant. I tenant potranno quindi accedere ai dati esportati in BigQuery.

Per ulteriori informazioni su un'infrastruttura multi-tenant, consulta le best practice per l'architettura multi-tenancy aziendale.

Confini di isolamento

Una piattaforma di distribuzione del software viene creata e utilizzata da più team, il che rende importante avere limiti di isolamento adeguati tra i diversi componenti della piattaforma. I limiti di isolamento aiutano a creare una piattaforma solida fornendo le seguenti caratteristiche:

• Disaccoppiare le 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 dell'accesso per limitare l'accesso.

• Riduce le aree interessate. Puoi apportare modifiche a un componente in modo indipendente senza che ciò influisca sugli altri.

• Riduce gli errori manuali. Poiché il controllo dell'accesso è granulare, puoi evitare errori manuali come il deployment accidentale di un cluster di produzione da un ambiente di sviluppo.

Questi limiti di isolamento possono esistere tra diverse applicazioni, infrastrutture e applicazioni o anche tra 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 di distribuzione del software complessivo. In termini di gestione della piattaforma, occorre fare due considerazioni principali: l'onboarding delle applicazioni, che in genere rientra nella categoria di governance, e lo sviluppo e la manutenzione continui della piattaforma (ovvero, il trattamento della piattaforma come un prodotto).

Onboarding e gestione delle applicazioni

L'obiettivo dell'adozione di metodi e strumenti moderni di CI/CD è quello di semplificare il processo di rilascio e l'onboarding dei nuovi servizi. L'onboarding delle nuove applicazioni dovrebbe essere un processo semplice che puoi eseguire con il minimo input da i team operativi e di sicurezza. Ciò non significa che i team operativi e di sicurezza non sono coinvolti, ma che il loro input iniziale dal punto di vista del deployment e della sicurezza viene gestito automaticamente attraverso il processo di provisioning. Dopo l'onboarding, i team operativi e di sicurezza sono naturalmente inclusi nel processo di rilascio attraverso richieste di unione, aggiornamenti dei criteri e applicazione delle best practice.

Ti consigliamo di creare un po' di 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 dagli altri team dell'organizzazione e offre agli sviluppatori autonomia per gestire un'applicazione in autonomia. Ciò consente agli sviluppatori di 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 la domanda in ambienti più elevati, dovrebbero essere coinvolti altri team e seguire il processo di revisione.

Nell'architettura di riferimento associata, questa automazione è denominata Application Factory.

La piattaforma come prodotto

Il flusso di lavoro CI/CD è un prodotto software, ad eccezione del fatto che gli utenti del prodotto sono i team di sviluppo, operazioni e sicurezza. Tenendo conto di ciò, la piattaforma richiede gli stessi ruoli e processi di sviluppo software, come proprietari dei prodotti, marketing (anche se rivolto all'interno), cicli di feedback degli utenti e 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 operativi, di sicurezza e di sviluppo devono prendere in considerazione anche altri fattori durante il lavoro, di cui vengono trattati in questa sezione.

Selezionare una richiesta di partecipazione al progetto pilota

Scegliere le prime applicazioni per passare alla piattaforma può essere un primo passo difficile. Sono buoni candidati per i progetti pilota i servizi che elaborano o gestiscono richieste, ma non archiviano dati, 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à e a errori di deployment che possono verificarsi ogni volta che si utilizzano nuove tecniche di deployment e gestione della configurazione. Man mano che i team acquisiscono maggiore esperienza con CI/CD e iniziano a usufruire di vantaggi in termini di affidabilità e velocità, puoi iniziare a trasferire i servizi principali sulla piattaforma di distribuzione del software.

Considerazioni per gli sviluppatori

Quando lavori in un moderno processo di sviluppo CI/CD, le funzionalità, le modifiche e i deployment possono avvenire sia con maggiore frequenza che in modo più asincrono. I team di sviluppo devono comprendere l'impatto delle modifiche sui sistemi downstream o dipendenti e capire come queste modifiche vengono testate. I percorsi di comunicazione tra sviluppo, operazioni e team di sicurezza devono essere fluidi. È buona prassi investire in pratiche migliori di controllo delle versioni sia per le applicazioni sia per i contratti 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 parti e l'utilizzo di rami e flag di funzionalità può migliorare il modo in cui testare e rilasciare le funzionalità.

Considerazioni sugli operatori

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 sviluppando strumenti e processi interni che semplificano lo sviluppo, il deployment e il funzionamento di applicazioni rivolte all'esterno. Gli strumenti della piattaforma sono utilizzati dal proprio team e dai team di sviluppo e sicurezza. Gli operatori devono creare strumenti che supportino l'implementazione di nuove versioni delle applicazioni e anche il loro rollback in caso di errori dell'applicazione o del deployment. Gli operatori dovrebbero inoltre porre maggiore enfasi sui sistemi di monitoraggio e avviso degli edifici per rilevare in modo proattivo gli errori e avvisare di conseguenza.

Considerazioni del team di sicurezza

I team di sicurezza dovrebbero fare in modo che la sicurezza sia una responsabilità condivisa tra loro e i team operativi e di sviluppo. Questo schema è comunemente chiamato cambio a sinistra sulla sicurezza, in cui la sicurezza delle informazioni (InfoSec) è coinvolta nelle prime fasi del processo di sviluppo, gli sviluppatori lavorano con strumenti pre-approvati e i test di sicurezza sono automatizzati. Oltre a queste tecniche, con Policy Controller puoi definire e applicare in modo programmatico i criteri di sicurezza. La combinazione di tecniche e strumenti consente all'applicazione della sicurezza di avere una posizione più proattiva.

Passaggi successivi

• Prova 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.

• Scopri di più sui pattern di monitoraggio e logging ibridi e multi-cloud.