Questo articolo descrive una soluzione di distribuzione blu/verde a disponibilità elevata per le applicazioni in Azure Spring Apps.
Il modello di distribuzione blu/verde prevede la conservazione di una versione esistente di un'applicazione attiva (denominata versione blu ) mentre una nuova versione dell'applicazione viene distribuita (denominata versione verde ). Questa distribuzione consente di riavviare, riscaldare e testare la nuova versione dell'applicazione in modo indipendente. Dopo l'esecuzione della nuova versione dell'applicazione, è possibile passare a tale versione e reindirizzarvi qualsiasi nuovo traffico in ingresso. Per l'utente dell'applicazione, la distribuzione della nuova versione avviene senza tempi di inattività visibili. La distribuzione blu/verde semplifica l'abbandono di una nuova versione senza influire sulla versione dinamica se una nuova distribuzione non funziona come previsto.
Architettura
Il diagramma seguente illustra l'architettura per questo approccio:
Scaricare un file di Visio di questa architettura.
Componenti
In questa soluzione vengono usati i componenti seguenti:
Azure Spring Apps è una piattaforma di microservizi moderna per l'esecuzione di applicazioni Java Spring Boot e Steeltoe .NET Core . Il servizio elimina il codice boilerplate per l'esecuzione di microservizi e consente di sviluppare rapidamente app affidabili nel cloud. È anche possibile usare Azure Spring Apps per distribuire il codice in base all'applicazione.
GitHub è una piattaforma di hosting di codice che fornisce il controllo della versione e la collaborazione. GitHub offre il controllo della versione distribuita Git, la gestione del codice sorgente e altre funzionalità.
GitHub Actions consente di automatizzare i flussi di lavoro di sviluppo e distribuzione del software dall'interno di un repository. È possibile usare la piattaforma per creare una configurazione di integrazione continua e recapito continuo (CI/CD) completamente automatizzata. È anche possibile usare GitHub Actions per creare ambienti per i quali è possibile configurare regole come la richiesta di revisori.
Workflow
L'architettura della soluzione implementa il flusso di lavoro seguente:
Uno sviluppatore apporta una modifica a un'applicazione. Il repository GitHub contiene il codice dell'app che deve essere distribuito in Azure Spring Apps. Ogni modifica al codice dell'app viene eseguita sotto il controllo del codice sorgente. GitHub completa le attività seguenti:
Verificare che le modifiche vengano esaminate.
Impedire modifiche non intenzionali o non autorizzate.
Verificare che i controlli di qualità siano stati completati.
Il repository GitHub contiene anche un flusso di lavoro di GitHub Actions per compilare le modifiche al codice e completare i controlli di qualità necessari. Dopo la compilazione del codice, il flusso di lavoro di GitHub Actions distribuisce la versione più recente del codice dell'app in Azure Spring Apps. Il flusso di lavoro di GitHub Actions include i passaggi seguenti:
Determinare l'ambiente di produzione attivo corrente.
Distribuire il codice in un ambiente non di produzione. Se non esiste un ambiente non di produzione, creare l'ambiente.
A questo punto della distribuzione, la versione precedente (blu) dell'app nella distribuzione di produzione continua a ricevere tutto il traffico di produzione.
Attendere la revisione della distribuzione e l'approvazione della nuova app.
Questo passaggio offre all'app appena distribuita (la versione verde) l'ora di avvio e riscaldamento.
Prima dell'approvazione, è possibile usare l'URL non di produzione dell'app per verificare la nuova versione e assicurarsi che sia pronta.
Dopo l'approvazione, passare alla distribuzione di produzione e alla distribuzione non di produzione.
Tutto il traffico di produzione ora indirizza alla nuova versione dell'app.
Nota
Se si rifiuta la nuova distribuzione, GitHub non cambia gli ambienti. La versione precedente continua a ricevere traffico di produzione.
Dopo l'approvazione e il passaggio del traffico, eliminare la distribuzione di produzione precedente.
Questo passaggio di pulizia produce una configurazione più conveniente.
Alternative
Questa soluzione usa GitHub Actions per automatizzare la distribuzione. È anche possibile usare Azure Pipelines o qualsiasi altro sistema di automazione CI/CD come alternativa. L'esempio fornito nella sezione Distribuzione scenario usa le istruzioni dell'interfaccia della riga di comando di Azure il più possibile, in modo da poter convertire facilmente questa configurazione in un altro strumento di automazione. Usare uno strumento CI/CD per configurare un ambiente e creare un flusso di approvazione.
Questa architettura usa App Spring di Azure con distribuzioni come servizio di destinazione. È possibile usare app Azure slot di staging del servizio come alternativa. Uno slot contiene la nuova versione dell'applicazione, che può essere ricaricata, riscaldata e testata prima di eseguire uno scambio di slot. Lo scambio di slot inserisce la nuova versione nell'ambiente di produzione. Questo processo è integrato nel servizio, quindi la configurazione è semplice.
In alternativa, è possibile posizionare qualsiasi servizio di Azure che ospita endpoint Web dietro una soluzione di bilanciamento del carico. Se si usa questo approccio, è possibile creare una seconda istanza del servizio di Azure, in cui è possibile distribuire una nuova versione dell'applicazione. Come passaggio successivo, è possibile creare una distribuzione senza tempi di inattività passando il traffico nella soluzione di bilanciamento del carico al servizio di Azure che contiene la nuova versione dell'app. Tenere presente che questo approccio alla distribuzione blu/verde richiede un sovraccarico significativo per la gestione.
Dettagli dello scenario
Per alcune applicazioni cloud, mantenere il tempo di attività il più alto possibile è fondamentale. Una soluzione consiste nell'usare una configurazione a disponibilità elevata, che può raddoppiare i costi. Un'altra soluzione è un piano di ripristino di emergenza, che consente di visualizzare nuovamente l'applicazione in un'altra area dopo un'interruzione. Il costo per quest'ultimo potrebbe essere inferiore, ma l'intera applicazione online richiede di nuovo tempo.
Questo articolo descrive un processo per garantire la disponibilità elevata durante la distribuzione di una nuova versione di un'applicazione. In una configurazione tradizionale, i nuovi bit dell'applicazione vengono distribuiti nel servizio che ospita l'applicazione. Questa configurazione spesso comporta un ricaricamento e un riavvio dell'applicazione. Durante questo processo, l'applicazione non è disponibile.
Questa soluzione usa Azure Spring Apps per implementare la distribuzione blu/verde e risolve l'automazione della distribuzione delle applicazioni.
Potenziali casi d'uso
Questa soluzione può trarre vantaggio da qualsiasi organizzazione che richiede disponibilità elevata. La soluzione è particolarmente adatta per settori come e-commerce e giochi, in cui i tempi di inattività possono causare una perdita di business e ricavi.
È possibile migliorare ulteriormente la disponibilità implementando distribuzioni senza tempi di inattività. Per altre informazioni, vedere la sezione Alternative di questo articolo.
Considerazioni
Le considerazioni sulla soluzione seguenti implementano i pilastri di Azure Well-Architected Framework. Questo framework è 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.
Disponibilità
Questa soluzione consente di mantenere la disponibilità per l'applicazione durante la distribuzione di una nuova versione. Non aumenta il contratto di servizio complessivo fornito da Azure Spring Apps. Gli errori del servizio nella piattaforma possono comunque influire sull'app.
Se si vuole una soluzione per aumentare il contratto di servizio complessivo della configurazione, esaminare la configurazione di un servizio Azure Spring Apps a disponibilità elevata in più aree. In questo approccio la configurazione viene anteriore alla configurazione con una soluzione di bilanciamento del carico globale.
Scalabilità
Questa soluzione funziona in base all'applicazione, quindi è particolarmente adatta per le applicazioni di microservizi. Consente anche ai team dell'applicazione di lavorare indipendentemente da altri team delle applicazioni senza influenzare il tempo di attività della soluzione complessiva.
Questa soluzione funziona anche in modo ottimale per ogni applicazione, in cui ogni applicazione ha un proprio flusso di lavoro di distribuzione blu/verde. Se si combinano applicazioni nello stesso flusso di lavoro, questa configurazione diventa complessa rapidamente, quindi non è consigliabile usare questo approccio.
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.
Oltre a configurare le autorizzazioni del repository, è consigliabile implementare le misure di sicurezza seguenti nei repository Git che contengono codice da distribuire in Azure Spring Apps:
Protezione dei rami. Proteggere i rami che rappresentano lo stato di produzione dell'applicazione dalla visualizzazione diretta delle modifiche. Richiedere l'invio di ogni proposta di modifica come richiesta pull.Require every change proposal to be submitted as a pull request (PR). Usare le richieste pull per eseguire controlli automatici. I controlli possono includere la compilazione di tutto il codice e l'esecuzione di unit test nel codice creato o modificato da una richiesta pull.
Revisione pull. Per applicare il principio a quattro occhi, è necessario che le richieste pull abbiano almeno un revisore. È anche possibile usare la funzionalità GitHub dei proprietari di codice per definire singoli utenti o team responsabili della revisione di file specifici in un repository.
Cronologia non modificabile. Consenti solo nuovi commit sulle modifiche esistenti. La cronologia non modificabile è particolarmente importante ai fini del controllo.
Ulteriori misure di sicurezza. Richiedere agli utenti di GitHub di attivare l'autenticazione a più fattori. Inoltre, consentire solo i commit firmati, che non possono essere modificati in un secondo momento.
È anche consigliabile eseguire la distribuzione in un solo servizio Azure Spring Apps. In una configurazione di produzione è necessario testare il codice in altri ambienti prima di distribuirlo nell'ambiente di produzione. L'ambiente di produzione deve essere preferibilmente in un ambiente diverso rispetto all'ambiente di sviluppo e test.
Per informazioni sulla sicurezza aggiuntiva per il servizio Azure Spring Apps, vedere Distribuire App Spring di Azure in una rete virtuale. Se si implementa la distribuzione consigliata, non è possibile usare gli strumenti di esecuzione ospitati da GitHub. È necessario usare il proprio strumento di esecuzione per il flusso di lavoro di distribuzione.
DevOps
L'automazione di questa configurazione tramite i flussi di lavoro di GitHub Actions aumenta la produttività di DevOps. Una delle funzionalità più utili è la possibilità di ripristinare rapidamente le modifiche che si comportano in modo imprevisto. È sufficiente rifiutare la nuova distribuzione.
Teams spesso gestisce più ambienti per la stessa applicazione. In genere è necessario distribuire diverse versioni di un'applicazione in diversi servizi di Azure Spring Apps. Il repository Git, che è l'unica fonte di verità, mostra le versioni delle applicazioni distribuite al momento in un cluster.
Ottimizzazione dei costi
L'ottimizzazione dei costi implica la ricerca di modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
Usare il calcolatore dei prezzi di Azure per stimare i costi.
Azure Spring Apps ha un livello Basic e un livello Standard. Per informazioni dettagliate, vedere Prezzi di Azure Spring Apps. Quando si usa la strategia di distribuzione blu/verde, si paga per un spu virtuale aggiuntivo solo per un breve periodo di tempo, mentre la distribuzione viene eseguita.
GitHub offre un servizio gratuito. Tuttavia, per usare funzionalità avanzate correlate alla sicurezza, ad esempio proprietari di codice o revisori necessari, è necessario il piano team. Per altre informazioni, vedere la pagina dei prezzi di GitHub.
Distribuzione dello scenario
Per un esempio di questa configurazione, vedere il repository GitHub distribuzione automatica blu/verde per le applicazioni Azure Spring Apps. Il repository include anche i passaggi per configurare il servizio Azure Spring Apps usando un modello Bicep.
Collaboratori
Microsoft gestisce questo contenuto. Il collaboratore seguente ha sviluppato il contenuto originale.
Autore principale:
- Gitte Vermeiren | FastTrack per tecnico di Azure
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Implementare questa architettura con una guida dettagliata
- Strategie di distribuzione blu/verde in Azure Spring Apps
- Guida introduttiva: Creare e distribuire app in App Spring di Azure
- Configurare un ambiente di gestione temporanea in Azure Spring Apps
- GitHub: Informazioni su GitHub Actions
- GitHub: usare gli ambienti per la distribuzione
- GitHub: Riutilizzare i flussi di lavoro