Prakse kontinuirane isporuke s Dockerom (recenzija i video)

Naš blog ćemo započeti s publikacijama zasnovanim na najnovijim govorima našeg tehničkog direktora distol (Dmitrij Stoljarov). Svi su se odvijali 2016. godine na raznim stručnim događajima i bili su posvećeni temi DevOps i Docker. Već imamo jedan video sa sastanka Docker Moskva u kancelariji Badooa objavljeno Online. Novi će biti praćeni člancima koji će prenositi suštinu izvještaja. Dakle…

31. maja na konferenciji RootConf 2016, održanom u okviru festivala „Ruske internet tehnologije“ (RIT++ 2016), sekcija „Kontinuirana implementacija i implementacija“ otvorena je izvještajem „Najbolje prakse kontinuirane isporuke sa Dockerom“. Sažeo je i sistematizirao najbolje prakse za izgradnju procesa kontinuirane isporuke (CD) koristeći Docker i druge proizvode otvorenog koda. Sa ovim rješenjima radimo u proizvodnji, što nam omogućava da se oslonimo na praktično iskustvo.

Ako imate priliku da provedete sat vremena video izvještaja, preporučujemo da ga pogledate u cijelosti. Inače, ispod je glavni sažetak u tekstualnom obliku.

Kontinuirana isporuka uz Docker

By Kontinuirana dostava razumemo lanac događaja usled kojih kod aplikacije iz Git repozitorija prvo dolazi u proizvodnju, a zatim završava u arhivi. izgleda ovako: Git → Napravi → Testiraj → Izdaj → Pokreni.

Većina izvještaja je posvećena fazi izgradnje (sastavljanje aplikacije), a ukratko se dotiču teme izdavanja i rada. Govorit ćemo o problemima i obrascima koji vam omogućavaju da ih riješite, a specifične implementacije ovih obrazaca mogu biti različite.

Zašto je Docker uopće potreban ovdje? Nije uzalud odlučili da razgovaramo o praksama kontinuirane isporuke u kontekstu ovog alata otvorenog koda. Iako je cijeli izvještaj posvećen njegovoj upotrebi, mnogi razlozi se otkrivaju kada se razmatra glavni obrazac uvođenja koda aplikacije.

Glavni obrazac uvođenja

Dakle, kada puštamo nove verzije aplikacije, svakako se suočavamo sa problem zastoja, generiran tijekom prebacivanja proizvodnog servera. Promet sa stare verzije aplikacije na novu ne može se odmah prebaciti: prvo moramo biti sigurni da je nova verzija ne samo uspješno preuzeta, već i „zagrijana“ (tj. potpuno spremna za ispunjavanje zahtjeva).

Tako će neko vrijeme obje verzije aplikacije (stara i nova) raditi istovremeno. Što automatski dovodi do sukob zajedničkih resursa: mreža, sistem datoteka, IPC, itd. Uz Docker, ovaj problem se lako rješava pokretanjem različitih verzija aplikacije u odvojenim kontejnerima, za koje je zagarantovana izolacija resursa unutar istog hosta (server/virtuelna mašina). Naravno, možete se snaći s nekim trikovima bez izolacije, ali ako postoji gotov i zgodan alat, onda postoji suprotan razlog - ne zanemariti ga.

Kontejnerizacija pruža mnoge druge prednosti kada se implementira. Svaka aplikacija zavisi od specifična verzija (ili raspon verzija) tumač, dostupnost modula/proširenja itd., kao i njihove verzije. I to se odnosi ne samo na neposredno izvršno okruženje, već i na cjelokupno okruženje, uključujući sistemski softver i njegovu verziju (do korištene Linux distribucije). Zbog činjenice da kontejneri sadrže ne samo kod aplikacije, već i unaprijed instalirani sistemski i aplikativni softver potrebnih verzija, možete zaboraviti na probleme s ovisnostima.

Hajde da sumiramo glavni obrazac uvođenja nove verzije uzimajući u obzir sljedeće faktore:

1. U početku, stara verzija aplikacije radi u prvom kontejneru.
2. Nova verzija se zatim razvaljuje i „zagreva“ u drugom kontejneru. Važno je napomenuti da sama ova nova verzija može nositi ne samo ažurirani kod aplikacije, već i bilo koju od njenih zavisnosti, kao i sistemske komponente (na primjer, novu verziju OpenSSL-a ili cijelu distribuciju).
3. Kada je nova verzija potpuno spremna za servisiranje zahtjeva, promet se prebacuje iz prvog kontejnera u drugi.
4. Stara verzija se sada može zaustaviti.

Ovaj pristup implementacije različitih verzija aplikacije u odvojenim kontejnerima pruža još jednu pogodnost - brzi povratak na staru verziju (na kraju krajeva, dovoljno je prebaciti promet na željeni kontejner).

Poslednja prva preporuka zvuči kao nešto čemu čak ni kapetan nije mogao da zameri: „[prilikom organizacije kontinuirane isporuke s Dockerom] Koristite Docker [i razumjeti šta daje]" Zapamtite, ovo nije srebrni metak koji će riješiti svaki problem, već alat koji pruža divnu osnovu.

Reproducibilnost

Pod „ponovljivošću“ podrazumevamo generalizovani skup problema sa kojima se susreću prilikom rada aplikacija. Govorimo o ovakvim slučajevima:

• Skripte koje je proveravao odeljenje za kvalitet za inscenaciju moraju biti precizno reprodukovane u proizvodnji.
• Aplikacije se objavljuju na serverima koji mogu primati pakete iz različitih ogledala spremišta (s vremenom se ažuriraju, a sa njima i verzije instaliranih aplikacija).
• “Lokalno mi sve radi!” (...i programerima nije dozvoljeno da uđu u proizvodnju.)
• Morate provjeriti nešto u staroj (arhiviranoj) verziji.
• ...

Njihova opšta suština se svodi na činjenicu da je neophodna puna usklađenost okruženja koje se koristi (kao i odsustvo ljudskog faktora). Kako možemo garantovati ponovljivost? Napravite Docker slike bazirane na kodu iz Git-a, a zatim ih koristiti za bilo koji zadatak: na test lokacijama, u proizvodnji, na lokalnim mašinama programera... Istovremeno je važno minimizirati radnje koje se izvode после sastavljanje slike: što je jednostavnije, manja je vjerovatnoća da će biti grešaka.

Infrastruktura je kod

Ako infrastrukturni zahtjevi (dostupnost serverskog softvera, njegova verzija, itd.) nisu formalizirani i „programirani“, tada uvođenje bilo kojeg ažuriranja aplikacije može rezultirati katastrofalnim posljedicama. Na primjer, u stagingu ste već prešli na PHP 7.0 i u skladu s tim prepisali kod - onda će njegovo pojavljivanje u produkciji sa nekim starim PHP-om (5.5) sigurno nekoga iznenaditi. Možda nećete zaboraviti na veliku promjenu u verziji tumača, ali "đavo je u detaljima": iznenađenje može biti u manjem ažuriranju bilo koje ovisnosti.

Pristup rješavanju ovog problema je poznat kao IaC (Infrastruktura kao kod, "infrastruktura kao kod") i uključuje pohranjivanje infrastrukturnih zahtjeva zajedno sa kodom aplikacije. Koristeći ga, programeri i stručnjaci za DevOps mogu raditi sa istim repozitorijumom Git aplikacije, ali na različitim njegovim dijelovima. Iz ovog koda se kreira Docker slika u Gitu, u kojoj se aplikacija postavlja uzimajući u obzir sve specifičnosti infrastrukture. Jednostavno rečeno, skripte (pravila) za sklapanje slika treba da budu u istom spremištu sa izvornim kodom i spojene zajedno.

U slučaju arhitekture višeslojne aplikacije – na primjer, postoji nginx, koji stoji ispred aplikacije koja već radi unutar Docker kontejnera – Docker slike moraju biti kreirane iz koda u Gitu za svaki sloj. Tada će prva slika sadržavati aplikaciju s interpretatorom i drugim “bliskim” ovisnostima, a druga slika će sadržavati uzvodni nginx.

Docker slike, komunikacija sa Gitom

Sve Docker slike prikupljene iz Gita dijelimo u dvije kategorije: privremene i puštene. Privremene slike označene imenom grane u Gitu, mogu biti prepisane sljedećim urezivanjem i uvedene su samo za pregled (ne za proizvodnju). Ovo je njihova ključna razlika od onih u izdanju: nikad ne znate koji je konkretan urezivanje u njima.

Ima smisla skupljati u privremene slike: glavnu granu (možete je automatski izbaciti na zasebnu stranicu da biste stalno vidjeli trenutnu verziju master), grane sa izdanjima, grane specifičnih inovacija.

Nakon što pregled privremenih slika dođe do potrebe za prevodom u produkciju, programeri stavljaju određenu oznaku. Automatski se prikuplja po oznakama objavi sliku (njegov tag odgovara oznaci iz Git-a) i uveden je u fazu. Ako je uspješno potvrđen od strane odjela za kvalitet, ide u proizvodnju.

dapp

Sve što je opisano (rollout, montaža slike, naknadno održavanje) može se implementirati nezavisno koristeći Bash skripte i druge „improvizovane“ alate. Ali ako to učinite, tada će implementacija u nekom trenutku dovesti do velike složenosti i loše kontrole. Shvativši ovo, došli smo do kreiranja vlastitog specijaliziranog programa Workflow za izgradnju CI/CD-a - dapp.

Njegov izvorni kod je napisan u Ruby-u, open source i objavljen GitHub. Nažalost, dokumentacija je trenutno najslabija tačka alata, ali radimo na tome. A o dappu ćemo pisati i pričati više puta, jer... Iskreno jedva čekamo da podijelimo njegove mogućnosti sa cijelom zainteresiranom zajednicom, ali u međuvremenu pošaljite svoje probleme i zahtjeve za povlačenjem i/ili pratite razvoj projekta na GitHub-u.

Ažurirano 13. avgusta 2019.: trenutno projekat dapp preimenovan u werf, njegov kod je potpuno prepisan u Go, a njegova dokumentacija je značajno poboljšana.

Kubernet

Još jedan gotov alat otvorenog koda koji je već dobio značajno priznanje u profesionalnom okruženju je Kubernet, Docker upravljački klaster. Tema njegove upotrebe u radu projekata izgrađenih na Dockeru je izvan okvira izvještaja, pa je prezentacija ograničena na pregled nekih zanimljivih karakteristika.

Za uvođenje, Kubernetes nudi:

• sonda spremnosti — provjera spremnosti nove verzije aplikacije (za prebacivanje prometa na nju);
• rolling update - sekvencijalno ažuriranje slike u klasteru kontejnera (gašenje, ažuriranje, priprema za pokretanje, prebacivanje prometa);
• sinkrono ažuriranje - ažuriranje slike u klasteru s drugačijim pristupom: prvo na polovini kontejnera, zatim na ostatku;
• canary releases - lansiranje nove slike na ograničenom (malom) broju kontejnera za praćenje anomalija.

Budući da Kontinuirana isporuka nije samo izdavanje nove verzije, Kubernetes ima niz mogućnosti za naknadno održavanje infrastrukture: ugrađeno praćenje i evidentiranje za sve kontejnere, automatsko skaliranje itd. Sve ovo već radi i samo čeka da se ispravno implementaciju u vaše procese.

Konačne preporuke

1. Koristite Docker.
2. Kreirajte Docker slike aplikacija za sve vaše potrebe.
3. Slijedite princip „Infrastruktura je kod“.
4. Povežite Git sa Dockerom.
5. Regulirajte redoslijed uvođenja.
6. Koristite gotovu platformu (Kubernetes ili neku drugu).

Video zapisi i slajdovi

Video sa nastupa (oko sat vremena) objavljeno na YouTube-u (sami izvještaj počinje od 5. minute - pratite link za igranje od ovog trenutka).

Prezentacija izvještaja:

PS

Ostali izvještaji na ovu temu na našem blogu:

• «werf - naš alat za CI/CD u Kubernetesu (pregled i video izvještaj)» (Dmitrij Stoljarov; 27. maja 2019. na DevOpsConf-u);
• «Baze podataka i Kubernetes» (Dmitrij Stoljarov; 8. novembar 2018. na HighLoad++);
• «CI/CD najbolje prakse sa Kubernetesom i GitLabom» (Dmitrij Stoljarov; 7. novembar 2017. na HighLoad++);
• «Naše iskustvo sa Kubernetesom u malim projektima» (Dmitrij Stoljarov; 6. juna 2017. na RootConf-u).

izvor: www.habr.com