Naš blog ćemo započeti s publikacijama temeljenim na najnovijim govorima našeg tehničkog direktora (Dmitrij Stoljarov). Svi su se održali tijekom 2016. na raznim stručnim događanjima i bili su posvećeni temi DevOps i Docker. Jedan video sa sastanka Docker Moscow u uredu Badooa već imamo Na liniji. Nove će biti popraćene člancima koji će prenijeti bit izvješća. Tako…
31. svibnja na konferenciji , održanom u sklopu festivala “Ruske internetske tehnologije” (RIT++ 2016), odjeljak “Kontinuirana implementacija i implementacija” otvorio je izvješće “Najbolje prakse kontinuirane isporuke s Dockerom”. Sažeo je i sistematizirao najbolje prakse za izgradnju procesa kontinuirane isporuke (CD) koristeći Docker i druge proizvode otvorenog koda. S tim rješenjima radimo u proizvodnji, što nam omogućuje da se oslonimo na praktično iskustvo.
Ako imate priliku provesti sat vremena , preporučujemo da ga pogledate u cijelosti. Inače, ispod je glavni sažetak u tekstualnom obliku.
Kontinuirana isporuka s Dockerom
ispod Kontinuirano isporuke razumijemo lanac događaja uslijed kojih aplikacijski kod iz Git repozitorija prvo dolazi u produkciju, a zatim završava u arhivi. Ona izgleda ovako: Git → Build → Test → Release → Operate.
Većina izvješća posvećena je fazi izgradnje (sastavljanje aplikacije), a teme o izdavanju i radu ukratko su dotaknute. Govorit ćemo o problemima i uzorcima koji vam omogućuju njihovo rješavanje, a konkretne implementacije tih obrazaca mogu biti različite.
Zašto je Docker uopće potreban ovdje? Nismo uzalud odlučili razgovarati o praksama kontinuirane isporuke u kontekstu ovog alata otvorenog koda. Iako je cijelo izvješće posvećeno njegovoj upotrebi, mnogi razlozi se otkrivaju kada se razmatra glavni obrazac uvođenja aplikacijskog koda.
Glavni uzorak izvođenja
Dakle, kada izbacimo nove verzije aplikacije, sigurno se susrećemo s problem zastoja, generiran tijekom prebacivanja proizvodnog poslužitelja. Promet sa stare verzije aplikacije na novu ne može se trenutno prebaciti: prvo se moramo uvjeriti da je nova verzija ne samo uspješno preuzeta, već i da je “zagrijana” (tj. potpuno spremna za posluživanje zahtjeva).
Tako će neko vrijeme obje verzije aplikacije (stara i nova) raditi istovremeno. Što automatski dovodi do sukob zajedničkih resursa: mreža, datotečni sustav, IPC itd. S Dockerom se ovaj problem lako rješava pokretanjem različitih verzija aplikacije u odvojenim spremnicima, za koje je zajamčena izolacija resursa unutar istog hosta (poslužitelja/virtualnog stroja). Naravno, možete proći s nekim trikovima i bez izolacije, ali ako postoji gotov i prikladan alat, onda postoji suprotan razlog - ne zanemariti ga.
Kontejnerizacija pruža mnoge druge prednosti kada se postavi. Svaka primjena ovisi o specifična verzija (ili raspon verzija) tumač, dostupnost modula/proširenja itd., kao i njihove verzije. I to se ne odnosi samo na neposredno izvršno okruženje, već i na cijelo okruženje, uključujući sistemski softver i njegovu verziju (do korištene distribucije Linuxa). Zbog činjenice da spremnici sadrže ne samo aplikacijski kod, već i unaprijed instaliran sustav i aplikacijski softver potrebnih verzija, možete zaboraviti na probleme s ovisnostima.
Sažmimo glavni uzorak izvlačenja nove verzije uzimajući u obzir sljedeće čimbenike:
- U početku se stara verzija aplikacije pokreće u prvom spremniku.
- Nova verzija se zatim izbacuje i "zagrijava" u drugom spremniku. Važno je napomenuti da sama ova nova verzija može sadržavati ne samo ažurirani aplikacijski kod, već i sve njegove ovisnosti, kao i komponente sustava (na primjer, novu verziju OpenSSL-a ili cijelu distribuciju).
- Kada je nova verzija potpuno spremna za posluživanje zahtjeva, promet se prebacuje s prvog spremnika na drugi.
- Stara verzija sada se može zaustaviti.
Ovaj pristup postavljanja različitih verzija aplikacije u zasebne spremnike pruža još jednu pogodnost - brzo vraćanje na staru verziju (uostalom, dovoljno je prebaciti promet na željeni spremnik).
Posljednja prva preporuka zvuči kao nešto čemu čak ni kapetan nije mogao naći zamjerku: "[prilikom organiziranja kontinuirane isporuke s Dockerom] Koristite Docker [i razumjeti što daje]" Zapamtite, ovo nije srebrni metak koji će riješiti svaki problem, već alat koji pruža prekrasan temelj.
Ponovljivost
Pod "ponovljivošću" mislimo na generalizirani skup problema koji se javljaju tijekom rada s aplikacijama. Govorimo o takvim slučajevima:
- Scenariji koje je odjel kvalitete provjerio za uprizorenje moraju se točno reproducirati u produkciji.
- Aplikacije se objavljuju na poslužiteljima koji mogu primati pakete iz različitih repozitorija mirrora (tijekom vremena ažuriraju se, a s njima i verzije instaliranih aplikacija).
- “Lokalno mi sve funkcionira!” (...i programerima nije dopušteno u proizvodnju.)
- Morate nešto provjeriti u staroj (arhiviranoj) verziji.
- ...
Njihova opća bit svodi se na činjenicu da je neophodna puna usklađenost korištenih okruženja (kao i odsutnost ljudskog faktora). Kako možemo jamčiti ponovljivost? Napravite Docker slike na temelju koda iz Gita, a zatim ih koristiti za bilo koji zadatak: na testnim mjestima, u proizvodnji, na lokalnim strojevima programera... Pritom je važno minimizirati radnje koje se izvode nakon sastavljanje slike: što je jednostavnije, manja je vjerojatnost pogrešaka.
Infrastruktura je šifra
Ako infrastrukturni zahtjevi (dostupnost poslužiteljskog softvera, njegova verzija, itd.) nisu formalizirani i "programirani", tada uvođenje bilo kojeg ažuriranja aplikacije može rezultirati katastrofalnim posljedicama. Na primjer, u inscenaciji ste već prešli na PHP 7.0 i u skladu s tim ponovno napisali kod - onda će njegovo pojavljivanje u produkciji s nekim starim PHP-om (5.5) sigurno nekoga iznenaditi. Ne možete zaboraviti veliku promjenu u verziji tumača, ali "vrag je u detaljima": iznenađenje može biti u manjem ažuriranju bilo koje ovisnosti.
Pristup rješavanju ovog problema poznat je kao IaC (Infrastructure as Code, "infrastruktura kao kod") i uključuje pohranu infrastrukturnih zahtjeva zajedno s kodom aplikacije. Koristeći ga, programeri i DevOps stručnjaci mogu raditi s istim repozitorijem Git aplikacije, ali na različitim njegovim dijelovima. Iz tog se koda u Gitu stvara Docker slika u kojoj se implementira aplikacija uzimajući u obzir sve specifičnosti infrastrukture. Jednostavno rečeno, skripte (pravila) za sklapanje slika trebaju biti u istom repozitoriju s izvornim kodom i spojene zajedno.
U slučaju višeslojne arhitekture aplikacije - na primjer, postoji nginx, koji stoji ispred aplikacije koja se već izvodi unutar Docker spremnika - Docker slike moraju se stvoriti iz koda u Gitu za svaki sloj. Tada će prva slika sadržavati aplikaciju s tumačem i drugim "bliskim" ovisnostima, a druga slika će sadržavati uzvodni nginx.
Docker slike, komunikacija s Gitom
Sve Docker slike prikupljene iz Gita dijelimo u dvije kategorije: privremene i izdanje. Privremene slike označeni imenom grane u Gitu, mogu se prebrisati sljedećim predanjem i uvode se samo za pregled (ne za proizvodnju). Ovo je njihova ključna razlika u odnosu na izdanje: nikad ne znate koji je konkretan commit u njima.
Ima smisla sakupiti u privremene slike: glavnu granu (možete je automatski prebaciti na zasebno mjesto da biste stalno vidjeli trenutnu verziju mastera), grane s izdanjima, grane specifičnih inovacija.
Nakon pregleda privremenih slika dođe do potrebe za prijevodom u proizvodnju, programeri stavljaju određenu oznaku. Automatski prikupljeno po oznaci objavi sliku (njegova oznaka odgovara oznaci iz Git-a) i uvodi se u staging. Ako je uspješno ovjeren od strane odjela za kvalitetu, ide u proizvodnju.
dapp
Sve opisano (rollout, montaža slike, naknadno održavanje) može se implementirati samostalno koristeći Bash skripte i druge "improvizirane" alate. Ali ako to učinite, onda će u nekom trenutku implementacija dovesti do velike složenosti i slabe upravljivosti. Shvaćajući ovo, došli smo do stvaranja vlastitog specijaliziranog uslužnog programa Workflow za izgradnju CI/CD-a - dapp.
Njegov izvorni kod napisan je u Rubyju, otvorenog koda i objavljen na . Nažalost, dokumentacija je trenutno najslabija točka alata, ali radimo na tome. A o dappu ćemo pisati i govoriti više puta, jer... Iskreno jedva čekamo podijeliti njegove mogućnosti s cijelom zainteresiranom zajednicom, ali u međuvremenu šaljite svoje probleme i zahtjeve za povlačenjem i/ili pratite razvoj projekta na GitHubu.
Ažurirano 13. kolovoza 2019.: trenutno projekt dapp preimenovan u , njegov je kod potpuno prepisan u Go, a dokumentacija mu je znatno poboljšana.
Kubernetes
Još jedan gotovi Open Source alat koji je već dobio značajno priznanje u profesionalnom okruženju je Kubernetes, klaster za upravljanje Dockerom. Tema njegove upotrebe u radu projekata izgrađenih na Dockeru je izvan okvira izvješća, stoga je prezentacija ograničena na pregled nekih zanimljivih značajki.
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 spremnika (gašenje, ažuriranje, priprema za pokretanje, prebacivanje prometa);
- sinkrono ažuriranje - ažuriranje slike u klasteru različitim pristupom: prvo na polovici spremnika, zatim na ostatku;
- canary releases - pokretanje nove slike na ograničenom (malom) broju spremnika za praćenje anomalija.
Budući da Continuous Delivery nije samo izdanje nove verzije, Kubernetes ima niz mogućnosti za naknadno održavanje infrastrukture: ugrađeno praćenje i bilježenje za sve spremnike, automatsko skaliranje itd. Sve to već radi i samo čeka ispravno implementaciju u vaše procese.
Završne preporuke
- Koristite Docker.
- Stvorite Docker slike aplikacija za sve svoje potrebe.
- Slijedite načelo "Infrastruktura je kod."
- Povežite Git s Dockerom.
- Regulirajte redoslijed izvođenja.
- Koristite gotovu platformu (Kubernetes ili neku drugu).
Video zapisi i slajdovi
Video s nastupa (oko sat vremena) (samo izvješće počinje od 5. minute - slijedite link za igranje od ovog trenutka).
Prezentacija izvješća:
PS
Ostali izvještaji o ovoj temi na našem blogu:
- «» (Dmitry Stolyarov; 27. svibnja 2019. na DevOpsConf);
- «» (Dmitry Stolyarov; 8. studenog 2018. na HighLoad++);
- «» (Dmitry Stolyarov; 7. studenog 2017. na HighLoad++);
- «» (Dmitry Stolyarov; 6. lipnja 2017. na RootConfu).
Izvor: www.habr.com