Vom începe blogul nostru cu publicații bazate pe ultimele discursuri ale directorului nostru tehnic (Dmitri Stolyarov). Toate au avut loc în 2016 la diverse evenimente profesionale și au fost dedicate subiectului DevOps și Docker. Avem deja un videoclip de la întâlnirea Docker Moscow de la biroul Badoo Pe net. Cele noi vor fi însoțite de articole care transmit esența rapoartelor. Asa de…
31 mai la conferință , desfășurat în cadrul festivalului „Russian Internet Technologies” (RIT++ 2016), secțiunea „Continuous Deployment and Deployment” s-a deschis cu raportul „Best Practices of Continuous Delivery with Docker”. Acesta a rezumat și sistematizat cele mai bune practici pentru construirea unui proces de livrare continuă (CD) folosind Docker și alte produse Open Source. Lucrăm cu aceste soluții în producție, ceea ce ne permite să ne bazăm pe experiența practică.
Dacă aveți ocazia să petreceți o oră , vă recomandăm să îl vizionați integral. În caz contrar, mai jos este rezumatul principal sub formă de text.
Livrare continuă cu Docker
În Livrarea continuă înțelegem lanțul de evenimente în urma căruia codul aplicației din depozitul Git vine mai întâi în producție și apoi ajunge în arhivă. Ea arata asa: Git → Construire → Testare → Lansare → Operare.
Cea mai mare parte a raportului este dedicată etapei de construire (asamblarea aplicației), iar subiectele lansare și operare sunt atinse pe scurt. Vom vorbi despre probleme și modele care vă permit să le rezolvați, iar implementările specifice ale acestor modele pot fi diferite.
De ce este nevoie de Docker aici? Nu degeaba am decis să vorbim despre practicile de livrare continuă în contextul acestui instrument Open Source. Deși întregul raport este dedicat utilizării sale, multe motive sunt dezvăluite atunci când se ia în considerare modelul principal de lansare a codului aplicației.
Modelul principal de lansare
Deci, atunci când lansăm noi versiuni ale aplicației, cu siguranță ne confruntăm cu problema cu timpul de nefuncţionare, generat în timpul comutării serverului de producție. Traficul de la versiunea veche a aplicației la cea nouă nu poate trece instantaneu: mai întâi trebuie să ne asigurăm că noua versiune nu este doar descărcată cu succes, ci și „încălzită” (adică, complet pregătită pentru a servi cererile).
Astfel, de ceva timp ambele versiuni ale aplicației (veche și nouă) vor funcționa simultan. Ceea ce duce automat la conflict de resurse partajate: rețea, sistem de fișiere, IPC etc. Cu Docker, această problemă este ușor de rezolvat prin rularea diferitelor versiuni ale aplicației în containere separate, pentru care izolarea resurselor este garantată în cadrul aceleiași gazde (server/mașină virtuală). Desigur, vă puteți descurca cu unele trucuri fără izolație deloc, dar dacă există un instrument gata făcut și convenabil, atunci există un motiv opus - să nu îl neglijați.
Containerizarea oferă multe alte beneficii atunci când este implementată. Orice aplicație depinde de versiune specifică (sau gama de versiuni) interpret, disponibilitatea modulelor/extensiunilor etc., precum și a versiunilor acestora. Și acest lucru se aplică nu numai mediului executabil imediat, ci și întregului mediu, inclusiv programul sistemului și versiunea acesteia (până la distribuția Linux utilizată). Datorită faptului că containerele conțin nu numai codul aplicației, ci și software-ul de sistem și aplicația preinstalat al versiunilor necesare, puteți uita de problemele legate de dependențe.
Să generalizăm modelul principal de lansare versiuni noi, luând în considerare următorii factori:
- La început, versiunea veche a aplicației rulează în primul container.
- Noua versiune este apoi lansată și „încălzită” într-un al doilea container. Este de remarcat faptul că această nouă versiune în sine poate conține nu numai codul de aplicație actualizat, ci și oricare dintre dependențele sale, precum și componente de sistem (de exemplu, o nouă versiune a OpenSSL sau întreaga distribuție).
- Când noua versiune este complet pregătită pentru a servi cererile, traficul trece de la primul container la al doilea.
- Vechea versiune poate fi acum oprită.
Această abordare de implementare a diferitelor versiuni ale aplicației în containere separate oferă o altă comoditate - rollback rapid la versiunea veche (la urma urmei, este suficient să comutați traficul către containerul dorit).
Prima recomandare finală sună ca ceva la care nici măcar căpitanul nu a putut găsi de vină: „[când se organizează livrarea continuă cu Docker] Folosiți Docker [și înțelegeți ce oferă]" Amintiți-vă, acesta nu este un glonț de argint care va rezolva orice problemă, ci un instrument care oferă o bază minunată.
Reproductibilitatea
Prin „reproductibilitate” înțelegem un set generalizat de probleme întâlnite la operarea aplicațiilor. Vorbim despre astfel de cazuri:
- Scripturile verificate de departamentul de calitate pentru montare trebuie reproduse cu acuratețe în producție.
- Aplicațiile sunt publicate pe servere care pot primi pachete din diferite oglinzi de depozit (în timp sunt actualizate, iar odată cu acestea și versiunile aplicațiilor instalate).
- „Totul funcționează pentru mine la nivel local!” (...și dezvoltatorii nu au voie să intre în producție.)
- Trebuie să verificați ceva în versiunea veche (arhivată).
- ...
Esența lor generală se rezumă la faptul că este necesară respectarea deplină a mediilor utilizate (precum și absența factorului uman). Cum putem garanta reproductibilitatea? Creați imagini Docker bazate pe codul din Git, și apoi să le folosiți pentru orice sarcină: pe site-uri de testare, în producție, pe mașini locale ale programatorilor... În același timp, este important să minimizați acțiunile care sunt efectuate după asamblarea imaginii: cu cât este mai simplă, cu atât mai puțin probabil să apară erori.
Infrastructura este cod
Dacă cerințele de infrastructură (disponibilitatea software-ului server, versiunea acestuia etc.) nu sunt oficializate și „programate”, atunci lansarea oricărei actualizări a aplicației poate avea consecințe dezastruoase. De exemplu, la montaj ați trecut deja la PHP 7.0 și ați rescris codul în consecință - atunci apariția lui în producție cu PHP vechi (5.5) va surprinde cu siguranță pe cineva. Poate nu uitați de o schimbare majoră în versiunea interpretului, dar „diavolul este în detalii”: surpriza poate fi într-o actualizare minoră a oricărei dependențe.
O abordare pentru a rezolva această problemă este cunoscută ca IaC (Infrastructura ca cod, „infrastructura ca cod”) și implică stocarea cerințelor de infrastructură împreună cu codul aplicației. Folosind-o, dezvoltatorii și specialiștii DevOps pot lucra cu același depozit de aplicații Git, dar în părți diferite ale acestuia. Din acest cod este creată o imagine Docker în Git, în care aplicația este implementată ținând cont de toate specificul infrastructurii. Mai simplu spus, scripturile (regulile) pentru asamblarea imaginilor ar trebui să fie în același depozit cu codul sursă și îmbinate împreună.
În cazul unei arhitecturi de aplicații cu mai multe straturi - de exemplu, există nginx, care stă în fața unei aplicații care rulează deja într-un container Docker - imaginile Docker trebuie create din codul din Git pentru fiecare strat. Apoi prima imagine va conține o aplicație cu un interpret și alte dependențe „apropiate”, iar a doua imagine va conține nginx-ul din amonte.
Imagini Docker, comunicare cu Git
Împărțim toate imaginile Docker colectate din Git în două categorii: temporare și de lansare. Imagini temporare etichetate după numele ramurii în Git, pot fi suprascrise de următorul commit și sunt lansate numai pentru previzualizare (nu pentru producție). Aceasta este diferența lor cheie față de cele de lansare: nu știi niciodată ce anume commit este în ele.
Este logic să colectați în imagini temporare: ramura principală (o puteți rula automat pe un site separat pentru a vedea în mod constant versiunea curentă a masterului), ramuri cu lansări, ramuri ale inovațiilor specifice.
După ce previzualizarea imaginilor temporare vine la necesitatea traducerii în producție, dezvoltatorii pun o anumită etichetă. Colectat automat prin etichetă eliberare imagine (eticheta sa corespunde etichetei de la Git) și este lansată în staging. Dacă este verificat cu succes de către departamentul de calitate, se trece la producție.
Dapp
Tot ceea ce este descris (dezvoltare, asamblare de imagini, întreținere ulterioară) poate fi implementat independent folosind scripturi Bash și alte instrumente „improvizate”. Dar dacă faceți acest lucru, atunci, la un moment dat, implementarea va duce la o mare complexitate și o controlabilitate slabă. Înțelegând acest lucru, am ajuns să creăm propriul nostru utilitar de flux de lucru specializat pentru construirea CI/CD - Dapp.
Codul său sursă este scris în Ruby, open source și publicat pe . Din păcate, documentarea este în prezent cel mai slab punct al instrumentului, dar lucrăm la el. Și vom scrie și vom vorbi despre dapp de mai multe ori, pentru că... Sincer, abia așteptăm să împărtășim capacitățile sale cu întreaga comunitate interesată, dar, între timp, trimiteți problemele dvs. și extrageți solicitările și/sau urmăriți dezvoltarea proiectului pe GitHub.
Actualizat 13 august 2019: în prezent un proiect Dapp redenumit în , codul său a fost complet rescris în Go, iar documentația sa a fost îmbunătățită semnificativ.
Kubernetes
Un alt instrument Open Source gata făcut, care a primit deja o recunoaștere semnificativă în mediul profesional este Kubernetes,un cluster de management Docker. Subiectul utilizării sale în operarea proiectelor construite pe Docker depășește sfera raportului, astfel încât prezentarea se limitează la o prezentare generală a unor caracteristici interesante.
Pentru lansare, Kubernetes oferă:
- sonda de pregătire — verificarea gradului de pregătire a unei noi versiuni a aplicației (pentru a comuta traficul către aceasta);
- Rolling update - actualizare secvențială a imaginii într-un grup de containere (închidere, actualizare, pregătire pentru lansare, comutare de trafic);
- actualizare sincronă - actualizarea unei imagini într-un cluster cu o abordare diferită: mai întâi pe jumătate din containere, apoi pe restul;
- lansări canare - lansarea unei noi imagini pe un număr limitat (mic) de containere pentru a monitoriza anomaliile.
Întrucât Continuous Delivery nu este doar lansarea unei noi versiuni, Kubernetes are o serie de capabilități pentru întreținerea ulterioară a infrastructurii: monitorizare și logare încorporate pentru toate containerele, scalare automată etc. Toate acestea funcționează deja și așteaptă doar un proces adecvat. implementare în procesele dumneavoastră.
Recomandări finale
- Folosiți Docker.
- Creați imagini Docker ale aplicațiilor pentru toate nevoile dvs.
- Urmați principiul „Infrastructura este cod”.
- Conectați Git la Docker.
- Reglați ordinea de lansare.
- Utilizați o platformă gata făcută (Kubernetes sau alta).
Videoclipuri și diapozitive
Videoclip de la spectacol (aproximativ o oră) (raportul în sine începe din minutul 5 - urmați linkul pentru a juca din acest moment).
Prezentarea raportului:
PS
Alte rapoarte pe acest subiect pe blogul nostru:
- «» (Dmitri Stolyarov; 27 mai 2019 la DevOpsConf);
- «» (Dmitri Stolyarov; 8 noiembrie 2018 pe HighLoad++);
- «» (Dmitri Stolyarov; 7 noiembrie 2017 pe HighLoad++);
- «» (Dmitri Stolyarov; 6 iunie 2017 la RootConf).
Sursa: www.habr.com