Modifica

CI/CD per le app del servizio Azure Kubernetes con GitHub Actions e GitFlow

Registro Azure Container
Servizio Azure Kubernetes
Monitoraggio di Azure
Azure Pipelines

GitOps è un modello operativo per le applicazioni native del cloud che archivia il codice dell'applicazione e dell'infrastruttura dichiarativa in Git da usare come origine della verità per il recapito continuo automatizzato. Con GitOps si descrive lo stato desiderato dell'intero sistema in un repository Git e un operatore GitOps lo distribuisce nell'ambiente, che spesso è un cluster Kubernetes. Per altre informazioni su GitOps per Kubernetes in Azure, vedere GitOps for servizio Azure Kubernetes o CI/CD e GitOps discipline con Kubernetes abilitato per Azure Arc.

Lo scenario di esempio in questo articolo è applicabile alle aziende che vogliono modernizzare lo sviluppo di applicazioni end-to-end usando contenitori, integrazione continua (CI) per la compilazione e GitOps per la distribuzione continua (CD). In questo scenario viene usata un'app Flask come esempio. Questa app Web è costituita da un front-end scritto con Python e il framework Flask.

Architettura

Le opzioni seguenti illustrano gli approcci CI/CD basati su push e pull.

Opzione 1: CI/CD basato su push

Diagram of the push-based architecture with GitHub Actions.

Architettura basata su push con GitHub Actions per CI e CD.

Scaricare un file di Visio di questa architettura.

Flusso di dati

Questo scenario illustra una pipeline DevOps basata su push per un'applicazione Web a due livelli, con un componente Web front-end e un back-end che usa Redis. Questa pipeline usa GitHub Actions per la compilazione e la distribuzione. Il flusso dei dati nello scenario avviene come segue:

  1. Il codice dell'app viene sviluppato.
  2. Il codice dell'app viene eseguito il commit in un repository GitHub git.
  3. GitHub Actions compila un'immagine del contenitore dal codice dell'app ed esegue il push dell'immagine del contenitore in Registro Azure Container.
  4. Un processo di GitHub Actions distribuisce o esegue il push dell'app, come descritto nei file manifesto, nel cluster servizio Azure Kubernetes (servizio Azure Kubernetes) usando kubectl o l'azione Distribuisci nel cluster Kubernetes.

Opzione 2: CI/CD basato sul pull (GitOps)

Diagram of the pull-based architecture with GitHub Actions and Argo CD.

Architettura basata sul pull con GitHub Actions per CI e Argo CD per CD.

Scaricare un file di Visio di questa architettura.

Flusso di dati

Questo scenario illustra una pipeline DevOps basata sul pull per un'applicazione Web a due livelli, con un componente Web front-end e un back-end che usa Redis. Questa pipeline usa GitHub Actions per la compilazione. Per la distribuzione, usa Argo CD come operatore GitOps per eseguire il pull/sincronizzazione dell'app. Il flusso dei dati nello scenario avviene come segue:

  1. Il codice dell'app viene sviluppato.
  2. Il codice dell'app viene eseguito il commit in un repository GitHub.
  3. GitHub Actions compila un'immagine del contenitore dal codice dell'app ed esegue il push dell'immagine del contenitore in Registro Azure Container.
  4. GitHub Actions aggiorna un file di distribuzione del manifesto Kubernetes con la versione dell'immagine corrente in base al numero di versione dell'immagine del contenitore nella Registro Azure Container.
  5. Argo CD si sincronizza con o esegue il pull dal repository Git.
  6. Argo CD distribuisce l'app nel cluster del servizio Azure Kubernetes.

Componenti

  • GitHub Actions è una soluzione di automazione che può essere integrata con i servizi di Azure per l'integrazione continua (CI). In questo scenario GitHub Actions orchestra la creazione di nuove immagini del contenitore in base ai commit nel controllo del codice sorgente, esegue il push di tali immagini in Registro Azure Container, quindi aggiorna i file manifesto di Kubernetes nel repository GitHub.
  • servizio Azure Kubernetes (servizio Azure Kubernetes) è una piattaforma Kubernetes gestita che consente di distribuire e gestire applicazioni in contenitori senza competenze nell'orchestrazione dei contenitori. Come servizio Kubernetes ospitato, Azure gestisce automaticamente attività critiche come il monitoraggio dello stato e la manutenzione.
  • Registro Azure Container archivia e gestisce le immagini del contenitore usate dal cluster del servizio Azure Kubernetes. Le immagini vengono archiviate in modo sicuro e possono essere replicate dalla piattaforma Azure in altre aree per ridurre i tempi di distribuzione.
  • GitHub è un sistema di controllo del codice sorgente basato sul Web che viene eseguito su Git e usato dagli sviluppatori per archiviare e versione il codice dell'applicazione. In questo scenario, GitHub viene usato per archiviare il codice sorgente in un repository Git, quindi GitHub Actions viene usato per eseguire la compilazione e il push dell'immagine del contenitore per Registro Azure Container nell'approccio basato su push.
  • Argo CD è un operatore GitOps open source che si integra con GitHub e il servizio Azure Kubernetes. Argo CD supporta la distribuzione continua (CD). Flux potrebbe essere stato usato a questo scopo, ma Argo CD illustra come un team di app potrebbe scegliere uno strumento separato per i problemi specifici del ciclo di vita dell'applicazione, rispetto all'uso dello stesso strumento usato dagli operatori del cluster per la gestione dei cluster.
  • Monitoraggio di Azure consente di tenere traccia delle prestazioni, gestire la sicurezza e identificare le tendenze. Le metriche ottenute da Monitoraggio di Azure possono essere usate da altre risorse e strumenti, ad esempio Grafana.

Alternative

  • Azure Pipelines consente di implementare una pipeline CI/DC e di test per qualsiasi app.
  • Jenkins è un server di automazione open source che può essere integrato con i servizi di Azure per CI/CD.
  • Flux può essere usato come operatore GitOps. Può eseguire le stesse attività di Argo CD e funziona allo stesso modo con il servizio Azure Kubernetes.

Dettagli dello scenario

In questo scenario, la compilazione e la distribuzione automatizzata dell'app usano diverse tecnologie. Il codice viene sviluppato in VS Code e archiviato in un repository GitHub. GitHub Actions viene usato per compilare l'app come contenitore, quindi eseguire il push dell'immagine del contenitore in un Registro Azure Container. GitHub Actions viene usato per aggiornare il file di distribuzione del manifesto Kubernetes necessario, archiviato anche nel repository Git, mentre l'operatore GitOps Argo CD preleva i file manifesto kubernetes da questa posizione e distribuisce l'app nel cluster del servizio Azure Kubernetes.

Altri esempi includono la fornitura di un ambiente di sviluppo automatizzato, la convalida di nuovi commit di codice e il push di nuove distribuzioni in ambienti di staging o di produzione. Generalmente le aziende devono creare e compilare manualmente le applicazioni e gli aggiornamenti e gestire una base di codice monolitica di grande dimensioni. Con un approccio moderno allo sviluppo di applicazioni che usa CI e GitOps per CD, è possibile compilare, testare e distribuire rapidamente i servizi. Questo approccio moderno consente di rilasciare applicazioni e aggiornamenti ai clienti più velocemente e di rispondere a esigenze aziendali mutevoli con maggiore flessibilità.

Usando i servizi Azure e GitHub, ad esempio servizio Azure Kubernetes, Registro Container, GitHub e GitHub Actions, le aziende possono usare le tecniche e gli strumenti di sviluppo delle applicazioni più recenti per semplificare il processo di implementazione della disponibilità elevata. Inoltre, usando tecnologie open source, come Flux o Argo CD per GitOps, le aziende semplificano la distribuzione e applicano lo stato desiderato delle applicazioni.

Potenziali casi d'uso

Gli altri casi d'uso pertinenti includono:

  • Modernizzare le procedure di sviluppo di applicazioni adottando un approccio basato su contenitori e microservizi.
  • Velocizzare lo sviluppo e il ciclo di vita della distribuzione delle applicazioni.
  • Automatizzare le distribuzioni in ambienti di test o accettazione per la convalida.
  • Verificare le configurazioni e lo stato desiderato dell'applicazione.
  • Automatizzare la gestione del ciclo di vita del cluster.

Opzioni CI/CD

Questo documento illustra l'uso di GitOps per un approccio moderno alla gestione della distribuzione continua in una pipeline CI/CD. Tuttavia, ogni organizzazione è diversa. Quando si distribuiscono applicazioni in cluster Kubernetes tramite pipeline di recapito automatizzate, è importante comprendere i diversi modi in cui può essere eseguita.

Le due opzioni CI/CD più comuni per la distribuzione di un'applicazione in un cluster del servizio Azure Kubernetes sono basate su push e basate sul pull. L'opzione push usa GitHub Actions per la distribuzione continua e l'opzione pull usa GitOps per la distribuzione continua.

Opzione 1: Architettura basata su push con GitHub Actions per CI e CD

In questo approccio, il codice inizia con la parte CI della pipeline che funziona nel modo in cui viene eseguito il push delle modifiche come distribuzioni nel cluster Kubernetes. Le distribuzioni sono basate su un trigger. Esistono diversi trigger che possono avviare la distribuzione, ad esempio i commit nel repository o un trigger da un'altra pipeline di integrazione continua. Con questo approccio, il sistema della pipeline ha accesso al cluster Kubernetes. Il modulo basato su push è il modello più comune usato oggi dagli strumenti CI/CD.

Motivi per usare un approccio basato su push:

  • Flessibilità: la maggior parte degli operatori GitOps attualmente viene eseguita solo in Kubernetes. Se l'organizzazione vuole distribuire applicazioni in un ambiente diverso da Kubernetes, è necessario eseguire il push dell'applicazione in tale ambiente tramite altri strumenti CI/CD, ad esempio con GitHub Actions.

  • Efficienza: un approccio standardizzato per distribuire le applicazioni native e tradizionali del cloud è più efficiente. GitOps è attualmente più adatto per le applicazioni native del cloud eseguite in Kubernetes.

  • Semplicità: CI/CD basato su push è ben noto tra il set più ampio di tecnici in molte organizzazioni. Un approccio basato su push potrebbe essere più semplice rispetto a una combinazione di approcci CI/CD basati su push e basati sul pull.

  • Struttura: la struttura del repository corrente usata per l'applicazione potrebbe non essere adatta a GitOps, vale a dire che sarebbe necessario pianificare e ristrutturazione significativi per GitOps.

Opzione 2: Architettura basata su pull con GitHub Actions per CI e l'operatore GitOps Argo CD per CD

Questo approccio riguarda l'applicazione di eventuali modifiche dall'interno di un cluster Kubernetes. Il cluster Kubernetes include un operatore che analizza un repository Git per individuare lo stato desiderato del cluster, raccogliendo e applicando le modifiche che devono essere apportate. In questo modello, nessun client esterno dispone di credenziali a livello di amministratore per il cluster Kubernetes. Il modello pull non è nuovo, ma non è stato ampiamente usato dagli strumenti CI/CD. Recentemente, con l'introduzione di GitOps, il modello pull sta ottenendo l'adozione. Molte organizzazioni usano GitOps per facilitare la distribuzione continua nelle pipeline CD/CD.

Motivi per usare un approccio basato sul pull:

  • Coerenza: con GitOps, un operatore confronta lo stato dei cluster Kubernetes con lo stato desiderato della configurazione e delle applicazioni in un repository Git. Se si verifica una deviazione alla configurazione o alle applicazioni, l'operatore GitOps riporta automaticamente il cluster Kubernetes allo stato desiderato.

  • Sicurezza: un approccio basato sul pull per CI/CD con GitOps consente di spostare le credenziali di sicurezza nel cluster Kubernetes, riducendo così la sicurezza e la superficie di rischio rimuovendo le credenziali dall'archiviazione negli strumenti ci esterni. Sarà anche possibile ridurre le connessioni in ingresso consentite e limitare l'accesso a livello di amministratore ai cluster Kubernetes.

  • Controllo delle versioni: poiché GitOps usa un repository Git come origine della verità, la distribuzione continua ha intrinsecamente funzionalità di controllo, rollback e controllo delle versioni.

  • Multi-tenancy: un approccio basato sul pull con GitOps è ideale per i team distribuiti e la multi-tenancy. Con GitOps è possibile usare repository Git separati, diritti di accesso separati e distribuire distribuzioni in spazi dei nomi diversi.

  • Nativo del cloud: più applicazioni vengono modernizzate o create per essere native del cloud. Per qualsiasi organizzazione con la maggior parte delle applicazioni in esecuzione in Kubernetes, l'uso di un operatore GitOps per la distribuzione continua è più semplice ed efficiente rispetto a un approccio tradizionale basato su push a CI/CD.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

Per monitorare le prestazioni dell'applicazione e segnalare i problemi, questo scenario usa Monitoraggio di Azure. Consente di monitorare e risolvere i problemi di prestazioni che potrebbero richiedere aggiornamenti del codice, che possono quindi essere distribuiti con la pipeline CI/CD.

Come parte del cluster del servizio Azure Kubernetes, un servizio di bilanciamento del carico distribuisce il traffico dell'applicazione a uno o più contenitori o pod che eseguono l'applicazione. Questo approccio per l'esecuzione di applicazioni in contenitori in Kubernetes offre un'infrastruttura a disponibilità elevata per i clienti.

Nota

Questo articolo non risolve direttamente la disponibilità elevata della pipeline CI/CD. Per altre informazioni, vedere Disponibilità elevata per GitHub Actions e CD Dichiarativo di Argo CD per GitOps per Kubernetes.

I componenti di resilienza sono incorporati in Kubernetes. Questi componenti monitorano e riavviano i contenitori o i pod in caso di problemi. Quando vengono combinati più nodi Kubernetes, l'applicazione può tollerare che un pod o un nodo non sia disponibile.

Per indicazioni generali sulla progettazione di soluzioni resilienti, vedere Progettazione di applicazioni affidabili per Azure.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Per la separazione delle credenziali e delle autorizzazioni, questo scenario usa un'entità servizio Microsoft Entra dedicata. Le credenziali per questa entità servizio vengono archiviate come oggetto credenziali sicure in GitHub, come segreti di GitHub Actions, in modo che non siano esposte e visibili direttamente all'interno degli script o della pipeline di compilazione.

Per indicazioni generali sulla protezione delle applicazioni nei cluster del servizio Azure Kubernetes, vedere Concetti di sicurezza per applicazioni e cluster nel servizio Azure Kubernetes.

Per la separazione delle problematiche, il materiale sussidiario consiste nel separare il calcolo che esegue l'applicazione aziendale dagli agenti CD o dall'operatore GitOps eseguendo l'applicazione aziendale e l'operatore GitOps in spazi dei nomi separati nel cluster Kubernetes. Per una maggiore separazione dei problemi, l'operatore GitOps può essere eseguito in un cluster Kubernetes dedicato all'istanza di GitOps separata dal cluster Kubernetes di produzione che esegue l'applicazione aziendale.

Nota

Questo articolo non descrive direttamente come proteggere una pipeline CI/CD.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.

Il servizio Azure Kubernetes consente di ridimensionare il numero di nodi del cluster per soddisfare le esigenze delle applicazioni. Man mano che l'applicazione aumenta, è possibile aumentare il numero di nodi Kubernetes che eseguono il servizio.

Con GitHub Actions, il provider di servizi cloud ridimensiona automaticamente il numero di strumenti di esecuzione. Se vengono usati strumenti di esecuzione self-hosted, l'host dello strumento di esecuzione sarà responsabile della scalabilità in base alle esigenze.

Per altri argomenti sulla scalabilità, vedere l'elenco di controllo per l'efficienza delle prestazioni.

Distribuire lo scenario

Seguire la procedura descritta nell'implementazione di riferimento di AKS-baseline-automation per distribuire lo scenario. Il repository di implementazione di riferimento include procedure guidate per lo scenario CI/CD basato su push e lo scenario CI/CD (GitOps) basato sul pull.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Questo scenario usa Registro Azure Container e servizio Azure Kubernetes per archiviare ed eseguire un'applicazione basata su contenitori. Le app azure Container o le Istanze di Azure Container possono essere usate anche per eseguire applicazioni basate su contenitori, senza dover effettuare il provisioning di componenti di orchestrazione. Per altre informazioni, vedere panoramica di Istanze di Azure Container e Panoramica di App contenitore di Azure.

Documentazione sui prodotti:

Moduli di Microsoft Learn: