🥇Pratiche di Continuous Delivery con Docker (riepilogo e video)

Iniziamo il nostro blog con articoli ispirati agli ultimi interventi del nostro Chief Technology Officer distol (Dmitrij Stolarov). Tutti si sono svolti nel 2016 durante vari eventi professionali e trattavano il tema del DevOps e di Docker. Un video, dall'incontro Docker Moscow presso l'ufficio di Badoo, è già pubblicato disponibile sul sito. I nuovi saranno accompagnati da articoli che ne riassumono il contenuto. Quindi...

Il 31 maggio, durante la conferenza RootConf 2016, svoltasi all'interno del festival "Tecnologie Internet Russe" (RIT++ 2016), la sezione "Distribuzione e Deploy Continuo" è stata inaugurata da un intervento sulle "Migliori pratiche di Continuous Delivery con Docker". In esso sono state riassunte e sistematizzate le migliori pratiche per costruire un processo di Continuous Delivery (CD) utilizzando Docker e altri prodotti open source. Lavoriamo con queste soluzioni in produzione, il che ci permette di basarci su esperienze pratiche.

Se hai la possibilità di dedicare un'ora a il video della presentazione, ti consigliamo di guardarlo completamente. In caso contrario, qui sotto trovi un riassunto principale in forma testuale.

Continuous Delivery con Docker

Sotto Continuous Delivery Comprendiamo la catena di eventi attraverso la quale il codice dell'applicazione dal repository Git arriva prima in produzione e poi viene archiviato. Si presenta così: Git → Build → Test → Release → Operate.

La maggior parte della presentazione è dedicata alla fase di build, mentre le tematiche del release e dell'operate vengono trattate in modo panoramico. Si parlerà dei problemi e dei modelli che ci permettono di risolverli, e le attuazioni specifiche di questi modelli possono variare.

Perché è necessario Docker in tutto questo? Non abbiamo scelto a caso di parlare delle pratiche di Continuous Delivery nel contesto di questo strumento Open Source. Sebbene l'intero documento sia dedicato al suo utilizzo, molte ragioni si rivelano già esaminando il principale modello di distribuzione del codice dell'applicazione.

Il principale modello di distribuzione

Quindi, durante il rilascio di nuove versioni dell'applicazione, ci troviamo inevitabilmente di fronte a un problema di inattività, che si forma durante il passaggio al server di produzione. Il traffico dalla vecchia versione dell'applicazione alla nuova non può essere commutato istantaneamente: dobbiamo prima assicurarci che la nuova versione non solo sia stata rilasciata con successo, ma anche 'riscaldata' (cioè, completamente pronta a gestire le richieste).

In questo modo, per un certo periodo entrambe le versioni dell'applicazione (la vecchia e la nuova) funzioneranno contemporaneamente. Questo porta automaticamente a un conflitto delle risorse comuni: rete, filesystem, IPC, ecc. Con Docker, questo problema si risolve facilmente eseguendo diverse versioni dell'applicazione in contenitori separati, per i quali è garantita l'isolamento delle risorse all'interno di un'unica host (server/macchina virtuale). Certo, è possibile fare a meno di alcuni accorgimenti anche senza isolamento, ma se esiste uno strumento già pronto e comodo, c'è anche un argomento contrario: non trascurarlo.

La containerizzazione offre molti altri vantaggi durante il deployment. Qualsiasi applicazione dipende da una versione specifica (o da un intervallo di versioni) dell'interprete, della disponibilità di moduli/estensioni ecc., e delle loro versioni. Questo riguarda non solo l'ambiente di esecuzione immediato, ma anche tutto l'ambiente circostante, inclusi il software di sistema e le sue versioni (fino alla specifica distribuzione Linux utilizzata). Grazie al fatto che i contenitori contengono non solo il codice delle applicazioni, ma anche il software di sistema e applicativo preinstallato nelle versioni necessarie, si possono dimenticare i problemi di dipendenze.

Facciamo un riepilogo il principale schema di diffusione di nuove versioni tenendo conto dei fattori menzionati:

In primo luogo, la vecchia versione dell'applicazione funziona nel primo contenitore.
Poi la nuova versione viene distribuita e 'riscaldata' nel secondo contenitore. È notevole che questa nuova versione possa portare non solo il codice aggiornato dell'applicazione, ma anche tutte le sue dipendenze e i componenti di sistema (ad esempio, una nuova versione di OpenSSL o dell'intera distribuzione).
Quando la nuova versione è completamente pronta per gestire le richieste, il traffico viene indirizzato dal primo contenitore al secondo.
Ora la vecchia versione può essere fermata.

Questo approccio all'implementazione di diverse versioni dell'applicazione in contenitori separati offre un ulteriore vantaggio — un rapido ripristino alla versione precedente (basta reindirizzare il traffico al contenitore corretto).

La prima raccomandazione finale è così formulata che nemmeno il Capitano può contestarla: «[nella realizzazione del Continuous Delivery con Docker] Usa Docker [e comprendi cosa offre]». Ricorda che non è una «panacea» in grado di risolvere ogni problema, ma uno strumento che fornisce una base eccezionale.

Riproducibilità

Con «riproducibilità» ci riferiamo a un insieme generale di problemi riscontrati durante l'operatività delle applicazioni. Si tratta di situazioni come:

Gli scenari verificati dal dipartimento qualità in staging devono essere replicati esattamente in produzione.
Le applicazioni vengono pubblicate su server che possono ricevere pacchetti da specchi diversi dei repository (nel tempo vengono aggiornati, e con essi anche le versioni delle applicazioni installate).
«Funziona tutto in locale!» (… e i programmatori non hanno accesso alla produzione.)
È necessario controllare qualcosa nella versione precedente (archiviata).
…

La loro essenza è che è necessario ottenere una corrispondenza completa degli ambienti utilizzati (senza fattore umano). Come garantire la riproducibilità? Creare immagini Docker basate su codice da Git, e poi utilizzarle per qualsiasi compito: su ambienti di test, in produzione, sulle macchine locali degli sviluppatori... È importante minimizzare le azioni eseguite dopo per la costruzione dell'immagine: più è semplice, minore è la probabilità di errori.

L'infrastruttura è codice

Se le richieste per l'infrastruttura (presenza di software server, le sue versioni, ecc.) non sono formalizzate e «programmate», il rilascio di qualsiasi aggiornamento dell'applicazione può finire con gravi conseguenze. Ad esempio, se su staging hai già aggiornato a PHP 7.0 e hai riscritto il codice di conseguenza, la sua apparizione in produzione con qualche vecchia versione di PHP (5.5) sorprenderà sicuramente qualcuno. Anche se non dimentichi un cambiamento significativo nella versione dell'interprete, «il diavolo è nei dettagli»: la sorpresa può arrivare in un aggiornamento minore di qualsiasi dipendenza.

L'approccio che risolve questo problema è conosciuto come IaC (Infrastructure as Code, «infrastruttura come codice») e implica la memorizzazione dei requisiti infrastrutturali insieme al codice dell'applicazione. Con il suo utilizzo, gli sviluppatori e i professionisti DevOps possono lavorare con un unico repository Git per l'applicazione, ma su diverse parti di essa. Da questo codice in Git viene creato un'immagine Docker, in cui l'applicazione è distribuita tenendo conto di tutta la specificità dell'infrastruttura. In parole semplici, gli script (regole) per la build delle immagini devono trovarsi nello stesso repository del codice sorgente e unire insieme.

Nel caso di architettura dell'applicazione a strati — ad esempio, c'è nginx che si trova davanti a un'applicazione già avviata all'interno di un contenitore Docker — le immagini Docker devono essere create dal codice in Git per ogni strato. In tal modo, la prima immagine avrà l'applicazione con l'interprete e altre dipendenze "più prossime", mentre la seconda avrà l'nginx a un livello superiore.

Immagini Docker, connessione con Git

Tutte le immagini Docker create da Git vengono suddivise in due categorie: immagini temporanee e di rilascio. Immagini temporanee sono etichettati in base al nome del ramo in Git, possono essere sovrascritti con il commit successivo e vengono rilasciati solo per la visualizzazione (non per la produzione). Questa è la loro principale differenza rispetto ai rilasci: non si sa mai quale commit specifico contengano.

Ha senso raccoglierli in immagini temporanee: il ramo master (può essere rilasciato automaticamente in un'area separata, per visualizzare continuamente l'attuale versione di master), rami con rilasci, rami di specifiche novità.

Dopo che la visualizzazione delle immagini temporanee richiede il passaggio in produzione, gli sviluppatori impostano un determinato tag. In base al tag viene automaticamente raccolto l'immagine di rilascio (il suo tag corrisponde a un tag in Git) e viene rilasciata in staging. In caso di verifica positiva da parte del team di qualità, passa in produzione.

dapp

Tutto quanto descritto (implementazione, creazione di immagini, successiva manutenzione) può essere realizzato autonomamente utilizzando script Bash e altri strumenti "alla buona". Tuttavia, seguendo questa strada, a un certo punto la realizzazione porterà a una grande complessità e cattiva gestibilità. Comprendendo ciò, abbiamo creato la nostra speciale utility Workflow per la costruzione di CI/CD — dapp.

Il suo codice sorgente è scritto in Ruby, è aperto e pubblicato su GitHub. Sfortunatamente, la documentazione attualmente è il punto più debole dello strumento, ma stiamo lavorando per migliorarlo. Non mancheremo di scrivere e raccontare nuovamente su dapp, poiché non vediamo l'ora di condividere le sue capacità con tutta la comunità interessata; nel frattempo, inviate i vostri problemi e pull request e/o seguite lo sviluppo del progetto su GitHub.

Aggiornato il 13 agosto 2019: attualmente il progetto dapp è stato rinominato in werf, il suo codice è stato completamente riscritto in Go e la documentazione è stata significativamente migliorata.

Kubernetes

Un altro strumento Open Source già ampiamente riconosciuto nella comunità professionale è Kubernetes, cluster per la gestione di Docker. Il tema del suo utilizzo nella gestione di progetti basati su Docker va oltre il relazionato, quindi la presentazione si limita a una panoramica di alcune interessanti funzionalità.

Per il rilascio Kubernetes offre:

readiness probe — verifica della prontezza della nuova versione dell'applicazione (per il commutatore del traffico su di essa);
rolling update — aggiornamento sequenziale dell'immagine nel cluster di contenitori (disattivazione, aggiornamento, preparazione al lancio, commutazione del traffico);
synchronous update — aggiornamento dell'immagine nel cluster con un approccio diverso: prima su metà dei contenitori, poi sugli altri;
canary releases — rilascio della nuova immagine su un numero limitato (ridotto) di contenitori per monitorare le anomalie.

Poiché il Continuous Delivery non è solo il rilascio di una nuova versione, in Kubernetes ci sono diverse funzionalità per la successiva manutenzione dell'infrastruttura: monitoraggio e registrazione integrati su tutti i contenitori, scalabilità automatica, e altro ancora. Tutto ciò è già operativo e attende solo un'integrazione adeguata nei vostri processi.

Raccomandazioni finali.

Utilizzate Docker.
Create immagini Docker dell'applicazione per tutte le necessità.
Segui il principio «L'infrastruttura è codice».
Collega Git a Docker.
Regola il processo di distribuzione.
Utilizza una piattaforma già pronta (Kubernetes o un'altra).

Video e slide

Video della presentazione (circa un'ora) pubblicato su YouTube (la presentazione inizia dal 5° minuto — riproduzione a partire da questo momento tramite il link).

Presentazione della relazione: