Alustame oma ajaveebi väljaannetega, mis põhinevad meie tehnikadirektori viimastel sõnavõttudel (Dmitri Stoljarov). Kõik need toimusid 2016. aastal erinevatel erialastel üritustel ning olid pühendatud DevOpsi ja Dockeri teemale. Üks video Docker Moskva kohtumisest Badoo kontoris on meil juba olemas Internetis. Uutele lisanduvad artiklid, mis annavad edasi aruannete olemust. Nii…
31. mail konverentsil , mis toimus festivali “Russian Internet Technologies” (RIT++ 2016) raames, avanes rubriik “Pidev juurutamine ja juurutamine” raportiga “Dokkeriga pideva tarnimise parimad tavad”. See võttis kokku ja süstematiseeris parimad tavad pideva tarnimise (CD) protsessi loomiseks, kasutades Dockerit ja muid avatud lähtekoodiga tooteid. Nende lahendustega töötame ka tootmises, mis võimaldab meil toetuda praktilistele kogemustele.
Kui teil on võimalus tund aega veeta , soovitame seda täismahus vaadata. Vastasel juhul on allpool peamine kokkuvõte teksti kujul.
Pidev kohaletoimetamine Dockeriga
Alla Pidev kohaletoimetamine me mõistame sündmuste ahelat, mille tulemusena Giti hoidlast pärit rakenduse kood kõigepealt tootmisse jõuab ja seejärel arhiivi. Ta näeb välja selline: Git → Ehitamine → Testi → Vabasta → Käita.
Suurem osa aruandest on pühendatud koostamisetapile (rakenduse kokkupanek) ning lühidalt puudutatakse väljalaske- ja tööteemaid. Räägime probleemidest ja mustritest, mis võimaldavad teil neid lahendada ning nende mustrite konkreetsed teostused võivad olla erinevad.
Milleks siia Dockerit üldse vaja on? Pole asjata, et me otsustasime selle avatud lähtekoodiga tööriista kontekstis rääkida pideva edastamise tavadest. Kuigi kogu aruanne on pühendatud selle kasutamisele, ilmneb rakenduse koodi levitamise peamist mustrit arvestades palju põhjuseid.
Peamine levitamise muster
Seega seisame rakenduse uute versioonide väljastamisel kindlasti silmitsi seisakute probleem, mis genereeritakse tootmisserveri vahetamisel. Liiklus rakenduse vanalt versioonilt uuele ei saa koheselt ümber lülituda: esmalt peame veenduma, et uus versioon pole mitte ainult edukalt alla laaditud, vaid ka "soojendatud" (st täielikult valmis päringuid teenindama).
Seega töötavad mõnda aega mõlemad rakenduse versioonid (vana ja uus) samaaegselt. Mis viib automaatselt jagatud ressursside konflikt: võrk, failisüsteem, IPC jne. Dockeriga saab selle probleemi hõlpsalt lahendada, käivitades rakenduse erinevad versioonid eraldi konteinerites, mille jaoks on tagatud ressursside eraldamine samas hostis (serveris/virtuaalmasin). Muidugi saab mõne nipiga hakkama ka ilma isolatsioonita, aga kui on olemas valmis ja mugav tööriist, siis on põhjus vastupidine - seda mitte unarusse jätta.
Konteinerimine pakub kasutuselevõtul palju muid eeliseid. Iga rakendus sõltub konkreetne versioon (või versioonivahemik) tõlk, moodulite/laienduste jms saadavus, aga ka nende versioonid. Ja see ei kehti ainult vahetu käivitatava keskkonna kohta, vaid ka kogu keskkonna kohta, sealhulgas süsteemitarkvara ja selle versioon (kuni kasutatud Linuxi distributsioonini). Kuna konteinerid ei sisalda mitte ainult rakenduse koodi, vaid ka vajalike versioonide eelinstallitud süsteemi ja rakendustarkvara, võite unustada sõltuvustega seotud probleemid.
Teeme üldistuse peamine levitamise muster uued versioonid, võttes arvesse järgmisi tegureid:
- Alguses töötab rakenduse vana versioon esimeses konteineris.
- Seejärel rullitakse uus versioon välja ja soojendatakse üles teises konteineris. Tähelepanuväärne on see, et see uus versioon ise võib sisaldada mitte ainult värskendatud rakenduse koodi, vaid ka mis tahes selle sõltuvusi, aga ka süsteemikomponente (näiteks OpenSSL-i uus versioon või kogu distributsioon).
- Kui uus versioon on päringute esitamiseks täielikult valmis, lülitub liiklus esimesest konteinerist teise.
- Vana versiooni saab nüüd peatada.
Rakenduse erinevate versioonide eraldi konteinerites juurutamise lähenemisviis pakub veel ühe mugavuse – kiire tagasipööramine vanale versioonile (lõppude lõpuks piisab liikluse suunamisest soovitud konteinerisse).
Viimane esimene soovitus kõlab nagu midagi, milles isegi kapten ei suutnud midagi ette heita: "[Dockeriga pideva kohaletoimetamise korraldamisel] Kasutage Dockerit [ja mõista, mida see annab]" Pidage meeles, et see ei ole hõbekuul, mis lahendab kõik probleemid, vaid tööriist, mis annab suurepärase aluse.
Reprodutseeritavus
"Reprodutseeritavuse" all peame silmas üldist probleemide kogumit, mis ilmnevad rakenduste kasutamisel. Me räägime sellistest juhtumitest:
- Kvaliteediosakonna poolt lavastamise jaoks kontrollitud skriptid peavad olema tootmises täpselt reprodutseeritud.
- Rakendused avaldatakse serverites, mis suudavad vastu võtta pakette erinevatest hoidlate peeglitest (aja jooksul uuendatakse neid ja koos nendega installitud rakenduste versioone).
- „Minu jaoks toimib kohapeal kõik!” (...ja arendajaid ei lubata tootmisse.)
- Peate midagi vanas (arhiivitud) versioonis üle kontrollima.
- ...
Nende üldine olemus taandub asjaolule, et kasutatavate keskkondade täielik vastavus (ja ka inimfaktori puudumine) on vajalik. Kuidas saame tagada reprodutseeritavuse? Tee Dockeri pilte Giti koodi põhjal ja seejärel kasutada neid mis tahes toimingu jaoks: testimisplatsidel, tootmises, programmeerijate kohalikel masinatel... Samal ajal on oluline tehtavaid toiminguid minimeerida pärast pildi kokkupanemine: mida lihtsam see on, seda väiksem on vigade tõenäosus.
Infrastruktuur on kood
Kui infrastruktuuri nõuded (serveritarkvara kättesaadavus, selle versioon jne) ei ole ametlikult vormistatud ja "programmeeritud", võib rakenduse mis tahes värskenduse kasutuselevõtt põhjustada katastroofilisi tagajärgi. Näiteks lavastuses oled juba PHP 7.0 peale üle läinud ja koodi vastavalt ümber kirjutanud – siis üllatab selle tootmisse ilmumine mõne vana PHP-ga (5.5) kindlasti kedagi. Te ei pruugi unustada suurt muudatust tõlgi versioonis, kuid "kurat on üksikasjades": üllatus võib olla mis tahes sõltuvuse väike värskendus.
Selle probleemi lahendamise viis on tuntud kui IaC (infrastruktuur kui kood, "infrastruktuur kui kood") ja hõlmab infrastruktuuri nõuete salvestamist koos rakenduse koodiga. Seda kasutades saavad arendajad ja DevOpsi spetsialistid töötada sama Giti rakenduste hoidlaga, kuid selle erinevates osades. Sellest koodist luuakse Gitis Dockeri pilt, milles rakendus juurutatakse kõiki infrastruktuuri eripärasid arvestades. Lihtsamalt öeldes peaksid piltide kokkupanemise skriptid (reeglid) asuma lähtekoodiga samas hoidlas ja kokku liitma.
Mitmekihilise rakendusarhitektuuri puhul – näiteks on olemas nginx, mis seisab Dockeri konteineris juba töötava rakenduse ees – tuleb iga kihi jaoks luua Giti koodist Dockeri pildid. Siis sisaldab esimene pilt rakendust koos tõlgi ja muude "lähedaste" sõltuvustega ning teine pilt sisaldab ülesvoolu nginxi.
Dockeri pildid, suhtlus Gitiga
Jagame kõik Gitist kogutud Dockeri pildid kahte kategooriasse: ajutised ja vabastatavad. Ajutised pildid Gitis oleva filiaali nimega märgistatud, saab järgmise sissekandmisega üle kirjutada ja need avaldatakse ainult eelvaate jaoks (mitte tootmiseks). See on nende peamine erinevus väljalaskest: kunagi ei tea, milline konkreetne kohustus neis on.
Mõttekas on koguda ajutisteks kujutisteks: põhiharu (saate selle automaatselt eraldi saidile välja veeretada, et näha pidevalt praegust põhiversiooni), väljalasetega harud, konkreetsete uuenduste harud.
Pärast ajutiste piltide eelvaate ilmnemist tootmisse tõlkimise vajaduseni panevad arendajad teatud sildi. Kogutakse automaatselt sildi järgi vabasta pilt (selle märgend vastab Giti sildile) ja see levitatakse lavastusse. Kui kvaliteediosakond seda edukalt kontrollib, läheb see tootmisse.
dapp
Kõike kirjeldatud (juurutamine, pildi kokkupanek, hilisem hooldus) saab Bashi skriptide ja muude "improviseeritud" tööriistade abil iseseisvalt rakendada. Kuid kui te seda teete, põhjustab rakendamine ühel hetkel suurt keerukust ja halva juhitavuse. Sellest aru saades asusime looma oma spetsiaalse töövoo utiliidi CI/CD loomiseks – dapp.
Selle lähtekood on kirjutatud Ruby keeles, avatud lähtekoodiga ja avaldatud . Kahjuks on dokumentatsioon hetkel tööriista nõrgim koht, kuid me töötame selle kallal. Ja me kirjutame ja räägime dappist rohkem kui korra, sest... Me siiralt ei jõua ära oodata, millal saame selle võimalusi kogu huvitatud kogukonnaga jagada, kuid seniks saatke oma probleemid ja päringuid ning/või jälgige projekti arengut GitHubis.
Värskendatud 13. augustil 2019: hetkel projekt dapp ümber nimetatud , on selle kood Go-s täielikult ümber kirjutatud ja selle dokumentatsiooni on oluliselt täiustatud.
Kubernetes
Teine valmis avatud lähtekoodiga tööriist, mis on professionaalses keskkonnas juba märkimisväärset tunnustust pälvinud, on Kubernetes, Dockeri haldusklaster. Selle kasutamise teema Dockeril üles ehitatud projektide töös väljub aruande ulatusest, seega piirdub esitlus mõne huvitava funktsiooni ülevaatega.
Kubernetes pakub levitamiseks järgmist:
- valmidussond — rakenduse uue versiooni valmisoleku kontrollimine (liikluse ümberlülitamiseks sellele);
- jooksev värskendus - järjestikune pildiuuendus konteinerite klastris (seiskamine, värskendamine, käivitamiseks ettevalmistamine, liikluse ümberlülitamine);
- sünkroonne värskendus - pildi värskendamine klastris erineva lähenemisega: kõigepealt pooltel konteineritel, seejärel ülejäänud;
- canary releases - uue pildi käivitamine piiratud (väikese) arvu konteinerite puhul, et jälgida kõrvalekaldeid.
Kuna Continuous Delivery ei ole ainult uue versiooni väljalase, on Kubernetesil mitmeid võimalusi taristu hilisemaks hoolduseks: sisseehitatud jälgimine ja logimine kõikide konteinerite jaoks, automaatne skaleerimine jne. Kõik see juba töötab ja ootab vaid korralikku rakendamine teie protsessides.
Viimased soovitused
- Kasutage Dockerit.
- Looge rakenduste Dockeri kujutised kõigi oma vajaduste jaoks.
- Järgige põhimõtet "Taristu on kood".
- Linkige Git Dockeriga.
- Reguleerige levitamise järjekorda.
- Kasutage valmis platvormi (Kubernetes või mõni muu).
Videod ja slaidid
Video etendusest (umbes tund) (aruanne ise algab 5. minutist - sellest hetkest mängimiseks järgi linki).
Aruande esitlus:
PS
Muud selleteemalised aruanded meie ajaveebis:
- «» (Dmitry Stolyarov; 27. mai 2019, DevOpsConf);
- «» (Dmitry Stolyarov; 8. november 2018, HighLoad++);
- «» (Dmitry Stolyarov; 7. november 2017, HighLoad++);
- «» (Dmitry Stolyarov; 6. juuni 2017 RootConfis).
Allikas: www.habr.com