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

Standard

---

Questo documento descrive un framework per l'implementazione di modelli processi di integrazione/distribuzione continua (CI/CD) su un software multi-team di distribuzione dei contenuti che usa Google Kubernetes Engine

Puoi quindi eseguire l'iterazione sulla piattaforma per migliorare ulteriormente le prestazioni per lo sviluppo e le operazioni, inclusa la velocità di rilascio, l'affidabilità della piattaforma e il tempo di recupero dai guasti.

Questo documento fa parte di una serie:

• CI/CD moderna con GKE: un framework di distribuzione del software (questo documento)

• CI/CD moderna con GKE: crea un sistema CI/CD (architettura di riferimento)

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

Questo documento è rivolto ad architetti aziendali e sviluppatori di applicazioni, nonché a team di sicurezza IT, DevOps e Site Reliability Engineering. Per comprendere i concetti di questo documento è utile avere una certa esperienza con gli strumenti e le procedure di deployment automatico.

Un caso per CI/CD moderno

CI/CD è un approccio di sviluppo software che consente di automatizzare build, test e di deployment dello sviluppo del software utilizzando una serie di strumenti e ripetibili.

Oltre all'automazione CI/CD, Kubernetes e i container hanno abilitato per ottenere miglioramenti senza precedenti nella velocità di sviluppo e deployment. Tuttavia, anche se l'adozione di Kubernetes e dei container è in crescita, molte organizzazioni non sfruttano appieno i vantaggi in termini di velocità di rilascio, stabilità ed efficienza operativa perché le loro pratiche CI/CD non sfruttano appieno Kubernetes o non risolvono problemi di operazioni e sicurezza.

Un approccio CI/CD veramente moderno deve comprendere più dell'automazione. Per beneficiare appieno dei miglioramenti in termini di velocità e sicurezza e per sfruttare la potenza di Kubernetes e dei container, devi semplificare l'onboarding delle applicazioni, le pratiche CI/CD e i processi operativi.

Utilizzando l'infrastruttura coerente offerta da GKE piattaforma, metodi CI/CD uniformi e best practice per l'implementazione, a disposizione dell'organizzazione i 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 al meglio per il provisioning di applicazioni e criteri di provisioning della piattaforma.

  • Semplifica l'onboarding delle applicazioni mettendo a disposizione dei team per i progetti di base funzionanti e di cui è possibile eseguire il deployment, integrate nelle best practice dell'organizzazione.

• Riduzione del tempo necessario per ripristinare il servizio.

  • Gestisci tutta la configurazione in modo dichiarativo utilizzando GitOps per controlli, rollback e revisioni semplificati.

  • Standardizzare le metodologie di implementazione e monitoraggio dell'organizzazione per ridurre il tempo necessario per identificare i i fattori di un problema che influisce su un servizio.

• Aumentare la frequenza di deployment.

  • Assicurati che gli sviluppatori di applicazioni possano eseguire l'iterazione in modo indipendente le proprie sandbox di sviluppo (o zone di destinazione) senza che interferiscono tra loro.

  • Utilizza GitOps per il deployment, migliora la gestione delle release e il monitoraggio delle modifiche.

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

  • Crea un processo di implementazione progressiva per un deployment coerente in ambienti di pre-produzione, offrendo agli sviluppatori la fiducia 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:

• 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 devi valutare se la tua organizzazione e i tuoi team sono pronti ad adottare una nuova piattaforma.

Caratteristiche organizzative

L'adozione di una piattaforma moderna richiede il seguente supporto da parte del leadership e dei team tecnici della tua attività:

• Sponsor leader. L'adozione di una piattaforma di distribuzione del software è tipicamente un impegno importante intrapreso da più team cross-funzionali. Il procedura in genere comporta modifiche a ruoli e responsabilità, nonché alle pratiche di sviluppo software. Per adottare con successo questi strumenti e tecniche, hai bisogno del forte supporto di uno o più membri del team dirigenziale. Il più sponsor di leadership efficaci sono coloro che considerano questi cambiamenti come un processo continuo di miglioramento e vogliono potenziare i propri team anziché gestirli.

• Allineamento della strategia tecnica e aziendale. Ti consigliamo di allineare i team aziendali e tecnici alle quattro misure chiave della distribuzione del software definite da DevOps Research and Assessment (DORA): tempo di risposta per le modifiche, frequenza di deployment, tempo per ripristinare il servizio e tasso di errore delle modifiche. Allinearsi a queste misure permette 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 investimenti.

• Risorse. Per avere successo, i team che sviluppano pratiche CI/CD moderne e creano catene di strumenti hanno bisogno delle risorse necessarie: tempo, persone e infrastrutture. Questi team hanno bisogno di tempo provare a selezionare i processi e gli strumenti migliori. Idealmente, questi team rappresentano molte funzioni diverse nel processo di distribuzione del software e possono integrare altre risorse dell'organizzazione. Infine, i team devono essere in grado di eseguire il provisioning dell'infrastruttura, incluse le risorse cloud e gli strumenti software.

• Apertura all'adozione di nuovi strumenti. Strumenti e tecniche CI/CD moderni spesso includono nuovi strumenti e processi. I team devono sperimentare con questi processi e strumenti e essere aperti ad adottarli. È necessario un ciclo di feedback per consentire ai team della piattaforma di ricevere informazioni dai team di applicazioni, operazioni e sicurezza che utilizzano la piattaforma.

• Idoneità culturale. Per eseguire correttamente il deployment e adottare un sistema CI/CD moderno con GKE, l'organizzazione e i team tecnici che sviluppano il sistema devono essere pronti a cambiare il modo in cui operano e collaborano. Ad esempio, sviluppo e operazioni i team devono essere disposti a la responsabilità per la sicurezza, e i team operativi e di sicurezza devono essere disposti semplificare le procedure di approvazione delle modifiche.

Capacità tecniche

L'adozione di un approccio CI/CD moderno richiede inoltre che i team siano preparati tecnicamente nel seguente modo:

• Esperienza con i container. Team che adottano tecnologie CI/CD moderne richiedono una certa familiarità con i container. Idealmente, questa esperienza include tecniche di sviluppo per creare immagini container e per creare sistemi più grandi.

• Strategia di integrazione continua. I team devono avere una certa esperienza nell'utilizzo di strumenti di CI (come Jenkins, TeamCity, Bamboo e CircleCI) ed eseguire alcune operazioni di integrazione continua e test automatici. Consigliamo alle organizzazioni di pianificare come migliorare ulteriormente queste procedure.

• Automazione del deployment. I team devono avere una certa esperienza con l'automazione del deployment. Esempi di strumenti di deployment automatico includono script shell di base, Terraform, Chef o Puppet. Avere una conoscenza di base degli strumenti e delle procedure di deployment automatico è fondamentale per semplificare e automatizzare i deployment.

• Architetture orientate ai servizi. Sebbene non sia un prerequisito adozione di moderni processi CI/CD, adozione di altri architetture modulari e orientate ai servizi devono essere un obiettivo a lungo termine per le organizzazioni che vogliono adottare le moderne soluzioni CI/CD e le tecniche con GKE. È stato dimostrato che le architetture basate su servizi migliorano la velocità e l'affidabilità.

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

Progetta una CI/CD moderna con GKE

Questa sezione descrive una piattaforma di distribuzione del software e i suoi componenti. A migliorare le prestazioni di distribuzione del software, devi implementare CI/CD e best practice tecniche che consentono ai team di rilasciare release in modo rapido e di operare in modo efficiente.

Questa sezione illustra anche l'infrastruttura necessaria per supportare il ciclo di vita del deployment del software e come gestirla in modo coerente con GKE. Infine, questa sezione fornisce un esempio di software flusso di lavoro di distribuzione e mostra come i repository di base semplificano l'onboarding implementazione delle best practice. Vengono esaminate le seguenti considerazioni di progettazione:

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

• Infrastruttura della piattaforma. I componenti dell'infrastruttura e le considerazioni di gestione necessari per creare la piattaforma ed eseguire le applicazioni.

• Flusso di lavoro di distribuzione del software. In che modo i team collaborano per creare, testare e implementare il codice in modo più efficiente.

• Repository di codice. Repository che 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 base 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 autonomamente il deployment e l'iterazione delle applicazioni utilizzando i guard rail che hai implementato.

• Modello operativo. Strumenti, processi e metodi tecnici per per la gestione dell'infrastruttura e delle applicazioni che compongono la piattaforma.

• Governance. Procedure e considerazioni necessarie per mantenere e gestire la piattaforma di distribuzione del software.

Piattaforme di distribuzione del software

Una piattaforma di distribuzione del software unifica gli strumenti e semplifica le procedure necessarie per creare, pubblicare, implementare e gestire le applicazioni.

La responsabilità della gestione della configurazione, della stabilità, del tempo di attività e della scalabilità di un'applicazione varia a seconda degli operatori, dei team di sicurezza e di sviluppo, ma tutti i componenti e i team devono lavorare insieme per velocizzare le release. Sebbene questo documento descriva metodi per migliorare la gestione del controllo del codice e l'osservabilità delle applicazioni, si concentra principalmente sull'integrazione continua (CI), sulla distribuzione continua (CD) e sulla gestione della configurazione.

Per creare una piattaforma di distribuzione del software completa, hai bisogno di ogni componente riportato nel seguente diagramma:

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

• Monitoraggio dell'infrastruttura. Il livello di monitoraggio di base necessario durante il provisioning per verificare il corretto funzionamento dei cluster, delle istanze di macchine virtuali (VM) e di altra infrastruttura necessaria per il funzionamento delle applicazioni.

• Orchestrazione dei container. La piattaforma che coordina il deployment e il funzionamento delle applicazioni basate su container. Esempi di per l'orchestrazione dei container sono Kubernetes, GKE o GKE Enterprise.

• Registro dei contenitori. Lo spazio di archiviazione e il controllo dell'accesso per le immagini container.

• CI. Il processo di applicazione di attività automatiche a un'applicazione prima del deployment. Le attività di CI in genere includono compilazione, imballaggio e test. I tipi di attività variano in base all'applicazione e all'organizzazione.

• CD. Processi di deployment altamente automatizzati e applicati con elevata frequenza. Alcuni esempi di metodologie includono approvazioni manuali, deployment Canary, deployment blue-green o deployment in sequenza.

• Norme. Definizione dei criteri di sicurezza e di configurazione dell'infrastruttura da parte dei team operativi e di sicurezza e applicata e applicata in modo continuativo dalla piattaforma.

• Gestione del codice sorgente. Ad esempio, archiviazione con controllo delle versioni per codice, file di configurazione e definizioni dei criteri. In un sistema CI/CD moderno, la gestione del codice sorgente è in genere Git.

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

• Osservabilità dell'applicazione. Il logging, il monitoraggio, gli avvisi e il monitoraggio a livello di applicazione utilizzati dai team di sviluppatori, operatori e sicurezza per risolvere i problemi e verificare il corretto funzionamento delle applicazioni.

Infrastruttura della piattaforma

Per creare una piattaforma di distribuzione del software scalabile, sono necessari i cluster Kubernetes per gli ambienti di sviluppo, di pre-produzione e cluster di produzione. I cluster possono avere molte funzioni diverse:

• Sviluppo. In questi cluster, gli sviluppatori eseguono implementazioni ad hoc delle loro applicazioni per test e sperimentazione.

• L'ambiente dell'applicazione.

  • Pre-produzione. Per ogni ambiente di preproduzione nel tuo workflow, devi avere un cluster Kubernetes per ospitare le tue applicazioni. Questi cluster devono essere simili ai cluster di produzione in modo da poter ridurre o eliminare le differenze tra gli ambienti e, di conseguenza, migliorare i tassi di successo del deployment.

  • Produzione. Questi cluster eseguono i carichi di lavoro di produzione. Dovresti utilizzare più cluster distribuiti geograficamente. In questo modo migliora l'affidabilità dai guasti dell'infrastruttura e semplifica il giorno 2 e problemi operativi 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. La configurazione coerente del cluster è fondamentale perché offre agli sviluppatori, agli operatori e ai team di sicurezza la certezza che gli ambienti di preproduzione e di produzione funzionino in modo simile. Puoi utilizzare Config Sync per archiviare e applicare configurazioni comuni in tutto il tuo parco risorse di cluster. Una volta che la configurazione del cluster standardizzati, verificabili e scalabili, puoi concentrarti sulla distribuzione del software e l'onboarding e il deployment delle applicazioni.

Gestisci i deployment nei cluster di sviluppo, di gestione temporanea e di produzione tramite le pipeline CI/CD dell'applicazione. La gestione del controllo del codice sorgente funge da punto di coordinamento per il codice e la configurazione dell'applicazione. Le pipeline CI/CD e le immagini container di un'applicazione sono isolate nell'ambiente dell'applicazione. Inizializzi i repository di applicazioni e configurazioni utilizzando repository di base e strumenti automatizzati. Ad esempio, puoi utilizzare Cloud Build per eseguire Terraform per l'onboarding e l'inizializzazione automatica di nuove applicazioni.

Esegui il deployment delle applicazioni nelle relative zone di destinazione su ogni cluster, in modo che siano isolate a livello di rete e di identità. Inizializziamo le zone di destinazione delle applicazioni in vari ambienti utilizzando Config Sync e utilizzi Cloud Service Mesh o Ingress multi-cluster in modo che i cluster di produzione sembrino 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 i creator di piattaforme iniziano a definire il processo CI/CD, devono assicurarsi che ogni componente produca o consumi elementi che rispettino un'interfaccia standardizzata. L'utilizzo di un'interfaccia standardizzata semplifica la sostituzione dei componenti quando sul mercato viene introdotta un'implementazione migliore.

Quando crei una piattaforma per le applicazioni containerizzate, puoi utilizzare le tre interfacce standardizzate tra i componenti: repository Git, immagini Docker e manifest Kubernetes. Queste interfacce ti consentono di creare una pipeline CI/CD riutilizzabile e flessibile con un flusso di lavoro di sviluppo, compilazione e rilascio, come mostrato nel seguente diagramma:

Questo flusso di lavoro funziona nel seguente modo:

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

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

3. Una volta che l'elemento è pronto per il deployment, viene aggiunto un riferimento alla configurazione dell'applicazione.

4. 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 un che esegue il deployment degli artefatti in un ambiente di sviluppo integrato.

5. Al termine dei 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. Quando gli operatori apportano modifiche alle configurazioni di base, tali modifiche sono applicate all'intera organizzazione. Quando gli operatori eseguono il commit delle modifiche di repository, gli aggiornamenti della configurazione dell'applicazione (e le successive deployment) possono essere attivati automaticamente. In alternativa, le modifiche degli operatori possono essere rilevate al successivo dispiegamento delle modifiche degli sviluppatori.

8. Parallelamente, gli esperti di sicurezza possono implementare e modificare i criteri che definiscono cosa può essere implementato, quindi eseguire il commit di questi criteri nel proprio repository.

Utilizzando una metodologia GitOps, puoi richiedere un approccio dichiarativo per qualsiasi modifiche alle applicazioni e ai cluster. Con questo approccio, tutte le modifiche sono soggette a verifica e revisione prima di poter essere applicate. Nel presente documento di configurazione, archivi i file di configurazione in un repository Git, mantenere un log delle modifiche, eseguire il rollback dei deployment non riusciti e controllare il potenziale impatto delle modifiche proposte.

Nella sezione architettura di riferimento, usi kustomize: per controllare le configurazioni delle applicazioni nella tua organizzazione. kustomize consente agli operatori di creare le cosiddette basi di configurazioni delle applicazioni i team di sviluppo possono perfezionare i modelli senza dover aggiungere o modificare la base. Mediante la definizione di configurazioni di base, i team della piattaforma possono creare ed eseguire l'iterazione sulle best practice per l'organizzazione. Operatori e sviluppatori possono eseguire l'iterazione i propri deployment in modo indipendente, con gli sviluppatori che applicano le best practice impostate dagli operatori. Quando gli operatori devono implementare una nuova best practice per l'organizzazione, apportano la modifica alla base, che viene richiamata automaticamente con il successivo deployment degli sviluppatori.

Repository di codice

I repository di codice sorgente sono il cuore del sistema CI/CD. Operatori sviluppatori e tecnici della sicurezza hanno ciascuno i propri repository da propagare modifiche alla piattaforma. L'utilizzo di un repository Git come base per tutte le modifiche nel sistema offre diversi vantaggi:

• Verificabilità 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 per tornare a uno stato precedente del sistema.

• Controllo delle versioni. Puoi taggare i commit Git per indicare una versione lo 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 come i vari team interagiscono con un repository centralizzato per tutte le modifiche:

Le sezioni seguenti spiegano come operatori, sviluppatori e tecnici della sicurezza utilizzano il repository Git in un sistema CI/CD moderno.

Repository operatori

I repository gestiti dall'operatore contengono best practice per CI/CD e configurazione delle applicazioni per aiutare i team a integrare le applicazioni, adottando al contempo le best practice organizzative fin dall'inizio. Con gli operatori che gestiscono i repository, gli sviluppatori possono utilizzare gli aggiornamenti alle best practice dell'organizzazione con il minor numero possibile di interruzioni del flusso di lavoro.

Gli operatori possono codificare il file in due repository. Il primo repository è il luogo in cui gli operatori mantengono al meglio la pipeline CI/CD condivisa. pratiche. In questo repository, gli operatori forniscono agli sviluppatori una libreria di attività predefinite che possono utilizzare per creare le proprie pipeline. I repository delle applicazioni degli sviluppatori ereditano automaticamente queste attività e la logica al loro interno. Non è necessario copiarle manualmente. Esempi di attività che puoi standardizzare in tutta l'organizzazione includono:

• Creazione e archiviazione di artefatti

• Metodologie di test per varie lingue

• Passi per il deployment

• Controlli delle norme

• Analisi della sicurezza

Il secondo repository per cui gli operatori gestiscono le best practice durante la configurazione di un'applicazione. Nel contesto di GKE, implicano garantire un modo per gestire i manifest dichiarativi nei 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, agli sviluppatori un percorso semplificato per il deployment best practice per l'organizzazione.

Repository di applicazioni

I repository delle applicazioni memorizzano la logica di business dell'applicazione e qualsiasi configurazione specializzata necessaria per il suo funzionamento corretto.

Poiché gli operatori creano e gestiscono le best practice in modo codificato, gli sviluppatori possono utilizzarle. Per farlo, gli sviluppatori fanno riferimento alle attività CI/CD e le basi applicative che gli operatori hanno creato sui propri repository. Dopo che gli sviluppatori hanno apportato le modifiche, gli operatori possono personalizzare ulteriormente il deployment dell'applicazione aggiungendo configurazioni specifiche per l'ambiente, ad esempio URL di database o etichette e annotazioni delle risorse.

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

• Codice sorgente dell'applicazione

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

• La definizione della pipeline CI/CD

• Estensioni o modifiche alle basi di configurazione delle applicazioni create dagli operatori

Repository Infrastructure as Code

I repository Infrastructure as Code memorizzano il codice per creare l'infrastruttura necessaria per eseguire le applicazioni. L'infrastruttura potrebbe includere piattaforme di networking e 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.

Esempi di artefatti che è possibile archiviare nei repository di applicazioni include:

• Codice in un linguaggio dichiarativo (Terraform, Pulumi) che rappresenta gli oggetti dell'infrastruttura.

• Script shell o Python che completano le definizioni API dichiarative.

• Estensioni o modifiche ai modelli 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 per operatori e tecnici della sicurezza.

Configurazione

La configurazione centralizzata ti consente di propagare le modifiche alla configurazione in tutto il sistema. Alcuni elementi di configurazione comuni che puoi gestire a livello centrale include:

• Spazi dei nomi Kubernetes

• Quote

• Controllo degli accessi basato sui ruoli (RBAC)

• Criteri di rete

Devi applicare in modo coerente questi tipi di configurazioni in tutti i tuoi cluster in modo che i team di applicazioni non usino o abusino dell'infrastruttura. Utilizzo in un repository Git per archiviare la configurazione può migliorare processi come l'auditing e il deployment configurazione tramite metodi come GitOps. Strumenti come Config Sync può semplificare il processo di applicazione uniforme configurazioni in tutta l'infrastruttura.

Norme

Dato che gli sviluppatori possono estendere le configurazioni di base create dagli operatori, occorre trovare un modo per vincolare le risorse create nei cluster che della piattaforma. In alcuni casi, puoi creare un criterio che consenta agli sviluppatori creare risorse solo se soddisfano requisiti specifici, ad esempio Ad esempio, la creazione di oggetti di servizio Kubernetes che non possono essere configurati del carico esterno.

Nell'architettura di riferimento associata, utilizzi Policy Controller per applicare i criteri.

Repository di avvio

I repository iniziali favoriscono l'adozione di best practice di CI/CD, infrastruttura e sviluppo su tutta la piattaforma. I repository di partenza possono ridurre notevolmente il costo associato all'adozione delle best practice. Le best practice, a loro volta, contribuiscono ad aumentare velocità delle funzionalità, affidabilità e produttività dei team. Nell'architettura di riferimento associata, esistono diversi repository di partenza per le configurazioni CI, CD, Kubernetes, le applicazioni di partenza e l'infrastruttura Go, Java e Python.

Integrazione continua

In genere, le organizzazioni hanno un insieme standard di attività che vengono applicate alle applicazioni durante l'integrazione continua. Ad esempio, nell'implementazione del riferimento, insieme di base di fasi CI sono le seguenti: 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, il processo per CD prevede in genere una serie di passaggi standard per il deployment delle applicazioni tramite gli ambienti di sviluppo, pre-produzione e produzione. A prescindere dalle metodologie di deployment utilizzate, il repository di base consente dei team della piattaforma applicano in modo uniforme queste metodologie a tutte le applicazioni ambienti cloud-native. Nell'implementazione di riferimento, il processo di deployment include implementazioni di sviluppo, deployment di pre-produzione, più cluster e approvazioni manuali per il deployment in produzione tramite Cloud Deploy.

Configurazione dell'applicazione

Affinché una piattaforma di distribuzione del software sia efficace, sono necessarie una un modo coerente per applicare la configurazione dell'applicazione. Utilizzando strumenti come kustomize e i repository di partenza per le configurazioni Kubernetes, le piattaforme possono fornire una base coerente per la configurazione delle applicazioni. Ad esempio, nell'implementazione di riferimento, la configurazione di base kustomize inizializza i repository dell'ambiente dell'applicazione con un insieme di configurazioni di base di cui è nota la validità. I singoli team delle applicazioni possono quindi adattare configurazioni alle loro esigenze.

Applicazioni di base

Le applicazioni iniziali possono aiutarti a ridurre l'overhead associato all'adozione di best practice, ad esempio l'osservabilità e le best practice per i contenitori.

• Osservabilità. Per gestire in modo efficiente un'applicazione e aiutare garantire l'affidabilità, le applicazioni devono tenere conto del logging, rintracciabili. 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 nitide. Le best practice per i container includono il confezionamento di una singola applicazione in un'immagine, la rimozione di strumenti non necessari dall'immagine e il tentativo attivo di produrre immagini piccole da immagini di base minime.

L'architettura di riferimento fornisce 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 inizio dell'infrastruttura

I repository di inizio dell'infrastruttura sono dotati del codice precompilato 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 del 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 di infrastruttura per gestire l'infrastruttura utilizzata da più team di applicazioni come risorsa condivisa. Analogamente, l'infra-template contiene il codice di infrastruttura di base iniziale che un'applicazione potrebbe richiedere, ad esempio un database Cloud Storage o Spanner. Questo modello viene in genere utilizzato dai team di applicazioni per gestire l'infrastruttura per le loro applicazioni.

Repository di modelli condivisi

I repository di modelli condivisi forniscono modelli di attività standard che chiunque in un'organizzazione può riutilizzare. Ad esempio, i moduli Infrastructure as Code come i moduli Terraform che possono essere utilizzati per creare risorse di infrastruttura come reti e calcolo.

Zone di destinazione dell'applicazione

Quando utilizzi CI/CD condivisi, configurazione dell'applicazione condivisa e ai criteri e alla configurazione nei vari cluster, puoi collegare queste funzionalità per creare le zone di destinazione delle applicazioni.

Una landing zone è un'entità logica bloccata che consente agli sviluppatori di eseguire il deployment e di eseguire l'iterazione sulle loro applicazioni. Le zone di destinazione delle applicazioni utilizzano i guard rail che hai implementato per consentire agli sviluppatori di operare in autonomia. Per ogni applicazione, crea uno spazio dei nomi Kubernetes in ogni cluster di ogni ambiente (ad esempio, per la produzione, lo sviluppo o lo staging). 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 gestisci una piattaforma di distribuzione del software con CI/CD moderna, è importante mantenere gli ambienti, l'infrastruttura e i processi coerenti e aggiornati. Pertanto, devi pianificare e scegliere con attenzione il modello operativo della piattaforma. Puoi scegliere tra vari modelli, ad esempio "Cluster as a Service", o un'infrastruttura multi-tenant.

Poiché è importante mantenere un'infrastruttura coerente, limitare l'espansione e consentire ai team di concentrarsi sulla pubblicazione di applicazioni, ti consigliamo di eseguire il deployment di un'infrastruttura multi-tenant. Il deployment di applicazioni su un'infrastruttura multi-tenant elimina la necessità per i team di applicazioni di gestire l'infrastruttura e consente ai team di operatori e sicurezza di concentrarsi sul mantenimento della coerenza dell'infrastruttura.

Considerazioni per l'infrastruttura multi-tenant

Quando crei una piattaforma di distribuzione di software multi-tenant, potresti prendere in considerazione diversi aspetti da integrare nella piattaforma:

• Isolamento dei carichi di lavoro. Il concetto di zone di destinazione dell'applicazione è e forniscono un framework per isolare i carichi di lavoro. Le zone di destinazione sono combinazione di spazi dei nomi, criteri di rete e RBAC. Tutte queste risposte i criteri dovrebbero essere gestiti e applicati centralmente Config Sync.

• Monitoraggio dell'utilizzo dei tenant. Per ottenere una suddivisione dei costi per singoli sposti 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 risorse e l'utilizzo delle risorse per i carichi di lavoro di un cluster, filtrare ulteriormente per spazi dei nomi ed etichette. Quando attivi la misurazione dell'utilizzo di GKE sul cluster multi-tenant, i record di utilizzo delle risorse vengono scritti BigQuery tabella. Puoi esportare le metriche specifiche del tenant nei set di dati BigQuery nel progetto del tenant corrispondente, in modo che i revisori possano analizzarle per determinare la suddivisione dei costi.

• Quote delle risorse. Per assicurarti che tutti i tenant che condividono un cluster abbiano un accesso equo alle risorse del cluster, devi applicare quote di risorse. Crea una quota di risorse per ogni spazio dei nomi in base al numero di pod di ciascun tenant e alla quantità di memoria e CPU richiesta da ciascun pod.

• Più cluster per ogni ambiente. Per migliorare l'applicazione l'affidabilità della piattaforma, dovresti usare più cluster per di pre-produzione e produzione. Con più cluster puoi implementare le applicazioni singolarmente nei cluster di convalida canary aggiuntivi. Inoltre, avere a disposizione che semplifica i problemi relativi al ciclo di vita del cluster la gestione e gli upgrade.

• Logging e monitoraggio specifici per i tenant. Per esaminare le operazioni delle loro applicazioni, gli utenti devono avere accesso a log e metriche. In un ambiente multi-tenant, il logging e il monitoraggio dovrebbero per applicazioni specifiche. Per le metriche e il monitoraggio, puoi utilizzare Google Cloud Managed Service per Prometheus e Grafana per ogni spazio dei nomi. Per i log, devi creare un sink per esportare le voci di log nei set di dati BigQuery, quindi filtrare i set di dati in base al nome dello spazio dei nomi del tenant. I tenant possono quindi accedere per i dati esportati in BigQuery.

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

Confini di isolamento

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

• Scollegare le responsabilità. Ogni team gestisce le risorse nei propri confini di isolamento senza preoccuparsi del resto. Ad esempio, il team di infrastruttura è responsabile solo della manutenzione dei cluster GKE. Gli operatori o gli sviluppatori sono responsabili solo della manutenzione delle pipeline CI/CD e del codice dell'applicazione.

• Controllo dell'accesso granulare. Se le risorse sono separate da limiti di isolamento, utilizza il controllo granulare dell'accesso per limitare l'accesso.

• Riduce le aree interessate. Puoi apportare modifiche in modo indipendente a un componente senza influire sugli altri componenti.

• Riduce gli errori manuali. Poiché il controllo dell'accesso è granulare, puoi evitare errori manuali come il deployment accidentale 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 sistemi CI/CD moderni è migliorare l'efficienza del processo di distribuzione del software complessivo. In termini di gestire la piattaforma, devi fare due considerazioni principali: l'onboarding, che in genere rientra nella categoria di governance; e continua lo sviluppo e la manutenzione della piattaforma, ovvero di un prodotto).

Onboarding e gestione delle applicazioni

L'obiettivo dell'adozione di una metodologia e di strumenti moderni di CI/CD è quello di snellire il processo di rilascio e l'onboarding di nuovi servizi. L'onboarding di nuove applicazioni dovrebbe essere un processo semplice che puoi eseguire con un intervento minimo dei team di operazioni e sicurezza. Ciò non significa che i team di operazioni e sicurezza non siano coinvolti, ma che il loro contributo iniziale dal punto di vista del deployment e della sicurezza viene gestito automaticamente tramite la procedura di provisioning. Dopo l’onboarding, i team operativi e di sicurezza sono naturalmente inclusi nel di rilascio del prodotto mediante richieste di unione, aggiornamenti delle norme e applicazione delle pratiche.

Ti consigliamo di 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. 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. 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 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.

Piattaforma come prodotto

Il flusso di lavoro CI/CD è un prodotto software, tranne per il fatto che gli utenti del prodotto sono i team di sviluppo, operazioni e sicurezza. Tenendo conto di questo, la piattaforma richiede gli stessi ruoli e processi di sviluppo software, come le soluzioni proprietari, marketing (anche se per uso interno), cicli di feedback degli utenti e funzionalità cicli di sviluppo.

Esegui il deployment di CI/CD con GKE

Quando inizi a eseguire il deployment di CI/CD moderni con GKE dell'organizzazione, è fondamentale scegliere le migliori applicazioni pilota. Sviluppo i team operativi e di sicurezza devono considerare anche altri fattori, di cui parleremo in questa sezione.

Selezionare un'applicazione pilota

Scegliere le prime applicazioni da spostare sulla piattaforma può essere un primo passo difficile. I candidati ideali per i progetti pilota sono i servizi che elaborano i dati o gestiscono le richieste, ma non li archiviano, ad esempio i livelli di memorizzazione nella cache, i frontend web o le applicazioni di elaborazione basate su eventi. In genere, queste applicazioni sono più resistenti a brevi interruzioni del servizio ed errori di deployment che possono verificarsi ogni volta che utilizzi nuove tecniche di gestione del deployment e della configurazione. Man mano che i team acquisiscono più esperienza con CI/CD e iniziano a trarre vantaggio in termini di affidabilità e velocità, puoi iniziare a spostare i servizi di base sulla piattaforma di distribuzione del software.

Considerazioni per gli sviluppatori

Quando lavori in un processo di sviluppo CI/CD moderno, le funzionalità, le modifiche e i deployment possono avvenire con maggiore frequenza e in modo più asincrono. I team di sviluppo devono comprendere come i cambiamenti influiranno a valle o in sistemi e come vengono testate tali modifiche. I percorsi di comunicazione tra i team di sviluppo, operativi e di sicurezza devono essere fluidi. È un buon di investire in migliori pratiche di controllo delle versioni sia per le applicazioni che contratti per i dati con cui comunicano i diversi servizi. Oltre a migliorare metodi di comunicazione e versionamento, l'implementazione di funzionalità in piccoli pezzi e l'utilizzo di flag e branch di funzionalità può migliorare il modo in cui testare e rilasciare le funzionalità.

Considerazioni per gli operatori

Con una piattaforma di distribuzione del software, i team operativi devono funzionare più come i team di sviluppo. Invece di creare funzionalità rivolte all'esterno, creando strumenti e processi interni che facilitino lo sviluppo, il deployment e il funzionamento delle applicazioni rivolte all'esterno. Gli strumenti della piattaforma utilizzati dal proprio team, nonché dai team di sviluppo e sicurezza. Operatori dovrebbero creare strumenti che contribuiscano all'implementazione di nuove versioni delle applicazioni e anche eseguendo il rollback in caso di errori dell'applicazione o del deployment. Gli operatori dovrebbero inoltre porre maggiore enfasi sulla creazione di sistemi di monitoraggio e avviso per rilevare in modo proattivo gli errori e inviare avvisi di conseguenza.

Considerazioni per il team di sicurezza

I team di sicurezza devono lavorare per rendere la sicurezza più una responsabilità condivisa tra loro e i team operativi e di sviluppo. Questo pattern è comunemente chiamato spostamento a sinistra per la sicurezza, in cui la sicurezza delle informazioni (InfoSec) è coinvolta all'inizio del processo di sviluppo, gli sviluppatori lavorano con strumenti preapprovati e i test di sicurezza sono automatizzati. Oltre a queste tecniche, puoi definire e applicare i criteri di sicurezza in modo programmatico con Policy Controller. La la combinazione di tecniche e strumenti rafforza l'applicazione della sicurezza postura proattiva.

Passaggi successivi

• Prova a implementare aspetti di questa architettura CI/CD moderna.

• Scopri di più sulle best practice per la configurazione della federazione delle identità.

• Letto Kubernetes e le sfide della distribuzione continua del software.

• Lettura di di pattern di monitoraggio e logging ibridi e multi-cloud.