Come avverare i tuoi sogni di 100% uptime con la strategia blue/green
•Download as PPTX, PDF•
0 likes•41 views
Vi è mai capitato di subire un downtime durante i rilasci del vostro software? Siete alla ricerca di modi per ridurre al minimo i rischi legati a un aggiornamento e contemporaneamente massimizzare l'uptime? Se è così, addentratevi con me in un mondo... blue/green! In questo talk esplorerò in dettaglio il concetto di blue/green strategy per i rilasci, e mostrerò anche come l'ho implementato in un caso d'uso reale in un contesto non convenzionale, con la flessbilità e la praticità di strumenti messi a disposizione da AWS.
Recommended
Recommended
More Related Content
Similar to Come avverare i tuoi sogni di 100% uptime con la strategia blue/green
Similar to Come avverare i tuoi sogni di 100% uptime con la strategia blue/green (20)
Come avverare i tuoi sogni di 100% uptime con la strategia blue/green
- 1. Monica Colangelo Come avverare i tuoi sogni di 100% uptime con la strategia blue/green
- 2. Test Rilascio Verifica Finalizzazione Come garantire un uptime 100% durante un rilascio Preparazione creazione dell’ambiente green e configurazione load balancer esecuzione test su ambiente green e monitoraggio risultati e stabilità swap versioni blue/green monitoraggio del traffico, eventuale rollback ritiro dalla produzione dell’ambiente blue
- 3. Realtà Infrastrutture legacy sistemi obsoleti che limitano la modernizzazione No budget ostacoli finanziari e/o organizzativi alla trasformazione digitale Tradizione orale conoscenza trasmessa di persona, scarsamente o per niente documentata
- 4. “Se funziona quanto basta non toccarlo che si guasta” (antico haiku della sala macchine)
- 5. Architettura “monolite” Batteria di web server “in prima linea” che servono migliaia di siti erogati da backend eterogenei (tra cui CMS) Blast radius Anni (decenni?) di configurazioni stratificate, costruite una sull’altra e talvolta inestricabili, inserite manualmente con rischio operativo elevatissimo Ownership Assenza di una ownership di progetto ben definita perché le applicazioni di backend afferiscono a team diversi e/o non più esistenti Test Ambiente di test inaffidabile per differenze di configurazioni e/o di backend Security Macchine mai aggiornate Situazione
- 6. VINCOLI Non intervenire sul “contenuto” dell’applicazione Mantenere l’architettura logica OBIETTIVI Migliorare sicurezza e affidabilità Ridurre il rischio operativo IDEA Upgrade tecnologico senza modifiche applicative Idea e obiettivi
- 7. Cosa vuol dire upgrade tecnologico PRIMA DOPO Configurazioni inserite manualmente senza uno storico Configurazioni salvate e versionate con Git Check manuali Test di correttezza sintattica Modifiche puntuali Generazione di container images con una pipeline automatica Macchine virtuali Orchestratore per gestire elasticità Gestione accessi, sicurezza, OS Minimizzazione dell’effort di gestione Rilasci manuali Rilasci automatizzati Rollback sanguinosi Rollback semplificati Strategia della speranza TEST, TEST, TEST
- 8. Test? Senza test, automatizzare significa fallire più velocemente Per ogni sistema e attività c’è un test più o meno significativo Photo by Ryan Cheng on Unsplash
- 9. Test! Photo by Christin Hume on Unsplash No regression sulle configurazioni precedenti Lista di URL dinamica Estrazione da access log con accorgimenti specifici ...dipende tutto dallo use case!
- 10. CodeBuild CodePipeline CodeDeploy ECS Fargate Lambda Check sintattico e build Orchestratore di container semplice e senza macchine Ecosistema tecnologico Per eseguire i test Rilasci automatici alla commit delle nuove configurazioni Supporto nativo della strategia blue/green
- 11. Architettura completa 1. Commit su repo unico intervento umano 2. L’evento di commit è rilevato da Eventbridge e una CodePipeline parte automaticamente 3. CodeBuild genera la container image e la salva su ECR 4. CodeDeploy crea l’ambiente green, lancia la Lambda per eseguire i test, e a seconda del risultato: a) se KO, distrugge l’ambiente green e termina il rilascio b) se OK, redirige gradualmente il traffico verso l’ambiente green; quando l’ambiente blue non riceve più traffico, lo termina
- 12. Configurazione Il load balancer viene creato con due listener su porte diverse Vengono associati due target group, di cui uno inizialmente vuoto La configurazione del rilascio viene effettuata direttamente su CodeDeploy
- 15. Risultati Durata di un rilascio Tempo di rollback Tasso di errori Uptime DevOps happiness Prima 3-4 ore 1-2 ore 40% 99.5% (downtime 1h a settimana = 2g/anno) Dopo 15 minuti immediato 2% 99.999% (downtime non misurato)