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

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 il rendimento per di sviluppo e operazioni, tra cui velocità di rilascio, affidabilità della piattaforma e tempi di ripristino dagli errori.

Questo documento fa parte di una serie:

Questo documento è rivolto agli Enterprise Architect e alle applicazioni sviluppatori, nonché per la sicurezza IT, DevOps e Site Reliability team di tecnici. Una certa esperienza con gli strumenti di deployment automatizzato è utile per comprendere i concetti esposti in questo documento.

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. Eppure, anche con l'aumento dell'adozione di Kubernetes e dei container, molte le organizzazioni non comprendono appieno i vantaggi in termini di velocità, stabilità ed efficienza operativa perché le loro pratiche CI/CD non sono sfruttare Kubernetes o risolvere problemi di operazioni e sicurezza.

Un approccio CI/CD realmente moderno deve includere qualcosa in più dell'automazione. A realizzare appieno miglioramenti in termini di velocità e sicurezza e di utilizzare la potenza in Kubernetes e nei container, devi semplificare l'onboarding delle applicazioni. pratiche CI/CD e 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 audit, rollback e revisione 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.

  • Aumento della 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 vedere come vengono realizzati questi vantaggi e concetti con GKE e CI/CD, consulta gli altri documenti di questa serie:

Valutare l'idoneità per un approccio moderno

Prima di implementare 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 della tua attività team dirigenziali e tecnici:

  • Sponsor leader. L'adozione di una piattaforma di distribuzione del software di solito è un grande impegno intrapreso da più team interfunzionali. La di processo di solito porta a cambiamenti di ruoli e responsabilità, e 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 di business. Ti consigliamo di controllare i team aziendali e quelli tecnici si allineano sulle quattro principali misure definite Ricerca e valutazione DevOps (DORA): tempo di risposta per le modifiche, frequenza di deployment, tempo per il ripristino del servizio il 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 la creazione di catene di strumenti necessitano delle risorse necessarie: tempo, persone e dell'infrastruttura. Questi team hanno bisogno di tempo provare a selezionare i processi e gli strumenti migliori. Idealmente, questi team rappresentano molte funzioni diverse del software del processo di distribuzione dei contenuti e può recuperare altre risorse dell'organizzazione. Infine, i team hanno bisogno della capacità di dell'infrastruttura, tra cui risorse cloud e 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 ed essere disposta ad adottarle. R loop di feedback in modo che i team della piattaforma possano sentire l'applicazione, le operazioni e team di sicurezza che usano la piattaforma.

  • Recupero culturale. Per avere successo nell'implementazione e nell'adozione di una sistema CI/CD moderno con GKE, l'organizzazione i team tecnici che sviluppano il sistema devono essere preparati a cambiare il modo operano e interagiscono tra loro. 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 moderno CI/CD richiede anche che i team siano tecnicamente preparato 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 hanno bisogno di esperienza nell'uso dell'CI come Jenkins, TeamCity, Bamboo e CircleCI) e l'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 esperienza con dell'automazione del deployment. Tra gli esempi di strumenti di deployment automatico ci sono gli script shell di base, Terraform, Chef o Puppet. Avere una conoscenza di base dell'automazione strumenti e processi di deployment sono fondamentali per la semplificazione e l'automazione deployment di machine learning.

  • Architetture orientate ai servizi. Sebbene non sia un prerequisito adozione di moderni processi CI/CD, adozione di altri architetture modulari e orientate ai servizi deve essere un obiettivo a lungo termine per le organizzazioni che vogliono adottare le moderne soluzioni CI/CD e le tecniche con GKE. Basato sui servizi architetture hanno dimostrato di migliorare velocità e 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 software ciclo di vita della distribuzione e come gestire coerentemente l'infrastruttura 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. Di seguito sono riportate alcune considerazioni recensito:

  • Piattaforma di distribuzione del software. Il framework e i requisiti tecnici che costituiscono le basi di un modello affidabile di rilascio dell'applicazione.

  • Infrastruttura della piattaforma. I componenti dell'infrastruttura le considerazioni sulla gestione necessarie per creare la piattaforma diverse applicazioni.

  • Flusso di lavoro di distribuzione del software. Come i team collaborano per creare, testare ed eseguire il deployment del codice in modo più efficiente.

  • Repository di codice. Repository che 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. Processi e considerazioni da 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 necessarie per creare, distribuire, sottoporre a deployment e gestire le applicazioni.

La responsabilità di mantenere la configurazione, la stabilità il tempo di attività e la scalabilità variano a seconda dell'operatore, del team di sicurezza e del team di sviluppatori, tutti i componenti e i team devono collaborare per velocizzare le release. Anche se questo documento descrive i metodi per migliorare la gestione del controllo del codice sorgente e l'osservabilità delle applicazioni, si concentra principalmente sull'integrazione continua (CI), distribuzione continua (CD) e gestione della configurazione.

Per creare una piattaforma di distribuzione del software completa, è necessario ogni componente nel seguente diagramma:

La gestione della piattaforma può essere condivisa o eseguita da team speciali.

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

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

  • Orchestrazione dei container. La piattaforma che coordina le il deployment e il funzionamento di applicazioni basate su container. Esempi di 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 delle attività automatizzate a un'applicazione prima del deployment. Le attività di CI includono in genere la creazione, pacchettizzazione e test. I tipi di attività variano in base all'applicazione e organizzazione.

  • CD. Processi di deployment con un essere automatizzati e applicati con molta frequenza. Esempi di metodologie includono approvazioni manuali, deployment canary, deployment blu/verdi o deployment di machine learning.

  • 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, l'archiviazione con controllo della versione codice, file di configurazione e definizioni dei criteri. In un ambiente CI/CD moderno la gestione del codice sorgente è in genere Git.

  • Gestione della configurazione. Il sistema utilizzato per archiviare per applicare la configurazione dell'applicazione ambienti cloud-native.

  • Osservabilità dell'applicazione. Il logging a livello di applicazione, il monitoraggio, l'avviso e il tracciamento di sviluppatori, operatori e sistemi dei team per risolvere i problemi e verificare il corretto funzionamento diverse 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 svolgere molte funzioni diverse:

  • Sviluppo. In questi cluster, gli sviluppatori eseguono deployment delle proprie applicazioni per scopi di test e sperimentazione.

  • L'ambiente applicativo.

    • Pre-produzione. Per ogni ambiente di pre-produzione flusso di lavoro, devi avere un cluster Kubernetes diverse applicazioni. Questi cluster dovrebbero assomigliare ai cluster di produzione, che è possibile 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. 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: Tre cluster coprono due regioni Google Cloud.

In questa architettura, gestisci i cluster per ogni ambiente tramite Config Sync. Una configurazione coerente del cluster è fondamentale perché offre operatore e team di sicurezza confidano nel fatto che le fasi di pre-produzione e di Google Cloud funzionano in modi simili. Puoi utilizzare Config Sync per archiviare e applicare configurazioni comuni nel parco risorse 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.

Puoi gestire i deployment nei cluster di sviluppo, gestione temporanea e produzione tramite delle 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 rispettive zone di destinazione su ciascun cluster, in modo che le applicazioni siano isolate dalla rete e dall'identità. Inizializziamo le zone di destinazione delle applicazioni in vari ambienti 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 gli sviluppatori di piattaforme iniziano a definire il processo CI/CD, devono garantire ogni componente produce o consuma artefatti che aderiscono a un a riga di comando. L'uso di un'interfaccia standardizzata semplifica la sostituzione componenti quando si tratta di una migliore implementazione sul mercato.

Quando crei una piattaforma per applicazioni containerizzate, puoi utilizzare interfacce standardizzate tra i componenti: repository Git, immagini Docker di Kubernetes. Queste interfacce consentono di creare un'interfaccia utente Pipeline CI/CD con un flusso di lavoro di sviluppo, creazione e rilascio, come di seguito il diagramma mostra:

Le fasi del flusso di lavoro includono commit, generazione, output, archiviazione e applicazione.

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 l'artefatto è archiviato in un registry.

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

  4. La configurazione dell'applicazione viene resa in un e archiviati in un repository di codice. Gli aggiornamenti di questo repository attivano un 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. 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. Oppure, gli operatori le modifiche possono al successivo deployment delle modifiche da parte degli sviluppatori.

  8. Parallelamente, i tecnici della sicurezza possono implementare e modificare criteri che di cosa può essere eseguito il deployment e poi il commit di questi criteri nei rispettivi criteri. repository Git.

Utilizzando una metodologia GitOps, puoi richiedere un approccio dichiarativo per qualsiasi modifiche alle applicazioni e ai cluster. Con questo approccio, tutte le modifiche vengono soggette a controllo 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 l'organizzazione, apportano la modifica alla base e la modifica automaticamente inserito con le API al deployment successivo.

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

  • Un processo di rollback semplificato. 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 ambiente repository per tutte le modifiche:

I repository includono quelli per le best practice, nonché per la configurazione di applicazioni e piattaforme.

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

Repository operatori

I repository gestiti dall'operatore contengono best practice per CI/CD e applicazioni per aiutare i tuoi team a eseguire l'onboarding delle applicazioni le best practice per l'organizzazione fin dall'inizio. Con operatori che gestiscono repository, gli sviluppatori possono utilizzare qualsiasi aggiornamento con il minor numero di interruzioni possibile per il 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 attività predefinite da usare per creare le proprie pipeline. Gli sviluppatori i repository di applicazioni ereditano automaticamente queste attività e la logica al suo interno che li rappresentano: non è necessario copiare manualmente le attività. 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 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 di applicazioni archiviano la logica di business dell'applicazione e di qualsiasi una configurazione specializzata necessaria affinché l'applicazione operare.

Man mano che gli operatori creano e mantengono le best practice in modo codificato, gli sviluppatori possono utilizzare queste best practice. 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 il deployment dell'applicazione aggiungendo specifiche come URL di database o etichette di risorse e annotazioni.

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

  • Codice sorgente dell'applicazione

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

  • Definizione della pipeline CI/CD

  • Estensioni o modifiche alle basi di configurazione dell'applicazione creato da 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.

Esempi di artefatti che puoi archiviare nei repository di applicazioni include:

  • 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 per operatori e tecnici della sicurezza.

Configurazione

La configurazione centralizzata consente di propagare le modifiche alla configurazione all'interno del sistema. Alcuni elementi di configurazione comuni che puoi gestire a livello centrale include:

  • Spazi dei nomi Kubernetes

  • Quote

  • Controllo di accesso basato sui ruoli (RBAC)

  • Criteri di rete

Devi applicare in modo coerente questi tipi di configurazioni in tutti gli account in modo che i team delle applicazioni non facciano un uso improprio o illecito 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.

Nella sezione architettura di riferimento, 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 della piattaforma. I repository di base possono ridurre notevolmente i costi associati con l'adozione di best practice. Le best practice, a loro volta, contribuiscono ad aumentare velocità delle funzionalità, affidabilità e produttività dei team. Nella sezione architettura di riferimento, esistono vari repository di base per configurazioni CI, CD, Kubernetes, applicazioni e infrastruttura iniziali Go, Java e Python.

Integrazione continua

Le organizzazioni di solito hanno una serie standard di attività che viene applicata delle applicazioni durante la CI. 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. Indipendentemente dalle metodologie di deployment utilizzate, il repository i 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 coerente per applicare la configurazione dell'applicazione. Utilizzando strumenti come kustomize e repository di base per le configurazioni e le piattaforme Kubernetes può fornire una base coerente per la configurazione dell'applicazione. Ad esempio, nel l'implementazione del riferimento, Configurazione di base kustomize inizializza i repository dell'ambiente dell'applicazione con un set di base noto di configurazioni. I singoli team delle applicazioni possono quindi adattare configurazioni alle loro esigenze.

Applicazioni di base

Le applicazioni Starter possono aiutarti a ridurre l'overhead associato all'adozione best practice, ad esempio osservabilità e best practice per i container.

  • Osservabilità. Per gestire in modo efficiente un'applicazione e aiutare garantire l'affidabilità, le applicazioni devono tenere conto del logging, rintracciabili. Le applicazioni di base aiutano i team a creare framework 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 la pacchettizzazione di una singola applicazione in un'immagine, rimuovendo dall'immagine strumenti non necessari e cercando attivamente produrre immagini piccole da immagini di base minime. Per ulteriori informazioni, vedi Best practice per la creazione di container.

L'architettura di riferimento fornisce app Go di base, un'app Java di base e un'app Python di base come punto di partenza. Dovresti aggiungere applicazioni di base personalizzate per linguaggi, stack tecnologici e tipi di applicazioni che i tuoi team lo sviluppo di applicazioni.

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 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 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 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 zona di destinazione è un'entità logica bloccata che consente agli sviluppatori di eseguire il deployment eseguire l'iterazione delle loro applicazioni. Le zone di destinazione delle applicazioni utilizzano i guard rail che attribuisci affinché gli sviluppatori possano operare in modo autonomo. Per ogni di un'applicazione, crei uno spazio dei nomi Kubernetes in ogni cluster (ad esempio per produzione, sviluppo o gestione temporanea). Questa coerenza consente agli operatori di eseguire il debug e gestire gli ambienti nel tempo.

Il seguente diagramma illustra il concetto di zone di destinazione:

Il cluster GKE include tre spazi dei nomi per ambienti e carichi di lavoro diversi.

Modello operativo

Quando gestisci una piattaforma di distribuzione del software con CI/CD moderni, è importante per mantenere gli ambienti, l'infrastruttura e i processi coerenti e data. 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 la e consentire ai team di concentrarsi sulla distribuzione delle applicazioni, ti consigliamo di il deployment di un'infrastruttura multi-tenant. Deployment di applicazioni su un multi-tenant elimina la necessità per i team delle applicazioni di gestire l'infrastruttura consentendo agli operatori e ai team di sicurezza di concentrarsi sul mantenimento dell'infrastruttura coerente.

Considerazioni sull'infrastruttura multi-tenant

Quando crei una piattaforma di distribuzione del software multi-tenant, esistono diverse aspetti che potresti integrare nella piattaforma:

  • Isolamento del carico 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 la ripartizione dei costi per singole spazi dei nomi ed etichette in un cluster, puoi utilizzare 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 . Puoi esporta le metriche specifiche per il tenant in set di dati BigQuery progetto tenant corrispondente, e i revisori possono analizzare tali metriche per determinare ripartizioni 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 che il deployment di ciascun tenant e la quantità di memoria e CPU utilizzate da ogni pod richiede.

  • 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 tenant. Per esaminare il delle loro applicazioni, i tenant devono accedere 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 crea un lavandino per esportare le voci di log in set di dati BigQuery e filtri i set di dati per spazio dei nomi tenant. I tenant possono quindi accedere per i dati esportati in BigQuery.

Per ulteriori informazioni su un'infrastruttura multi-tenant, consulta Best practice per la multitenancy aziendale.

Confini di isolamento

Una piattaforma di distribuzione del software è 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 il controllo 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 dell'intero processo di distribuzione del software. 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 metodi e strumenti moderni di CI/CD è quello di snellire il processo di rilascio e l'onboarding di nuovi servizi. Onboarding di nuove applicazioni dovrebbe essere un processo semplice che possa essere eseguito con un input minimo da parte di team delle operazioni e della sicurezza. Ciò non significa che operazioni e sicurezza non sono coinvolti, ma il loro input iniziale da un deployment viene gestita automaticamente attraverso il processo 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 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. 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, operativi e di 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 moderna 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 una richiesta di partecipazione al progetto pilota

Scegliere le prime applicazioni da trasferire sulla piattaforma può essere difficile primo passaggio. Sono buoni candidati per i progetti pilota i servizi che elaborano dati o gestiscono ma non archiviano dati, ad esempio strati di memorizzazione nella cache, frontend web, per applicazioni containerizzate o basate su eventi. In genere, queste applicazioni è resistente a piccoli tempi di inattività ed errori di deployment che possono verificarsi lavorare con nuove tecniche di gestione del deployment e della configurazione. Come i team acquisiscono maggiore esperienza con CI/CD e iniziano a riscontrare vantaggi affidabilità e velocità, puoi iniziare a trasferire i servizi principali di distribuzione dei contenuti.

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 sia 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. Percorsi di comunicazione tra le attività di sviluppo, le operazioni e la sicurezza devono essere fluide. È 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 controllo delle versioni, piccoli elementi e l'utilizzo di rami di funzionalità e flag può migliorare il test e il rilascio delle funzionalità.

Considerazioni sugli operatori

Con una piattaforma di distribuzione del software, i team operativi devono funzionare in modo più simile 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 eseguendone il rollback in caso di errori dell'applicazione o del deployment. Gli operatori dovrebbero inoltre porre maggiore enfasi sul monitoraggio e sull'allarme degli edifici sistemi rilevare in modo proattivo gli errori e avvisare di conseguenza.

Considerazioni del team di sicurezza

I team di sicurezza dovrebbero lavorare per rendere la sicurezza più una responsabilità condivisa e i team operativi e di sviluppo. Questo pattern è comunemente chiamato spostamento a sinistra sulla sicurezza, in cui la sicurezza delle informazioni (InfoSec) è coinvolta sin dalle prime fasi di sviluppo software, gli sviluppatori lavorano con strumenti preapprovati e i test sono automatizzati. Oltre a queste tecniche, puoi utilizzare in modo programmatico la definizione e l'applicazione dei criteri di sicurezza con Policy Controller. La combinazione di tecniche e strumenti rende l'applicazione della sicurezza in un postura proattiva.

Passaggi successivi