Distribuisci un'applicazione su Kubernetes

Continuous Delivery sarà interrotto nelle seguenti regioni il 12 febbraio 2027: au-syd, ca-mon, ca-tor, us-east. Anche Code Risk Analyzer e DevOps Insights saranno deprecati in tutte le regioni a partire da quella data. Tuttavia, se una regione non ha un utilizzo attivo di queste funzioni, le funzioni in quella regione possono essere interrotte prima e smettere di accettare nuove istanze. Ulteriori informazioni

In questa esercitazione, imparerai come creare una toolchain aperta utilizzando diverse strategie di distribuzione. Si apprende inoltre come vengono implementati i toolchain nel servizio IBM Cloud® Continuous Delivery e come sviluppare e distribuire una semplice applicazione web (app) utilizzando i toolchain.

Questa esercitazione è basata sul browser. È anche possibile creare una toolchain aperta simile in Terraform, come mostrato nell'esempio del provider IBM Cloud Terraform ibm-cd-toolchain-simple-helm.

Questa esercitazione usa le strategie di distribuzione che hanno Kubernetes come destinazione di distribuzione. La toolchain utilizzata in questa esercitazione implementa le pratiche DevOps standard come la scansione del codice, i test di accettazione, i repository Git e le capacità di integrazione continua e fornitura continua. Dopo aver creato un cluster Kubernetes e una toolchain, modifichi il codice della tua applicazione e distribuisci la modifica al repository Git Repos and Issue Tracking. Quando esegui il push delle modifiche al tuo repository, la pipeline di consegna basata su Tekton crea e distribuisce automaticamente il codice.

Tekton è un framework nativo Kubernetes, indipendente dal fornitore e open source che puoi utilizzare per creare, testare e distribuire le applicazioni. Tekton fornisce una serie di componenti condivisi per la creazione di sistemi di integrazione continua e di fornitura continua. Come progetto open source, Tekton è gestito da Continuous Delivery Foundation. L'obiettivo è modernizzare la fornitura continua fornendo specifiche di settore per pipeline, flussi di lavoro e altri elementi costitutivi. Con Tekton, puoi creare, testare e distribuire tra i provider cloud o i sistemi in loco astraendo i dettagli di implementazione sottostanti. Le pipeline Tekton sono integrate in Continuous Delivery.

Il modello utilizzato in questo tutorial funziona sia con il piano Standard che con quello Lite per Kubernetes. Con il piano Standard, puoi accedere alla tua applicazione tramite il nome DNS. Nel piano Lite, puoi accedere alla tua applicazione utilizzando nodeport.

È possibile utilizzare una strategia di installazione per aggiornare un'applicazione in un ambiente di produzione, in modo controllato. L'utilizzo di una strategia di distribuzione può fornire i seguenti vantaggi:

  • Evitare i tempi di inattività delle applicazioni.
  • Consente test di produzione di nuove funzioni senza impatti sui clienti.
  • Limitare l'impatto dei problemi di produzione a un sottoinsieme di utenti.
  • Abilitare il rollback rapido alla versione precedente se vengono rilevati dei problemi.

Sono disponibili molte possibili strategie di distribuzione. In generale, dipendono dall'esecuzione di più istanze dell'applicazione e dalla modalità di aggiornamento delle varie istanze. Puoi pre - configurare le seguenti strategie di distribuzione comuni in Continuous Delivery:

Base
Distribuisce la nuova release arrestando e aggiornando contemporaneamente tutte le istanze in esecuzione, causando tempi di inattività. Per il rollback, è necessario distribuire nuovamente la versione precedente, il che causa ulteriori tempi di inattività. Sebbene questa strategia sia semplice, veloce e abbia bassi requisiti di risorse di runtime, è la più rischiosa e causa tempi di inattività. La strategia di distribuzione di base non è consigliata per le applicazioni critiche che devono essere altamente disponibili.
Aggiornamento a rotazione
Simile alla strategia di base, questa strategia di distribuzione è semplice, veloce e ha requisiti di risorse di runtime bassi. Tuttavia, poiché ogni istanza in esecuzione viene disattiva e aggiornata singolarmente, evitando tempi di inattività, il rollback richiede di distribuire nuovamente la release precedente. Questo approccio dispendioso in termini di tempo potrebbe causare problemi se la versione corrente dell'app in produzione è interrotta.
Distribuzione blu-verde
Crea due ambienti di produzione separati e permanenti (blu e verdi) e solo uno di tali ambienti riceve il traffico alla volta. La release corrente viene sempre distribuita all'ambiente inattivo e il traffico viene commutato ad esso una volta completata la distribuzione, senza tempi di inattività. Poiché è necessario passare solo il traffico all'ambiente non modificato, il rollback non causa tempi di inattività. Poiché questa strategia richiede due ambienti di produzione completi, i requisiti delle risorse sono più elevati. Tuttavia, questa strategia abilita potenti flussi di sviluppatori, come la capacità di testare nuove versioni di app nell'ambiente di produzione prima di consentire il traffico del cliente. La distribuzione Blue - Green supporta anche il rollback rapido.
Rilascio a campione di utenti (canary)
Distribuisce una nuova versione in parallelo con l'ambiente di produzione originale (simile a Blue - Green), senza tempi di inattività. La quantità di traffico inviata alle istanze aggiornate e originali viene gestita in modo che la nuova versione sia disponibile per un sottoinsieme controllato di utenti mentre la distribuzione procede. Nel tempo, il traffico inviato alla nuova versione viene aumentato fino a quando non viene inviato tutto il traffico, a quel punto è possibile arrestare il vecchio ambiente di produzione. Per un rapido rollback mentre la distribuzione è in corso, puoi instradare tutto il traffico all'ambiente di produzione originale. Poiché questa strategia richiede due ambienti di produzione completi solo durante la distribuzione, l'utilizzo complessivo delle risorse è inferiore rispetto alla distribuzione Blue-Green. La strategia di distribuzione della release Canarie è la più lenta a passare da una release precedente a una release corrente del software che si sta distribuendo. Le distribuzioni Canarie consentono alle organizzazioni di testare due diverse versioni di software affiancate in produzione.

Prima di iniziare

Prima di iniziare questa esercitazione, assicurati di disporre delle seguenti risorse:

  • Un accountIBM Cloud. A seconda del tipo di account IBM Cloud, l'accesso a determinate risorse potrebbe essere limitato. A seconda dei limiti del piano dell'account, alcune funzionalità richieste da alcune strategie di distribuzione potrebbero non essere disponibili. Per ulteriori informazioni sugli account IBM Cloud, vedi Configurazione del tuo account IBM Cloud e Aggiornamento del tuo account.

  • Un clusterKubernetes e una chiave API. Puoi creare queste risorse utilizzando l'IU o la CLI. Il cluster potrebbe richiedere del tempo per il provisioning. Man mano che il cluster viene creato, procede attraverso le fasi Distribuzione, In sospeso e Pronto. Per ulteriori informazioni sui cluster Kubernetes, vedi ClusterKubernetes. Anche se puoi utilizzare le distribuzioni Rolling e Blue - Green per i piani Lite, devi creare un cluster Kubernetes per i piani Standard.

  • Un'istanza del servizio Continuous Delivery.

  • Facoltativo. Segreti archiviati in un vault di gestione dei segreti e gestiti centralmente da una sola ubicazione. Per ulteriori informazioni sulla scelta tra le varie offerte di gestione dei segreti e di protezione dei dati, vedi Gestione dei segreti IBM Cloud. Se non si dispone già di un'istanza del provider del vault di gestione dei segreti di propria scelta, crearne uno.

  • Facoltativo. Uno spazio dei nomi creato utilizzando la riga comandi del registro del contenitore. Per creare uno spazio dei nomi, digitate il seguente comando:

    ibmcloud cr namespace-add <my namespace>

    In alternativa, puoi creare uno spazio dei nomi nella pagina Container Registry. Per ulteriori informazioni sulla creazione di uno spazio dei nomi in questa posizione, consultare il servizio IBM Cloud Container Registry.

Contenuto correlato

Crea la toolchain

In questo passo, crei una toolchain Develop a Kubernetes app. Il cluster Kubernetes di destinazione viene configurato durante la configurazione della toolchain utilizzando la tua chiave API IBM Cloud e il nome cluster Kubernetes. Puoi modificare queste impostazioni successivamente aggiornando la configurazione di Delivery Pipeline. Tutto il codice che viene unito al ramo del repository Git di destinazione viene automaticamente creato, convalidato e distribuito nel cluster Kubernetes.

Per creare una toolchain Develop a Kubernetes app, fai clic su

Crea toolchain

In alternativa, dalla IBM Cloud console, clicca sull 'icona Menu > Automazione piattaforma > Toolchain. Nella pagina Toolchains, fai clic su Create a Toolchain. Nella pagina Crea una toolchain, fai clic su Sviluppa Kubernetes un'app.

Configura il nome della toolchain e la regione

Rivedi le informazioni predefinite per la configurazione della toolchain. Il nome della toolchain la identifica in IBM Cloud. Assicurati che il nome della toolchain sia univoco all'interno delle tue toolchain per la stessa regione e gruppo di risorse in IBM Cloud.

La regione della toolchain può essere diversa dal cluster e dalla regione di registro.

Kubernetes nome e regione della catena di strumenti dell'app sicura
Kubernetes nome e regione della catena di strumenti dell'app sicura

Selezionare la strategia di distribuzione

La toolchain crea una pipeline di distribuzione continua per distribuire l'immagine Docker dell'applicazione in IBM Cloud® Kubernetes Service. Selezionare la strategia di distribuzione che si desidera utilizzare. In base alla strategia di distribuzione scelta (Rolling, Blue - Green o Canary), è necessario fornire ulteriori dettagli.

  1. Fare clic sulla strategia di distribuzione che si desidera utilizzare per la toolchain.

    Kubernetes strategie
    di distribuzione sicura delle appStrategie di distribuzione

  2. Fai clic su Continue.

Configura il repository del codice sorgente dell'applicazione

Nel passo Applicazione, le opzioni consigliate per il repository del codice sorgente dell'applicazione vengono visualizzate per impostazione predefinita. Per visualizzare tutte le opzioni disponibili per l'integrazione Git sottostante, fare clic su Opzioni avanzate. Per impostazione predefinita, la toolchain utilizza l'esempio predefinito che clona l'applicazione di esempio come repository IBMospitato Git Repos and Issue Tracking.

Kubernetes repository di app sicuro repository
Kubernetes di app sicuro

Puoi modificare il nome del repository dell'app. La regione del repository rimane uguale alla regione della toolchain.

Il template della toolchain fornisce un'app esempio NodeJS. Se si desidera collegare un repository di applicazioni esistente per la toolchain, selezionare Bring your own app e specificare l' URL a per il repository. La toolchain supporta il collegamento solo ai repository Git Repos and Issue Tracking esistenti.

Per impostazione predefinita, il modello di repository dell'applicazione viene clonato nella tua Git Repos and Issue Tracking organizzazione. Per modificare l'organizzazione, abilita le Opzioni avanzate e specifica il proprietario del repository.

Configura il repository di inventario

Il repository di inventario registra i dettagli delle risorse create dalle toolchain di integrazione continua. Puoi creare un nuovo repository di inventario che sia un clone del template di repository di inventario oppure utilizzare un repository di inventario esistente che condividi tra le toolchain.

Kubernetes repository sicuro dell'inventario delle app repository
Kubernetes sicuro dell'inventario delle app

Per impostazione predefinita, il modello di repository dell'inventario viene clonato nella tua Git Repos and Issue Tracking organizzazione. Per cambiare l'organizzazione, seleziona Opzioni avanzate e specifica il proprietario del repository.

Archivia in modo sicuro i segreti

Diversi strumenti all'interno di questa toolchain richiedono segreti, come una chiave API IBM Cloud. Devi archiviare in modo sicuro tutti i segreti in un vault dei segreti e fare riferimento ad essi come richiesto dalla toolchain.

Utilizzando IBM Cloud, puoi scegliere tra diverse offerte di gestione dei segreti e di protezione dei dati che ti aiutano a proteggere i tuoi dati sensibili e centralizzare il segreto. Nel passo dei segreti, puoi specificare quali integrazioni del vault dei segreti aggiungere o rimuovere dalla tua toolchain. Per ulteriori informazioni sull'aggiunta e sulla rimozione delle integrazioni del vault, inclusi i prerequisiti e utilizzando i suggerimenti, vedi Gestione dei segreti IBM Cloud.

Utilizzando i suggerimenti all'interno di un template, una toolchain viene automaticamente popolata con segreti preconfigurati; non devi selezionare manualmente i segreti dalle integrazioni del vault che sono allegate alla toolchain.

Questa esercitazione utilizza IBM Secrets Manager come vault dei segreti.

Kubernetes Opzioni di sicurezza dei segreti
Kubernetes dell'app Opzioni di sicurezza dei segreti dell'app

IBM Secrets Manager archivia e applica in modo sicuro i segreti come le chiavi API, la firma immagine o le credenziali HashiCorp che fanno parte della tua toolchain.

Kubernetes Opzioni di sicurezza dei
Kubernetes segreti delle app Opzioni di sicurezza dei segreti delle app

Per ulteriori informazioni sulla gestione dei segreti in IBM Key Protect o HashiCorp, vedere Segreti.

Configurare la destinazione di distribuzione

Configurare il cluster Kubernetes di destinazione a cui distribuire l'app. Dopo che l'applicazione passa la fase di build, test e scansione, la pipeline distribuisce l'immagine dell'applicazione creata al cluster di destinazione Kubernetes. Questa distribuzione è ora pronta per il test di accettazione o di integrazione.

Se la chiave API ha l'accesso richiesto, i seguenti campi vengono caricati automaticamente utilizzando la chiave API creata, richiamata da un vault o specificata manualmente. Se la chiave API è valida, i valori per la regione del registro del contenitore e la regione del cluster dello spazio dei nomi, il nome, lo spazio dei nomi e il gruppo di risorse vengono popolati automaticamente. È possibile aggiornare uno qualsiasi di questi campi in modo che corrisponda alla propria configurazione.

  • Nome app: il nome dell'applicazione. Il nome app predefinito è hello-containers.

  • Chiave API IBM Cloud: la chiave API utilizzata per interagire con lo strumento CLI ibmcloud in diverse attività. Utilizzare uno dei seguenti metodi per specificare una chiave API che si desidera utilizzare:

    • Fare clic sulla chiave per importare una chiave API esistente da un vault segreto di propria scelta.
    • Copia e incolla una chiave API esistente.
    • Fare clic su Nuovo per creare una chiave API.
    • Genera un nuovo api-key se non hai una chiave API esistente.

    Puoi salvare immediatamente la chiave API generata in un vault dei segreti esistente a tua scelta.

L'applicazione viene distribuita utilizzando la strategia di distribuzione che hai specificato. Il seguente esempio mostra i dettagli per una distribuzione Rolling o Blue - Green.

Kubernetes Dettagli sull'obiettivo di distribuzione sicura delle app per Rolling o Blue-Green Dettagli sull'obiettivo
Kubernetes di distribuzione sicura delle app Rolling

Se si è selezionata la strategia di distribuzione Canary, è necessario specificare ulteriori dettagli sulla destinazione di distribuzione.

  • Dimensione passo Canarie: definisce la quantità di traffico da reindirizzare alla nuova release della distribuzione Canarie.

  • Intervallo passo Canarie: definisce l'intervallo di tempo tra ciascun test delle Canarie per passare alla nuova release della distribuzione delle Canarie.

Kubernetes Dettagli sul target di distribuzione dell'app sicura per Canary Dettagli sul target di
Kubernetes distribuzione dell'app sicura Canary

Aggiungi integrazioni strumento facoltative

Puoi aggiungere l'integrazione dello strumento IBM Cloud® DevOps Insights alla tua toolchain senza alcuna configurazione aggiuntiva.

DevOps Insights è incluso nella toolchain creata. Non devi fornire alcuna procedura di configurazione per DevOps Insights. La pipeline di integrazione continua utilizza automaticamente l'istanza DevOps Insights inclusa nella toolchain. DevOps Insights aggrega dati di codice, test, build e distribuzione per fornire visibilità nella velocità e qualità di tutti i tuoi team e release.

Fai clic su Continue.

Completa la configurazione della toolchain

Nella pagina di riepilogo, fare clic su Crea. Diversi passi vengono eseguiti automaticamente per configurare la tua toolchain.

Puoi configurare le singole integrazioni della toolchain dopo la creazione della pipeline.

Kubernetes Panoramica sulla catena di strumenti per app sicure
Kubernetes Panoramica sulla catena di strumenti per app sicure

Esplora la tua nuova toolchain

Dopo aver creato la tua toolchain, mostra ciascuna delle integrazioni dello strumento che fanno parte della toolchain in un diagramma.

Esplora le pipeline

Puoi esplorare le pipeline per comprendere il flusso della toolchain e le differenti operazioni eseguite all'interno di ogni pipeline. La toolchain appena creata contiene tre pipeline:

  • Pull request pipeline: viene eseguito quando uno sviluppatore unisce le modifiche dal proprio ramo di sviluppo al ramo master o a qualsiasi altro ramo nel repository. La pipeline di richiesta di pull esegue il test unità e le scansioni statiche sul codice sorgente dell'applicazione.
  • Pipeline di integrazione continua: viene eseguito quando si unisce una modifica nel ramo principale del repository del codice sorgente applicazione. La pipeline di integrazione continua esegue il test unità, la copertura del codice e le scansioni statiche sul codice sorgente dell'applicazione, il controllo CIS e il controllo BOM (Bill Of Materials). La pipeline di fornitura continua genera anche le risorse di build binarie e le carica in IBM Cloud® Kubernetes Service, come configurato nella toolchain. E la pipeline di integrazione continua genera i metadati delle risorse di build e li archivia nel repository Inventory.
  • Pipeline di distribuzione continua: distribuisce le risorse di build all'ambiente di distribuzione. La pipeline verifica la corretta distribuzione dell'applicazione eseguendo il controllo di integrità. È necessario attivare manualmente questa pipeline dopo il corretto completamento della pipeline di integrazione continua. A seconda della strategia di distribuzione selezionata, vengono aggiunti più trigger alla pipeline di fornitura continua.

Esegui la richiesta di pull e le pipeline di integrazione continua

Per avviare la pipeline di richiesta di pull, crea una richiesta di unione nel tuo repository dell'applicazione:

  1. Nella pagina Panoramica della toolchain, nella scheda Repository fai clic sul repository dell'applicazione compliance-app-<timestamp>.
  2. Dal repository master, crea un ramo.
  3. Aggiornare del codice nel file readme o nell'applicazione del nodo di esempio e salvare queste modifiche.
  4. Inoltrare la richiesta di integrazione.
  5. Nella pagina della panoramica della toolchain, sulla scheda Repository, fai clic sul repository pr-pipeline per avviare la pipeline di richiesta di pull. La richiesta di unione corrispondente nel repository della tua applicazione rimane nello stato in sospeso fino a quando tutte le fasi della pipeline di richiesta di pull non vengono completate correttamente.
  6. Dopo che l'esecuzione della pipeline di richiesta di pull ha esito positivo, puoi selezionarla per esplorare i passi completati.

della pipeline delle richieste di pull* Successo della pipeline delle richieste di

Per avviare la pipeline di integrazione continua, unisci la richiesta di integrazione continua nel tuo repository dell'applicazione:

  1. Andare alla richiesta di unione.
  2. Unisci la richiesta in modo che le modifiche vengano copiate nel ramo master del tuo repository dell'app. La pipeline di integrazione continua viene attivata automaticamente.
  3. Nella pagina della panoramica della toolchain di integrazione continua, sulla scheda Repository, fai clic sul repository ci-pipeline per avviare la pipeline di integrazione continua.
  4. Dopo che l'esecuzione della pipeline di integrazione continua ha esito positivo, puoi fare clic sull'esecuzione della pipeline per esplorare i passi completati.

della pipeline di integrazione
della pipeline di integrazione continua*

Pratica del cambio a sinistra

Nel mondo dello sviluppo sicuro delle app, lo shift-left è una pratica che previene e individua problemi come difetti e vulnerabilità di sicurezza ed esegue controlli di conformità nelle prime fasi del processo di consegna del software. Questa pratica di spostare i controlli di qualità all'inizio del ciclo di sviluppo comprende le seguenti pratiche:

  • Esegui i controlli che possono essere eseguiti sul codice o sul repository stesso e non hanno bisogno dell'immagine creata, il più presto possibile. Questi controlli impediscono l'unione del codice non conforme al ramo principale del repository. Poiché le prove non vengono raccolte dalla pipeline delle richieste di pull, il suo obiettivo è spostare i controlli di conformità nelle prime fasi del processo di sviluppo.
  • Tutti i controlli vengono eseguiti in ogni esecuzione della pipeline. Se un controllo precedente ha esito negativo, la pipeline passa al controllo successivo. Per valutare se hai degli errori nell'esecuzione, controlla il passo finale della tua pipeline che ha un programma di valutazione della pipeline.

I risultati dei test di unità e delle scansioni di vulnerabilità vengono pubblicati sull'istanza DevOps Insights all'interno della toolchain. Per esaminare questi risultati, fai clic sul tile DevOps Insights all'interno della toolchain e vai alla pagina Dashboard della qualità.

{: caption="dell'integrazione continua della toolchainRisultati " caption-side="bottom"}'integrazione continua della toolchain

Per valutare se si verificano errori nell'esecuzione della pipeline, controllare il passo finale della pipeline, che dispone di un programma di valutazione della pipeline.

Esplora la pipeline di fornitura continua

La richiesta di pull e le pipeline di integrazione continua sono comuni a tutte le strategie di distribuzione. Le modifiche di progettazione e implementazione della pipeline di fornitura continua si basano sulla strategia di distribuzione precedentemente selezionata in questa esercitazione.

Questa esercitazione dimostra come funziona la strategia di distribuzione progressiva utilizzando l'app di esempio.

Esplora la distribuzione progressiva

La strategia di distribuzione progressiva utilizzata in questa esercitazione dimostra come puoi utilizzare una strategia di distribuzione con Continuous Delivery Service per eseguire il tuo carico di lavoro di produzione su Kubernetes. La pipeline di fornitura continua fornisce due trigger per la distribuzione progressiva. Puoi avviare una pipeline di fornitura continua in uno dei seguenti modi:

  • Attivare manualmente la pipeline di fornitura continua.
  • Attiva automaticamente la pipeline di fornitura continua dopo ogni azione Merge nel repository Inventory. Dopo l'unione, devi attivare manualmente l'esecuzione della pipeline di consegna continua.

È stato impostato un Git Repos and Issue Tracking trigger per attivare una pipeline di consegna continua automatica, ma è disabilitato per impostazione predefinita. È possibile abilitare questo trigger dopo la prima volta che si promuove una modifica.

Trigger della pipeline di consegna continua per la distribuzione
nella pipeline di consegna continua per la distribuzione

Poiché la strategia di distribuzione progressiva aggiorna in modo incrementale tutte le istanze di produzione con la nuova versione del software, non subisce alcun tempo di inattività. Tuttavia, la strategia di rollback della distribuzione richiede la ridistribuzione della release precedente, il cui completamento potrebbe richiedere del tempo.

Dopo che la pipeline di consegna continua è stata eseguita con successo, è possibile individuare l'app URL all'interno della fase di configurazione ( perform deployment ) della pipeline di consegna continua.

Applicazione URL per la distribuzione continua
Applicazione URL in pipeline di consegna continua

Passi successivi

Se vuoi rimuovere l'applicazione di esempio in esecuzione su Kubernetes, devi ripulire il cluster Kubernetes:

  1. Andare alla home page Cluster Kubernetes.

  2. Selezionare il cluster in cui è in esecuzione l'applicazione di esempio.

  3. Fai clic su Dashboard Kubernetes.

  4. Dalla posizione in cui è in esecuzione l'applicazione di esempio, seleziona namespace.

    Kubernetes spazio dei nomi
    Kubernetes spazio dei nomi

  5. Elimina le distribuzioni, i servizi e gli ingressi correlati elencati nello spazio nomi selezionato.

È necessario aiuto?

IBM Cloud IBM l'assistente IA di , che si basa sull' watsonx di , è progettato per aiutarti a imparare a lavorare in IBM Cloud e a creare soluzioni con il catalogo di prodotti e servizi disponibili. Vedere Ottenere aiuto dall'assistente IA.

Per ulteriori opzioni di supporto, vedi Come ottenere assistenza e supporto per Continuous Delivery.