Formazione scritta DevOps

Come eseguire deployment DevOps del codice in produzione a basso rischio?

In molte organizzazioni IT i deployment in produzione sono laboriosi e stressanti. Per lavorare tranquilli, si tende a ridurne il più possibile la frequenza. Le organizzazioni finiscono inevitabilmente per affrontare deployment in lotti più grandi, che causano problemi ancora maggiori. Questo circolo vizioso non fa che peggiorare e purtroppo descrive la situazione di gran parte delle organizzazioni più grandi, comprese quelle la cui attività principale è il software o la tecnologia.

Il team DevOps integra controlli e meccanismi di mitigazione del rischio

In una tipica organizzazione IT il team di sviluppo crea il software e quello operativo si occupa del deployment. Con DevOps i controlli e la mitigazione dei rischi passano da team esterni e indipendenti al tuo team, competente e autosufficiente, che li gestisce tramite deployment automatizzati e revisioni tra pari.

Poiché tutti gli ambienti, di produzione e non, sono risorse importanti quanto il software che il team DevOps produce, il team adotta tre principi:

1. Garantire la coerenza di tutti gli ambienti per sistemi operativi, componenti, interfacce, livelli di patch, tutte le altre dipendenze e naturalmente il proprio software e le relative configurazioni.
2. Dare massima priorità alla risoluzione di qualsiasi impedimento che comprometta la coerenza degli ambienti.
3. Eseguire il deployment con le stesse tecniche in tutti gli ambienti, così le prove di deployment in produzione diventano un'attività abituale e quotidiana.

Il meccanismo integrato di deployment self-service

Il meccanismo automatizzato di deployment self-service segue questo schema.

1. Scrivere il codice ed eseguire il check-in nel trunk.
2. Creare pacchetti pronti per il deployment.
3. Convalidare i pacchetti da distribuire, le dipendenze e la preparazione della configurazione.
4. Verificare che l'ambiente sia pronto.
5. Eseguire i test automatizzati.
6. Registrare tutti i risultati di convalida e dei test automatizzati per audit e conformità.
7. Distribuire i pacchetti nell'ambiente di destinazione.
8. Eseguire test automatizzati nell'ambiente di destinazione per convalidare il deployment.
9. Monitorare le metriche di sistema, prestazioni e attività dell'ambiente di destinazione.
10. Fornire feedback rapido e, in caso di problemi, correggere o annullare il deployment.

I deployment e i rilasci sono operazioni distinte

Con un meccanismo automatizzato self-service per distribuire codice negli ambienti di produzione e negli altri ambienti, il team DevOps può eseguire deployment quotidiani. Poiché non tutti i deployment rilasciano funzionalità o vantaggi per i clienti serviti, il team deve progettare le applicazioni e/o gli ambienti in modo che un rilascio non richieda modifiche al codice e ulteriori deployment associati.

Modello di deployment Blue-Green

Una delle difficoltà nell'automatizzare il deployment è il passaggio effettivo dall'ultima fase di test alla produzione. Di solito va eseguito rapidamente per ridurre al minimo l'inattività. Con il deployment Blue-Green mantieni due ambienti di produzione il più possibile identici. In ogni momento uno dei due, per esempio il blu, è attivo. Mentre prepari una nuova versione del software, esegui i test finali nell'ambiente verde. Quando il software funziona nel verde, riconfiguri il router perché tutte le richieste in arrivo vadano all'ambiente verde, mentre quello blu rimane inattivo.

Modello di deployment Canary
(noto anche come Dark Launch)

Un tempo, i canarini erano usati regolarmente come sistema di allerta precoce nelle miniere di carbone. Gas tossici come metano o anidride carbonica avrebbero ucciso il canarino prima di colpire i minatori. I segni di sofferenza dell'uccello avvertivano i minatori che le condizioni erano pericolose.

Ispirato all'uso dei canarini nelle miniere, il deployment Canary è un modello per distribuire le versioni a un sottoinsieme di utenti o server. L'idea è applicare la modifica a un piccolo gruppo di server, testarla e poi distribuirla agli altri. Il deployment Canary fornisce un avviso precoce e riduce l'impatto sui tempi di inattività. Se fallisce, gli altri server non ne risentono.

Facebook e Google, insieme a molti altri giganti della tecnologia, adottano una forma di deployment Canary chiamata «Dark Launch». Rilasciano e verificano gradualmente le nuove funzionalità presso un piccolo gruppo di utenti prima di renderle disponibili a tutti. In questo modo vedono se ti piacciono oppure no e valutano gli effetti sulle prestazioni del sistema. Facebook chiama il suo strumento «Gatekeeper», perché controlla l'accesso degli utenti a ogni nuova funzionalità.

Si chiama dark launch perché solitamente il rilascio non viene annunciato. La funzionalità viene resa disponibile in sordina all'1% degli utenti, poi al 5%, poi al 30% e così via. A volte una nuova funzionalità viene distribuita per qualche giorno e poi sparisce. Probabilmente non ha dato buoni risultati o l'azienda voleva solo un primo riscontro per orientarne lo sviluppo.

Modello di rilascio Cluster Immune System

È un'estensione del modello di deployment Canary. Richiede sistemi di monitoraggio delle prestazioni e delle attività del software strettamente integrati nel processo di rilascio.

Nel modello Canary illustrato sopra, dopo il deployment iniziale sul server arancione, i sistemi di monitoraggio registrano tutte le metriche di sistema, prestazioni e attività del software e generano avvisi precoci se i problemi superano determinate soglie. In tal caso viene eseguito il rollback automatico del codice installato sul server arancione.

Se i test automatizzati sul server arancione e il sistema di monitoraggio danno esito positivo, il team DevOps può distribuire il codice con molta più fiducia anche a tutti gli altri cluster di server blu. In breve, il modello di rilascio Cluster Immune System offre al team:

• Protezione aggiuntiva contro i problemi che potrebbero sfuggire ai test automatizzati.
• Riscontro rapido e rollback automatico in caso di problemi in produzione.

Feature toggle

I feature toggle permettono di attivare e disattivare le funzionalità dell'applicazione. Una volta distribuito in produzione tutto il codice necessario, basta attivare il toggle per rilasciare la funzionalità. I toggle sono solitamente impostazioni nei file di configurazione di runtime o nei database di configurazione.

Con i feature toggle, il team DevOps può disattivare una funzionalità se un deployment Canary causa errori o peggiora l'esperienza utente. Se il sistema fatica a scalare, puoi anche disattivare funzionalità che consumano molte risorse e sono relativamente meno importanti. Così, anche se il sistema fatica a scalare con tutte le funzioni attive, i clienti possono ottenere le migliori prestazioni dalle funzioni essenziali. Per esempio, in un portale e-commerce puoi disattivare temporaneamente la visualizzazione delle fatture, lasciando più risorse CPU e memoria alla procedura di acquisto.

Inoltre, in un'architettura orientata ai servizi, i team DevOps possono distribuire diverse versioni dei servizi senza attivarle. Quando tutte le nuove versioni necessarie per una funzionalità o un flusso di servizio sono state distribuite, puoi attivare i toggle dei servizi per abilitare il nuovo flusso.

Progetta l'architettura per rilasci più sicuri

Non esiste un'architettura perfetta per tutti i prodotti e servizi software di ogni dimensione.

Quando si costruisce la piattaforma IT di una startup, un'architettura monolitica è spesso la prima scelta per entrare sul mercato il più rapidamente ed economicamente possibile e convalidare il business case. Il problema è che gli aspetti funzionalmente distinti, come funzioni principali e accessorie, interfacce utente e di sistema e integrazioni, sono tutti intrecciati, anziché organizzati in componenti separati. Nel corso della propria storia molte grandi organizzazioni, tra cui Amazon, Google, Facebook ed Ebay, hanno dovuto abbandonare le architetture monolitiche per scalare rapidamente, rilasciare nuove funzionalità con meno rischi e ampliare quelle offerte ai clienti. Sono quindi passate ad architetture orientate ai servizi o microservizi, adottando lo Strangler Application Pattern.

Strangler Application Pattern per migrazioni a basso rischio verso i microservizi

Sostituire completamente un sistema complesso può essere un'impresa enorme. Spesso serve migrare gradualmente verso un nuovo sistema e mantenere il vecchio per le funzionalità che non sono ancora migrate. Eseguire due versioni separate di un'applicazione implica però che i client sappiano dove si trovano le varie funzionalità. Ogni volta che ne migri una o migri un servizio, occorre aggiornare i client affinché puntino alla nuova posizione.

Lo Strangler Application Pattern sostituisce gradualmente specifiche funzionalità con nuove applicazioni e nuovi servizi. Crea una facciata che intercetti le richieste dirette al backend legacy. La facciata le instrada all'applicazione legacy o ai nuovi servizi. Puoi migrare gradualmente le funzionalità esistenti e chi le usa continua a servirsi della stessa interfaccia senza accorgersi della migrazione.

Ebay è stata una delle prime organizzazioni a usare lo Strangler Application Pattern per migrare da un'architettura monolitica legacy ai microservizi. Ha cominciato mettendo le applicazioni dietro API universali ben definite nell'ecosistema di Ebay, senza dover riscrivere tutto il codice in una sola migrazione. Ha riorganizzato i gruppi di ingegneria in piccoli team da 6 a 10 persone. Ora un team di appena 10 persone gestisce l'API universale della piattaforma di aste, l'API per aste più usata al mondo.

CONCLUSIONE

Nella maggior parte dei reparti IT i team non sono ritenuti responsabili di costruire modelli di deployment scalabili, sicuri e capaci di durare, con le relative architetture. Eppure creare architetture e funzionalità applicative che consentano deployment più rapidi e sicuri è un requisito importante per riuscire con DevOps.

Solo mettendo i team in condizione di eseguire deployment quotidiani, più rapidi e a basso rischio, potrete beneficiare del deployment continuo e di rilasci senza intoppi.