Inizieremo il nostro blog con pubblicazioni basate sugli ultimi interventi del nostro direttore tecnico (Dmitri Stolyarov). Tutti si sono svolti nel 2016 in occasione di diversi eventi professionali e sono stati dedicati al tema DevOps e Docker. Abbiamo già un video dell'incontro di Docker Mosca presso l'ufficio di Badoo In linea. Quelli nuovi saranno accompagnati da articoli che trasmettono l'essenza dei rapporti. COSÌ…
31 maggio alla conferenza , tenutasi nell'ambito del festival “Russian Internet Technologies” (RIT++ 2016), la sezione “Continuous Deployment and Deployment” si è aperta con il rapporto “Best Practices of Continuous Delivery with Docker”. Ha riassunto e sistematizzato le migliori pratiche per la creazione di un processo di distribuzione continua (CD) utilizzando Docker e altri prodotti Open Source. Lavoriamo con queste soluzioni in produzione, il che ci consente di fare affidamento sull'esperienza pratica.
Se hai l'opportunità di trascorrere un'ora , ne consigliamo la visione integrale. Altrimenti, di seguito è riportato il riepilogo principale in forma testuale.
Consegna continua con Docker
sotto Consegna continua comprendiamo la catena di eventi a seguito della quale il codice dell'applicazione dal repository Git arriva prima in produzione e poi finisce nell'archivio. Sembra così: Git → Compila → Test → Rilascia → Opera.
La maggior parte del rapporto è dedicata alla fase di creazione (assemblaggio dell'applicazione) e gli argomenti relativi al rilascio e al funzionamento vengono brevemente trattati. Parleremo di problemi e modelli che consentono di risolverli e le implementazioni specifiche di questi modelli potrebbero essere diverse.
Perché Docker è necessario qui? Non per niente abbiamo deciso di parlare di pratiche di Continuous Delivery nel contesto di questo strumento Open Source. Sebbene l'intero rapporto sia dedicato al suo utilizzo, emergono molte ragioni quando si considera il modello principale di implementazione del codice dell'applicazione.
Modello di lancio principale
Quindi, quando lanciamo nuove versioni dell'applicazione, ci troviamo sicuramente di fronte problema dei tempi di inattività, generato durante il cambio del server di produzione. Il traffico dalla vecchia versione dell'applicazione a quella nuova non può passare istantaneamente: dobbiamo prima assicurarci che la nuova versione non solo sia stata scaricata con successo, ma anche “riscaldata” (cioè completamente pronta a servire le richieste).
Pertanto, per qualche tempo entrambe le versioni dell'applicazione (vecchia e nuova) funzioneranno contemporaneamente. Il che porta automaticamente a conflitto di risorse condivise: rete, file system, IPC, ecc. Con Docker questo problema è facilmente risolvibile eseguendo diverse versioni dell'applicazione in contenitori separati, per i quali è garantito l'isolamento delle risorse all'interno dello stesso host (server/macchina virtuale). Certo, puoi cavartela con alcuni trucchi senza isolamento, ma se esiste uno strumento già pronto e conveniente, allora c'è la ragione opposta: non trascurarlo.
La containerizzazione offre molti altri vantaggi una volta distribuita. Qualsiasi applicazione dipende da versione specifica (o gamma di versioni) interprete, disponibilità di moduli/estensioni, ecc., nonché le relative versioni. E questo vale non solo per l'ambiente eseguibile immediato, ma anche per l'intero ambiente, compreso software di sistema e la sua versione (fino alla distribuzione Linux utilizzata). Poiché i contenitori contengono non solo il codice dell'applicazione, ma anche il sistema preinstallato e il software applicativo delle versioni richieste, puoi dimenticare i problemi con le dipendenze.
Riassumere modello di lancio principale nuove versioni tenendo conto dei seguenti fattori:
- Inizialmente, la vecchia versione dell'applicazione viene eseguita nel primo contenitore.
- La nuova versione viene quindi srotolata e “riscaldata” in un secondo contenitore. È interessante notare che questa nuova versione stessa potrebbe contenere non solo il codice dell'applicazione aggiornato, ma anche le sue dipendenze, nonché componenti di sistema (ad esempio, una nuova versione di OpenSSL o l'intera distribuzione).
- Quando la nuova versione è completamente pronta per servire le richieste, il traffico passa dal primo contenitore al secondo.
- La vecchia versione ora può essere interrotta.
Questo approccio di distribuzione di diverse versioni dell'applicazione in contenitori separati offre un'altra comodità: ripristino rapido alla vecchia versione (dopo tutto, è sufficiente trasferire il traffico al contenitore desiderato).
La prima raccomandazione finale suona come qualcosa a cui nemmeno il Capitano potrebbe trovare da ridire: “[quando si organizza la consegna continua con Docker] Usa Docker [e capire cosa dà]" Ricorda, questa non è una soluzione miracolosa che risolverà ogni problema, ma uno strumento che fornisce una base meravigliosa.
Riproducibilità
Per “riproducibilità” intendiamo un insieme generalizzato di problemi incontrati durante l'utilizzo delle applicazioni. Stiamo parlando di questi casi:
- Le sceneggiature controllate dal reparto qualità per la messa in scena devono essere riprodotte accuratamente in produzione.
- Le applicazioni vengono pubblicate su server che possono ricevere pacchetti da diversi mirror di repository (nel tempo vengono aggiornati e con essi le versioni delle applicazioni installate).
- "Tutto funziona per me a livello locale!" (...e gli sviluppatori non sono ammessi nella produzione.)
- Devi controllare qualcosa nella vecchia versione (archiviata).
- ...
La loro essenza generale si riduce al fatto che è necessario il pieno rispetto degli ambienti utilizzati (nonché l'assenza del fattore umano). Come possiamo garantire la riproducibilità? Crea immagini Docker basati sul codice di Git, per poi utilizzarli per qualsiasi compito: sui siti di test, in produzione, sulle macchine locali dei programmatori... Allo stesso tempo, è importante ridurre al minimo le azioni eseguite dopo assemblare l'immagine: più è semplice, meno è probabile che ci siano errori.
L'infrastruttura è un codice
Se i requisiti infrastrutturali (disponibilità del software server, sua versione, ecc.) non sono formalizzati e “programmati”, l’implementazione di qualsiasi aggiornamento dell’applicazione può comportare conseguenze disastrose. Ad esempio, nello staging sei già passato a PHP 7.0 e hai riscritto il codice di conseguenza, quindi la sua apparizione in produzione con un vecchio PHP (5.5) sorprenderà sicuramente qualcuno. Forse non dimenticherai un cambiamento importante nella versione dell'interprete, ma "il diavolo è nei dettagli": la sorpresa potrebbe risiedere in un aggiornamento minore di qualsiasi dipendenza.
Un approccio per risolvere questo problema è noto come IaC (Infrastructure as Code, “infrastruttura come codice”) e prevede la memorizzazione dei requisiti dell'infrastruttura insieme al codice dell'applicazione. Usandolo, gli sviluppatori e gli specialisti DevOps possono lavorare con lo stesso repository di applicazioni Git, ma su parti diverse di esso. Da questo codice viene creata un'immagine Docker in Git, in cui l'applicazione viene distribuita tenendo conto di tutte le specificità dell'infrastruttura. In poche parole, gli script (regole) per l'assemblaggio delle immagini dovrebbero trovarsi nello stesso repository con il codice sorgente e uniti insieme.
Nel caso di un'architettura applicativa multi-layer - ad esempio c'è nginx, che sta di fronte a un'applicazione già in esecuzione all'interno di un container Docker - le immagini Docker devono essere create dal codice in Git per ogni layer. Quindi la prima immagine conterrà un'applicazione con un interprete e altre dipendenze "vicine", e la seconda immagine conterrà nginx upstream.
Immagini Docker, comunicazione con Git
Dividiamo tutte le immagini Docker raccolte da Git in due categorie: temporanee e di rilascio. Immagini temporanee contrassegnati dal nome del ramo in Git, possono essere sovrascritti dal commit successivo e vengono implementati solo per l'anteprima (non per la produzione). Questa è la differenza fondamentale rispetto a quelle di rilascio: non si sa mai quale commit specifico contenga.
Ha senso raccogliere in immagini temporanee: il ramo master (puoi distribuirlo automaticamente in un sito separato per vedere costantemente la versione corrente del master), rami con versioni, rami di innovazioni specifiche.
Dopo che l'anteprima delle immagini temporanee arriva alla necessità di tradurle in produzione, gli sviluppatori inseriscono un determinato tag. Raccolti automaticamente per tag rilasciare l'immagine (il suo tag corrisponde al tag di Git) e viene distribuito allo staging. Se viene verificato con successo dal reparto qualità, passa alla produzione.
Dapp
Tutto quanto descritto (rollout, assemblaggio delle immagini, successiva manutenzione) può essere implementato autonomamente utilizzando script Bash e altri strumenti “improvvisati”. Ma se lo fai, a un certo punto l'implementazione porterà a una grande complessità e a una scarsa controllabilità. Comprendendo questo, siamo arrivati a creare la nostra utilità di flusso di lavoro specializzata per la creazione di CI/CD: Dapp.
Il suo codice sorgente è scritto in Ruby, open source e pubblicato su . Sfortunatamente la documentazione è attualmente il punto più debole dello strumento, ma ci stiamo lavorando. E scriveremo e parleremo del dapp più di una volta, perché... Sinceramente non vediamo l'ora di condividere le sue capacità con l'intera comunità interessata, ma nel frattempo inviate i vostri problemi e richieste pull e/o seguite lo sviluppo del progetto su GitHub.
Aggiornato il 13 agosto 2019: attualmente un progetto Dapp rinominato in , il suo codice è stato completamente riscritto in Go e la sua documentazione è stata notevolmente migliorata.
kubernetes
Un altro strumento Open Source già pronto che ha già ricevuto un riconoscimento significativo nell'ambiente professionale è kubernetes,un cluster di gestione Docker. L'argomento del suo utilizzo nel funzionamento di progetti basati su Docker va oltre lo scopo del rapporto, quindi la presentazione si limita a una panoramica di alcune funzionalità interessanti.
Per l'implementazione, Kubernetes offre:
- sonda di disponibilità: verifica della disponibilità di una nuova versione dell'applicazione (per trasferire il traffico ad essa);
- aggiornamento in sequenza: aggiornamento sequenziale dell'immagine in un cluster di contenitori (spegnimento, aggiornamento, preparazione al lancio, cambio di traffico);
- aggiornamento sincrono - aggiornamento di un'immagine in un cluster con un approccio diverso: prima su metà dei contenitori, poi sul resto;
- rilasci canary: lancio di una nuova immagine su un numero limitato (piccolo) di contenitori per monitorare le anomalie.
Poiché la consegna continua non significa solo il rilascio di una nuova versione, Kubernetes dispone di una serie di funzionalità per la successiva manutenzione dell'infrastruttura: monitoraggio e registrazione integrati per tutti i contenitori, ridimensionamento automatico, ecc. Tutto questo sta già funzionando e sta solo aspettando il corretto implementazione nei vostri processi.
Raccomandazioni finali
- Usa Docker.
- Crea immagini Docker di applicazioni per tutte le tue esigenze.
- Segui il principio “L’infrastruttura è codice”.
- Collega Git a Docker.
- Regolamentare l'ordine di implementazione.
- Utilizza una piattaforma già pronta (Kubernetes o altro).
Video e diapositive
Video dello spettacolo (circa un'ora) (il resoconto stesso inizia dal 5° minuto - segui il link per giocare da questo momento).
Presentazione del rapporto:
PS
Altri resoconti sull'argomento sul nostro blog:
- «» (Dmitry Stolyarov; 27 maggio 2019 alla DevOpsConf);
- «» (Dmitry Stolyarov; 8 novembre 2018 su HighLoad++);
- «» (Dmitry Stolyarov; 7 novembre 2017 su HighLoad++);
- «» (Dmitry Stolyarov; 6 giugno 2017 su RootConf).
Fonte: habr.com