Comprendere le strategie di distribuzione delle applicazioni moderne con Oracle Cloud Infrastructure DevOps
La distribuzione rapida di software è fondamentale per eseguire in modo efficiente le tue applicazioni nel cloud. Il servizio Oracle DevOps offre una piattaforma di integrazione e distribuzione continue (CI/CD) che gli sviluppatori possono utilizzare per creare, testare e distribuire facilmente software e applicazioni su Oracle Cloud.
Le pipeline di creazione e distribuzione DevOps riducono gli errori basati sulle modifiche e riducono il tempo impiegato dai clienti per creare e distribuire release. Il servizio fornisce anche repository Git privati per memorizzare il codice e supportare connessioni a repository di codici esterni. Che si tratti della migrazione dei carichi di lavoro in OCI (da on-premise o da altri cloud) o dello sviluppo di nuove applicazioni su OCI, è possibile utilizzare il servizio DevOps per semplificare il ciclo di vita di consegna del software.
Architettura
Questa architettura di riferimento descrive due diverse strategie di implementazione, la strategia Blue-Green e la strategia Canary.
Le strategie di distribuzione sono modelli e procedure che consentono la modifica o l'aggiornamento dell'applicazione. Consentono ai team DevOps di definire il modo in cui le applicazioni vengono distribuite nell'ambiente di produzione. La scelta tra strategie di implementazione diverse consente agli amministratori di fare il giusto compromesso tra il rischio di distribuire una nuova release, l'impatto della nuova release sugli utenti e il sovraccarico dell'infrastruttura necessario per implementare la strategia. Le strategie qui presentate offrono ai clienti più opzioni per fare il giusto compromesso, tenuto conto delle loro esigenze applicative.
Distribuzione blu-verde
Una strategia di implementazione Blue-Green consente ai team DevOps di rilasciare una nuova versione dell'applicazione utilizzando due ambienti identici in cui uno di essi è attivo in un dato momento. Viene eseguito il provisioning della versione corrente dell'applicazione nell'ambiente attivo, mentre la nuova versione viene distribuita nell'ambiente in standby.
La distribuzione nell'ambiente in standby non ha alcun impatto sull'ambiente attivo o sul traffico utente. La pipeline di release DevOps può eseguire test di convalida sulla nuova versione e, una volta approvata, viene promossa alla produzione semplicemente passando il traffico utente all'ambiente in standby. Questo processo verrà ripetuto per ogni nuova release dell'applicazione.
Il vantaggio principale di questa strategia è che offre tempi di inattività quasi nulli e funzionalità di rollback istantaneo. Se si verificano problemi con la nuova versione, il traffico può tornare immediatamente alla versione stabile precedente. Inoltre, l'ambiente in standby è disponibile per i problemi di debug con la release dell'applicazione.
- Consente implementazioni rapide e prive di rischi.
- Offre un meccanismo di rollback semplice ed efficace.
- È un modo efficace per orchestrare i test del software A/B.
- Richiede poco o nessun tempo di inattività perché la produzione viene sempre gestita da uno degli ambienti attivi (controllati da un load balancer).
- L'esecuzione di ambienti identici è costosa e la manutenzione richiede un uso intensivo delle risorse.
- Quando si gestisce una release tra due ambienti identici, è necessario monitorare da vicino entrambi gli ambienti.
- La gestione delle dipendenze del database tra le distribuzioni può essere complessa.
Questo diagramma illustra un'architettura di implementazione Blue-Green:
Descrizione dell'immagine blue-green-deployment.png
Distribuzione canaria
Con una strategia di distribuzione Canary, la release dell'applicazione viene eseguita in modo incrementale in un subset di utenti. Inizialmente, la nuova versione viene distribuita in un ambiente canary senza traffico utente. La pipeline di release DevOps può eseguire test di convalida sulla nuova versione e, una volta pronto, instradare solo un subset di utenti all'ambiente del canale.
Questa tecnica consente al team DevOps di valutare la nuova versione dell'applicazione rispetto al traffico utente reale. Possono confrontare le due versioni delle applicazioni affiancate prima di eseguire il rollback della nuova versione a una base utenti più grande. Offre inoltre mitigazione dei rischi, in quanto la nuova versione è abilitata solo per un piccolo sottoinsieme di utenti. Questi utenti possono tornare facilmente alla versione precedente in caso di problemi.
- È possibile testare due versioni delle applicazioni affiancate con utenti reali.
- Nessun tempo di inattività per le nuove versioni.
- Il rollback a una versione precedente è molto facile e comporta il minor rischio.
- I test e la convalida di una nuova release su larga scala possono essere complessi.
- Il recupero del feedback dai test degli utenti in una nuova release richiede molto tempo.
Il diagramma riportato di seguito illustra una strategia di distribuzione Canaria.
Descrizione dell'immagine canary-deployment.png
- Area
Un'area geografica OCI è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni e le grandi distanze possono separarle (tra paesi o addirittura continenti). L'architettura utilizza una singola area.
- Progetto DevOps
Raggruppamento logico delle risorse DevOps necessarie per implementare un flusso di lavoro di integrazione e distribuzione continue. Le risorse DevOps possono essere artifact, pipeline di build, pipeline di distribuzione, connessioni esterne, trigger e ambienti. I progetti DevOps semplificano la registrazione, il monitoraggio e le notifiche di tutte le risorse DevOps.
- Pipeline di build
Una pipeline di build accetta un ID commit dai repository di codici sorgente e utilizza tale codice per eseguire le istruzioni sulla build. Le pipeline di build definiscono un set di fasi per il processo di build: creazione, test e compilazione di artifact software, consegna di artifact ai repository OCI e, facoltativamente, attivazione di una distribuzione. Il flusso e le istruzioni per l'esecuzione della build vengono definite nel file delle specifiche di build.
- Crea fasiGli stadi sono singole azioni che vengono eseguite durante l'esecuzione di una pipeline. Di seguito sono riportate alcune fasi di costruzione:
- Fasi di creazione gestite: fase di creazione gestita per la creazione e il test del codice sorgente.
- Fase di consegna degli artifact: fase in cui eseguire il PUSH degli output della fase di build in vari repository, ad esempio le immagini dei contenitori nel repository contenitore o nel file manifest di distribuzione nel registro artifact.
- Richiama distribuzione: una fase per richiamare una pipeline di distribuzione una volta completate le fasi di build, nonché per analizzare le variabili esportate dalla fase di build gestita alle fasi della pipeline di distribuzione.
- Repository codice
Repository Git privati ospitati dal servizio DevOps. È possibile memorizzare, gestire e sviluppare il codice sorgente con questi repository di codice DevOps.
- Pipeline di distribuzione
Sequenza di passi per la distribuzione e la distribuzione di un set di artifact in un ambiente di destinazione. Il flusso e la logica della release software possono essere controllati definendo fasi eseguibili in serie o parallele.
- Fasi di distribuzione
Le fasi sono singole azioni che vengono eseguite durante un'esecuzione di una pipeline. Le fasi di creazione per le distribuzioni Blue-Green sono:
- Distribuzione blu/verde OKE o Distribuzione del gruppo di istanze blu/verde: fase in cui si distribuisce il codice aggiornato negli ambienti di destinazione.
- Convalida distribuzione: fase facoltativa in cui è possibile utilizzare le funzioni per convalidare le distribuzioni.
- Controllo: approvazione: fase di controllo per l'approvazione della distribuzione nell'ambiente di produzione di destinazione.
- Spostamento del traffico OKE blu/verde o Spostamento del traffico del gruppo di istanze blu/verde: la fase finale, in cui il traffico di produzione viene passato all'ambiente di distribuzione più recente.
- Distribuzione canaria OKE o Distribuzione gruppo di istanze canarie: fase in cui si distribuisce il codice aggiornato negli ambienti di destinazione.
- Convalida distribuzione: fase facoltativa in cui è possibile utilizzare le funzioni per convalidare le distribuzioni.
- Maiusc del traffico OKE canary o Maiusc del traffico gruppo di istanze canarie: fase in cui, in base al limite di rampa (% del traffico da spostare), il traffico viene modificato verso l'ambiente Canary.
- Controllo: approvazione: fase di controllo per l'approvazione della distribuzione nell'ambiente di produzione di destinazione.
- Produzione gruppo di istanze distribuzione canaria o Produzione distribuzione OKE: la fase finale in cui il traffico di produzione viene passato all'ambiente distribuito più recente.
- Artifact DevOps
Un artifact DevOps è un riferimento o un puntatore a qualsiasi file, file binario, package, file manifesto o immagine che costituisce l'applicazione. Quando si crea un artifact, informare Oracle DevOps della posizione di origine dell'artifact effettivo. DevOps supporta il registro delle immagini del contenitore OCI e i repository del registro degli artifact OCI.
- Repository artifact
Il repository artifact crea repository per raggruppare artifact simili. Una volta creati, è possibile caricare gli artifact in questo repository. Questi artifact sono una raccolta di file di testo, file binari e file manifest di distribuzione forniti nell'ambiente di distribuzione di destinazione. Ogni artifact ha un nome, che è fatto del percorso: versione. Il percorso è una stringa per organizzare gli artifact.
- Servizi di registrazione e notifica OCI
Il servizio di log OCI memorizza i log correlati alla distribuzione. L'output di runtime della distribuzione e i risultati finali della distribuzione vengono visualizzati come voci di log. Il servizio di notifiche OCI offre visibilità sullo stato più recente del progetto di distribuzione e delle relative risorse e intraprende le azioni necessarie. Ad esempio, si riceve una notifica quando un evento importante, ad esempio una fase di una pipeline di distribuzione in attesa di approvazione. Quando si riceve il messaggio di notifica, è possibile passare alle pipeline di distribuzione DevOps e approvare la fase.
- Ambienti di distribuzione
Questo ambiente è una raccolta di risorse di calcolo in cui vengono distribuiti gli artifact. Gli ambienti possono essere una funzione, una virtual machine (VM) di computazione o un'istanza Bare Metal o un cluster OKE. La distribuzione Blue-Green è disponibile solo con i cluster OKE e le virtual machine di computazione.
Suggerimenti
- Forme di computazione
Questa architettura utilizza un'immagine del sistema operativo Oracle Linux con una forma di flexfield E3 o E4 con risorse minime per ospitare gli host di computazione nei nodi del cluster OKE. Se la tua applicazione richiede più memoria o memorie centrali, puoi scegliere una forma diversa.
- VCN
Quando crei una rete VCN, determina il numero di blocchi CIDR necessari e la dimensione di ciascun blocco in base al numero di risorse che intendi collegare alle subnet nella VCN. Usare i blocchi CIDR che si trovano all'interno dello spazio di indirizzi IP privati standard. Dopo aver creato una VCN, puoi modificare, aggiungere e rimuovere i relativi blocchi CIDR. Questa architettura utilizza una VCN pubblica per ospitare Oracle Container Engine for Kubernetes. Inoltre, puoi usare una VCN privata. In questo caso, utilizzare un gateway NAT per concedere al cluster l'accesso tramite la rete Internet pubblica.
- Oracle Container Engine for Kubernetes (OKE)
Questa architettura viene distribuita nel cluster OKE come uno degli ambienti di destinazione. I nodi di lavoro vengono distribuiti su un sistema operativo E3 o E4 Oracle Linux. Questa architettura utilizza tre nodi di lavoro nel cluster, ma è possibile creare fino a 1.000 nodi su ciascun cluster.
- Gruppo di istanze
Se scegli questa architettura per la distribuzione in un gruppo di istanze, nella tua tenancy viene creata una nuova istanza di computazione con la forma che preferisci.
- Registro immagine contenitore
Questa architettura distribuisce il registro come registro Docker privato per uso interno. Le immagini Docker vengono spostate dal registro di sistema e quindi estratte. Inoltre, puoi utilizzare il registro di sistema come registro Docker pubblico, consentendo a qualsiasi utente con accesso a Internet e conoscenza dell'URL appropriato di estrarre le immagini dai repository pubblici in Oracle Cloud.
- Registro artifact
Questa architettura crea un artifact per il software e la configurazione utilizzati da una distribuzione del gruppo di istanze, OKE e Functions. L'architettura crea un repository di registro artifact per uso interno. I file binari software, il testo e le configurazioni di distribuzione vengono caricati e scaricati dal repository del registro artifact.
Considerazioni
Quando si utilizza il servizio DevOps Oracle per distribuire una piattaforma di integrazione e distribuzione continue (CI/CD), tenere in considerazione questi fattori.
- Distribuzioni supportate da DevOps
DevOps supporta le distribuzioni in OKE, negli host di computazione e nelle funzioni. Questa architettura viene distribuita in un cluster OKE. Considera la distribuzione ad altri endpoint in base ai tuoi requisiti specifici.
- Supporto per Linux
Per le distribuzioni dei gruppi di istanze nelle istanze di computazione sono supportati solo gli host Linux.
- Artifact distribuiti
Gli artifact da distribuire con DevOps devono trovarsi in un registro artifact OCI o in un repository del registro immagini contenitore.
- Raggruppamento di applicazioni
Come best practice, raggruppa ogni applicazione e tutti i suoi microservizi in un unico progetto.
Distribuisci
Il codice Terraform per questa architettura di riferimento è disponibile come stack di esempio in Oracle Cloud Infrastructure Resource Manager. Puoi anche scaricare il codice da GitHub e personalizzarlo in base ai tuoi requisiti specifici.
- Distribuire utilizzando lo stack di esempio in Oracle Cloud Infrastructure Resource Manager:
- Fare clic sul pulsante che corrisponde alla strategia di distribuzione desiderata, quindi seguire le istruzioni riportate nei passi da 2 a 6:
Per... Fare clic... Istanze canarie 
Canary OKE Istanze blu-verde OKE verde blu Se non si è già connessi, immettere le credenziali della tenancy e dell'utente.
- Selezionare l'area in cui distribuire lo stack.
- Seguire i prompt visualizzati e le istruzioni per creare lo stack.
- Dopo aver creato lo stack, fare clic su Azioni Terraform e selezionare Plan.
- Attendere il completamento del job e rivedere il piano.
Per apportare eventuali modifiche, tornare alla pagina Dettagli stack, fare clic su Modifica stack e apportare le modifiche necessarie. Eseguire quindi di nuovo l'azione Piano.
- Se non sono necessarie ulteriori modifiche, tornare alla pagina Dettagli stack, fare clic su Azioni Terraform e selezionare Applica.
- Fare clic sul pulsante che corrisponde alla strategia di distribuzione desiderata, quindi seguire le istruzioni riportate nei passi da 2 a 6:
- Distribuiscilo utilizzando il codice Terraform in GitHub:
- Visita GitHub.
- Copiare o scaricare il repository sul computer locale.
- Seguire le istruzioni riportate nel documento
README.