Cumincià u nostru blog cù publicazioni basate nantu à l'ultimi discorsi di u nostru direttore tecnicu (Dmitri Stolyarov). Tutti sò stati in 2016 in diversi avvenimenti prufessiunali è sò stati dedicati à u tema di DevOps è Docker. Un video da a riunione di Docker Moscow à l'uffiziu Badoo, avemu digià In linea. I novi seranu accumpagnati da articuli chì trasmettenu l'essenza di i rapporti. Allora…
31 di maghju à a cunferenza , tenutu cum'è parte di u festivale "Tecnulugia Russa di l'Internet" (RIT++ 2016), a sezione "Implementazione è Implantamentu Continuu" hà apertu cù u rapportu "Best Practices of Continuous Delivery with Docker". Hè riassuntu è sistematizatu e migliori pratiche per custruisce un prucessu di Consegna Continua (CD) cù Docker è altri prudutti Open Source. Travagliemu cù sti suluzioni in a pruduzzione, chì ci permette di cunfidassi nantu à l'esperienza pratica.
Sì avete l'uppurtunità di passà una ora , ricumandemu di fighjulà in tuttu. Altrimenti, quì sottu hè u riassuntu principale in forma di testu.
Consegna cuntinuu cù Docker
By Cunsigliu cuntinuu capiscenu a catena di l'eventi cum'è u risultatu di quale u codice di l'applicazione da u repository Git vene prima à a produzzione, è poi finisce in l'archiviu. Ella pare cusì: Git → Custruì → Test → Libera → Operate.
A maiò parte di u rapportu hè cunsacratu à a fase di custruzzione (assemblea di l'applicazione), è i temi chì liberanu è operanu sò toccu brevemente. Parleremu di prublemi è mudelli chì permettenu di risolve, è l'implementazioni specifiche di sti mudelli ponu esse diverse.
Perchè Docker hè necessariu quì in tuttu? Ùn hè per nunda chì avemu decisu di parlà di e pratiche di Cunsigliu Continuu in u cuntestu di questa strumentu Open Source. Ancu s'è u rapportu tutale hè cunsacratu à u so usu, parechji mutivi sò revelati quandu si cunsiderà u mudellu principale di rollout di codice di l'applicazione.
U mudellu di rollout principale
Allora, quandu avemu lanciatu novi versioni di l'applicazione, simu certamente affruntati prublema di downtime, generatu durante u cambiamentu di u servitore di produzzione. U trafficu da a vechja versione di l'applicazione à a nova ùn pò micca cambià istantaneamente: prima duvemu assicurà chì a nova versione ùn hè micca solu scaricata bè, ma ancu "riscaldata" (vale à dì, cumplettamente pronta per serve richieste).
Cusì, per qualchì tempu e duie versioni di l'applicazione (vechja è nova) funzionanu simultaneamente. Chì porta automaticamente à cunflittu di risorse spartute: rete, sistema di schedari, IPC, etc. Cù Docker, stu prublema hè facilmente risolta da eseguendu diverse versioni di l'applicazione in cuntenituri separati, per quale l'isolamentu di risorse hè garantitu in u stessu host (servitore / macchina virtuale). Di sicuru, pudete fà cun alcuni trucchi senza insulazione à tuttu, ma s'ellu ci hè un strumentu prontu è cunvene, allora ci hè u mutivu oppostu - per ùn trascuratà micca.
A cuntainerizazione furnisce assai altri benefici quandu hè implementata. Ogni applicazione dipende versione specifica (o gamma di versioni) interprete, dispunibilità di moduli / estensioni, etc., è ancu e so versioni. È questu ùn hè micca solu per l'ambiente eseguibile immediatu, ma ancu per tuttu l'ambiente, cumpresu software di sistema è a so versione (finu à a distribuzione Linux utilizata). A causa di u fattu chì i cuntenituri cuntenenu micca solu u codice di l'applicazione, ma ancu u sistema preinstallatu è u software di l'applicazioni di e versioni richieste, pudete scurdà di prublemi cù dependenzii.
Riassumemu mudellu di rollout principale novi versioni tenendu in contu i seguenti fattori:
- À u principiu, a versione vechja di l'applicazione corre in u primu containeru.
- A nova versione hè poi sparata è "riscaldata" in un secondu containeru. Hè nutate chì sta nova versione stessu pò purtà micca solu u codice di l'applicazione aghjurnatu, ma ancu qualsiasi di e so dependenze, è ancu i cumpunenti di u sistema (per esempiu, una nova versione di OpenSSL o a distribuzione sana).
- Quandu a nova versione hè cumplettamente pronta per serve e dumande, u trafficu cambia da u primu containeru à u sicondu.
- A versione vechja pò avà esse firmata.
Stu approcciu di implementà diverse versioni di l'applicazione in cuntenituri separati furnisce un'altra cunvenzione - rollback rapidu à a versione vechja (dopu tuttu, hè abbastanza per cambià u trafficu à u cuntinuu desideratu).
A prima raccomandazione finale sona cum'è qualcosa chì ancu u Capitanu ùn hà micca pussutu truvà difetti: "[quandu urganizeghja Consegna Cuntinuu cù Docker] Utilizà Docker [è capisce ciò chì dà]" Ricurdativi, questu ùn hè micca una bala d'argentu chì risolve ogni prublema, ma un strumentu chì furnisce una fundazione maravigliosa.
Riproducibilità
Per "riproducibilità" intendimu un inseme generalizatu di prublemi scontri quandu operanu applicazioni. Parlemu di tali casi:
- I scripts verificati da u dipartimentu di qualità per a messa in scena devenu esse riproduci cù precisione in a produzzione.
- L'applicazioni sò publicate nantu à i servitori chì ponu riceve pacchetti da diversi specchi di repository (in u tempu sò aghjurnati, è cun elli e versioni di l'applicazioni installate).
- "Tuttu funziona per mè in u locu!" (... è i sviluppatori ùn sò micca permessi di produzzione.)
- Avete bisognu di verificà qualcosa in a versione antica (archivata).
- ...
A so essenza generale si riduce à u fattu chì u cumpletu cumpletu di l'ambienti utilizati (cum'è l'absenza di u fattore umanu) hè necessariu. Cumu pudemu assicurà a riproducibilità? Fate l'imaghjini di Docker basatu annantu à u codice da Git, è dopu l'utilizanu per ogni compitu: in siti di teste, in pruduzzione, in machini lucali di programatori... À u listessu tempu, hè impurtante di minimizzà l'azzioni chì sò realizati. после assemblà l'imaghjini: u più simplice hè, u menu prubabile chì ci sò errori.
L'infrastruttura hè codice
Se i bisogni di l'infrastruttura (dispunibilità di u software di u servitore, a so versione, etc.) ùn sò micca formalizzati è "programati", allora u rollout di qualsiasi aghjurnamentu di l'applicazione pò esse cunsiquenzi disastrosi. Per esempiu, in staging, avete digià cambiatu à PHP 7.0 è riscrivite u codice in cunseguenza - allora a so apparizione in produzzione cù qualchì vechju PHP (5.5) certamenti sorprenderà à qualchissia. Ùn pudete micca scurdà di un cambiamentu maiò in a versione di l'interprete, ma "u diavulu hè in i dettagli": a sorpresa pò esse in una aghjurnazione minore di ogni dependenza.
Un approcciu per risolve stu prublema hè cunnisciutu cum'è IaC (Infrastructure as Code, "infrastructure as code") è implica l'almacenamiento di esigenze infrastrutturali cù u codice di l'applicazione. Aduprendu, i sviluppatori è i specialisti di DevOps ponu travaglià cù u stessu repositoriu di l'applicazioni Git, ma in diverse parti di questu. Da questu codice, una maghjina Docker hè creata in Git, in quale l'applicazione hè implementata in cunsiderà tutte e specifiche di l'infrastruttura. Simply put, i scripts (règuli) per l'assemblea di l'imaghjini duveranu esse in u stessu repository cù u codice fonte è fusionati.
In u casu di una architettura d'applicazione multi-layer - per esempiu, ci hè nginx, chì si trova davanti à una applicazione chì hè digià in esecuzione in un containeru Docker - l'imaghjini Docker deve esse creatu da u codice in Git per ogni capa. Allora a prima maghjina cuntene una applicazione cù un interprete è altre dependenzii "vicini", è a seconda maghjina cuntene u nginx upstream.
Docker images, cumunicazione cù Git
Dividemu tutte l'imaghjini Docker raccolte da Git in duie categurie: temporanee è liberate. Imàgini tempuranee tagged by the name of the branch in Git, pò esse scrittu da u prossimu impegnu è sò sbulicati solu per a vista previa (micca per a produzzione). Questa hè a so differenza chjave da quelli di liberazione: ùn sapete mai quale cummit specificu hè in elli.
Hè sensu di cullà in l'imaghjini tempuranee: u ramu maestru (pudete automaticamente roll out à un situ separatu per vede constantemente a versione attuale di u maestru), rami cù liberazioni, rami di innovazioni specifiche.
Dopu à l'anteprima di l'imaghjini tempuranee vene à a necessità di traduzzione in a produzzione, i sviluppatori mettenu una certa tag. Raccolta automaticamente per tag libera l'immagine (u so tag currisponde à l'etichetta da Git) è hè rializatu à staging. S'ellu hè verificatu cù successu da u dipartimentu di qualità, passa à a produzzione.
dapp
Tuttu ciò chì descrive (rollout, assemblea di l'imaghjini, mantenimentu sussegwente) pò esse implementatu indipindente cù script Bash è altri strumenti "improvisati". Ma s'è vo fate questu, allora in un certu puntu l'implementazione portarà à una grande cumplessità è una poca cuntrollabilità. Capendu questu, avemu ghjuntu à creà a nostra propria utilità di flussu di travagliu specializata per custruisce CI / CD - dapp.
U so codice fonte hè scrittu in Ruby, open source è publicatu nantu . Sfurtunatamente, a documentazione hè attualmente u puntu più debule di l'uttellu, ma avemu travagliatu nantu à questu. È scriveremu è parleremu di u dapp più di una volta, perchè... Sinceramente, ùn pudemu micca aspittà di sparte e so capacità cù tutta a cumunità interessata, ma intantu, mandate i vostri prublemi è tirà e dumande è / o seguite u sviluppu di u prugettu in GitHub.
Aghjurnatu 13 d'Agostu 2019: attualmente un prughjettu dapp rinominatu à , u so codice hè stata riscritta cumplettamente in Go, è a so ducumentazione hè stata mejorata significativamente.
Kubernetes
Un altru strumentu Open Source ready-made chì hà digià ricevutu ricunniscenza significativu in l'ambiente prufessiunale hè Kubernetes, un cluster di gestione Docker. U tema di u so usu in u funziunamentu di prughjetti custruiti nantu à Docker hè fora di u scopu di u rapportu, cusì a presentazione hè limitata à una visione generale di qualchi funziunalità interessanti.
Per u rollout, Kubernetes offre:
- sonda di prontezza - cuntrollà a prontezza di una nova versione di l'applicazione (per cambià u trafficu);
- aghjurnamentu rolling - aghjurnamentu sequenziale di l'imaghjini in un gruppu di cuntenituri (arrestu, aghjurnamentu, preparazione per u lanciu, cambiamentu di trafficu);
- aghjurnamentu sincronu - aghjurnà una maghjina in un cluster cù un approcciu diffirenti: prima nantu à a mità di i cuntenituri, dopu nantu à u restu;
- Canary releases - lanciazione di una nova maghjina nantu à un numeru limitatu (picculu) di cuntenituri per monitorà anomalie.
Siccomu Continuous Delivery ùn hè micca solu a liberazione di una nova versione, Kubernetes hà una quantità di capacità per u mantenimentu di l'infrastruttura sussegwenti: monitoraghju integratu è logging per tutti i cuntenituri, scaling automaticu, etc. Tuttu chistu hè digià travagliatu è hè solu aspittendu per u propiu. implementazione in i vostri prucessi.
Raccomandazioni finali
- Utilizà Docker.
- Crea l'imaghjini Docker di applicazioni per tutti i vostri bisogni.
- Segui u principiu "L'infrastruttura hè codice".
- Link Git à Docker.
- Regulà l'ordine di rollout.
- Aduprate una piattaforma pronta (Kubernetes o un altru).
Videos è slides
Video da u spettaculu (circa una ora) (u rapportu stessu principia da u 5u minutu - seguitate u ligame per ghjucà da questu mumentu).
Presentazione di u rapportu:
PS
Altri rapporti nantu à u tema nantu à u nostru blog:
- «» (Dmitry Stolyarov; 27 di maghju 2019 à DevOpsConf);
- «» (Dmitry Stolyarov; 8 di nuvembre 2018 nantu à HighLoad++);
- «» (Dmitry Stolyarov; 7 di nuvembre 2017 nantu à HighLoad++);
- «» (Dmitry Stolyarov; 6 di ghjugnu 2017 à RootConf).
Source: www.habr.com