🥇Dockeriga Continuous Delivery praktikad (ülevaade ja video)

Käivitan oma blogi publikatsioonidega, mis on loodud meie tehnilise direktori viimaste esinemiste alusel distol (Dmitri Stoljarov). Need kõik toimusid 2016. aastal erinevates professionaalsetes üritustes ja olid pühendatud DevOpsi ja Dockeri teemale. Üks video, Docker Moscow kohtumiselt Badoo kontoris, on juba ülevaate saidil. Uued järgivad artiklitega, mis edastavad ettekanne sisu. Nii et...

31. mail konverentsil RootConf 2016, mis toimus festivali "Venemaa internetitehnoloogiad" (RIT++ 2016) raames, avati "Jätkuv juurutamine ja deploy" sektsioon ettekandega "Parimad praktikad Continuous Delivery Dockeriga". Selles koondati ja süsteematiseeriti parimad praktikad Continuous Delivery (CD) protsessi ülesehitamiseks Dockerit ja teisi avatud lähtekoodiga tooteid kasutades. Nende lahendustega töötame tootmises, mis võimaldab toetuda praktilisele kogemusele.

Kui Teil on võimalus kulutada tund ettekande video vaatamiseks, soovitame vaadata seda täielikult. Vastasel juhul — allpool on esitatud põhikokkuvõte tekstivormingus.

Continuous Delivery Dockeriga

Alustama Jätkuv kohaletoimetamine Me mõistame tegevuste jada, mille jooksul rakenduse kood Git-repositooriumist kõigepealt jõuab tootmisettevõttesse ja seejärel arhiivi. Protsess näeb välja järgmine: Git → Build (kokkupanek) → Test (testimine) → Release (vabastus) → Operate (järgnevad tegevused).

Suurem osa ettekandest käsitleb etappi build (rakenduse kokkupanek), samas kui teemad release ja operate on käsitletud ülevaatlikult. Rääkime probleemidest ja mustritest, mille abil neid lahendada, ning nende mustrite konkreetsed rakendused võivad olla erinevad.

Miks on siin üldse vajalik Docker? Me ei räägi lihtsalt nii praktilise Continuous Delivery praktikast selle avatud lähtekoodiga tööriista kontekstis. Kuigi kogu ettekande fookus on sellele tööriistale pühendatud, paljusid põhjuseid paljastavad juba rakenduse koodi vabastamise põhikomplekti vaatlemisel.

Peamine mustri väljalaskmine

Seega, kui uute rakenduste versioonide väljalaskmine toimub, seisame silmitsi seisaku probleemiga, mis tekib production-serveri vahetamise käigus. Liiklus vana rakenduse versioonilt uuele ei saa koheselt üleminekuks minna: esmalt peame veenduma, et uus versioon on mitte ainult edukalt tõmmatud, vaid ka 'soojendatud' (st täielikult valmis päringute teenindamiseks).

Seega töötavad mõlema rakenduse versioon (vana ja uus) mõnda aega üheaegselt. See toob automaatselt kaasa ühiste ressursside konflikti: võrgu, failisüsteemi, IPC jne. Dockeriga lahendatakse see probleem kergesti, käivitades rakenduse erinevaid versioone eraldi konteinerites, millele tagatakse ressursside isolatsioon ühel hostil (serveris/virtuaalmasinas). Muidugi on võimalik saavutada mõningaid lahendusi ka ilma isolatsioonita, kuid kui on olemas mugav ja valmis tööriist, siis on ka vastupidine mõte — mitte seda ignoreerida.

Konteinerimine annab palju teisi eeliseid juurutamiseks. Iga rakendus sõltub kindlast versioonist (või versioonide vahemikust) tõlgist, moodulite / laienduste jne olemasolu ja nende versioonid. See kehtib mitte ainult jooksvas keskkonnas, vaid ka kogu keskkonna kohta, sealhulgas süsteemne tarkvara ja selle versioonid (kuni kasutatava Linuxi jaotise välja). Kuna konteinerid sisaldavad mitte ainult rakenduste koodi, vaid ka eelnevalt installitud süsteemset ja rakenduslikku tarkvara vajalikes versioonides, võib sõltuvusprobleemide pärast muretsemine jääda minevikku.

Kokkuvõtteks pea musternäidis uute versioonide väljaandmise osas, arvestades eeltoodud tegureid:

Esiteks töötab vana rakenduse versioon esimeses konteineris.
Seejärel väljastatakse uus versioon ja "kütteperiood" teises konteineris. Oluline on, et see uus versioon võib sisaldada mitte ainult uuendatud rakenduse koodi, vaid ka kõiki selle sõltuvusi ning süsteemikomponente (nt uus OpenSSL versioon või kogu jaotise uus versioon).
Kui uus versioon on täielikult valmis kasutama, suunatakse liiklus esimeselt konteinerilt teisele.
Nüüd saab vana versiooni peatada.

See lähenemine, kus erinevaid rakenduse versioone juurutatakse erinevatesse konteineritesse, annab veel ühe mugavuse — kiire tagasimineku eelnevale versioonile (sest piisab liikluse suunamisest õigesse konteinerisse).

Lõplik esimene soovitus ütleb nii, et isegi Kapten ei saa midagi nuriseda: «[organiseerides Continuous Delivery Dockeriga] Kasutage Dockerit [ja mõistke, mida see annab]». Pea meeles, et see ei ole „hõbepüss”, mis lahendab kõik probleemid, vaid tööriist, mis loob suurepärase aluse.

Reproduktiivsus

All „reproduktiivsus” mõistame laia haardega probleeme, millega rakenduste haldamisel kokku puututakse. Räägime sellistest juhtudest:

Kvaliteediosakonna poolt stagingus testitud stsenaariumid peavad täpselt reproduceeruma tootmises.
Rakendused avaldatakse serveritesse, mis võivad pakkuda pakette erinevatest peegeldusallikatest (ajaga uuendatakse neid koos nendega — ja seega ka installitavate rakenduste versioone).
„Kohapeal töötas kõik!” (… ja arendajad ei pääse tootmisse.)
Vaja on kontrollida midagi vana (arhiveeritud) versiooni kohta.
…

Nende üldine olemus seisneb selles, et kõigi kasutatavates keskkondades peab olema täielik ühtsus (ning puuduma peab inimmõjutus). Kuidas tagada reproduktsiooni? Luua Docker-pilte koodist, mis on saadud Git'ist, ning kasutada neid erinevates ülesannetes: testimisplatvormidel, tootmisülesannetes, arendajate kohalikes seadmetes... Samuti on oluline minimaliseerida teostatavaid toiminguid pärast pildi koostamine: mida lihtsam, seda väiksem on tõrgete tõenäosus.

Infrastruktuur on kood

Kui infrastruktuuri nõudeid (serveritarkvara olemasolu, selle versioon jne) ei fikseeri ega ‘programmeeri’, siis iga rakenduse värskendamise tulemus võib olla kurb. Näiteks kui olete staging’ul juba üle läinud PHP 7.0 peale ja olete vastavalt sellele koodi ümber kirjutanud, siis selle ilmumine tootmisülesandele vanema PHP (5.5) juures kindlasti üllatab kedagi. Olgu, et te ei unusta suure versiooni vahetust, kuid ‘demon peitub detailides’: üllatus võib olla väiksemas värskenduses mistahes sõltuvuses.

Selle probleemi lahendusaastus on tuntud kui IaC (Infrastructure as Code, 'infrastruktuur kui kood') ja sisaldab infrastruktuuri nõuete salvestamist koos rakenduse koodiga. Selle kasutamise korral saavad arendajad ja DevOps-spetsialistid töötada ühe rakenduse Git-repositooriumiga, kuid erinevate selle osade kallal. Sellest koodist luuakse Git-is Docker-pilt, kus rakendus on käivitatud arvestades kogu infrastruktuuri eripära. Lihtsamalt öeldes peavad piltide koostamise skriptid (reeglid) asuma samas repositooriumis, kus on lähtekood, ja koos olema ühinema.

Kui rakenduse arhitektuur on kihiline — näiteks on olemas nginx, mis asub rakenduse ees, mis juba töötab Docker-konteineris — peab Docker-pilte looma koodist Git-is iga kihiga. Siis on esimeses pildis rakendus koos tõlgendajaga ja muude «lähedaste» sõltuvustega, ning teises — ülemine nginx.

Docker-pildid, ühendus Git-iga

Kõik Git-ist loodud Docker-pildid jagame kaheks kategooriaks: ajutised ja versioonipildid. Ajutised pildid needless to say, these are tagged by branch name in Git, can be overwritten by the next commit, and are released only for preview (not for production). This is their key difference from releases: you never know which specific commit they contain.

It makes sense to gather temporary images: the master branch (which can be automatically deployed to a staging area to constantly see the current version of master), release branches, and branches with specific innovations.

Once the preview of temporary images reaches the point of needing to be moved to production, developers apply a specific tag. The release image is automatically built by this tag. release image (its tag corresponds to the Git tag) and is deployed to staging. If it passes the quality assurance check, it goes to production.

dapp

Kõik kirjeldatud (rakendamine, piltide kogumine, edasine hooldus) saab iseseisvalt teostada Bash-skriptide ja teiste "kättesaadavate" vahendite abil. Kuid kui seda teha, toob see mingil hetkel kaasa suuri keerukusi ja halba hallatavust. Mõistes seda, lõime oma spetsialiseeritud töövoo utiliidi CI/CD ehitamiseks — dapp.

üksikasjalik kood on kirjutatud Ruby keeles, avatud ja avaldatud aadressil GitHub. Kahjuks on tema dokumentatsioon praegu tööriista nõrgim koht, kuid me töötame selle kallal. Me kirjutame ja räägime dappist veel mitu korda, kuna meil on tõeliselt hea meel jagada tema võimalusi kogu huvitatud kogukonnaga, ning saatke meile oma probleemid ja pull requestid ning/või jälgige projekti arengut GitHubis.

Uuendatud 13. augustil 2019: praegu on projekt dapp ümber nimetatud werf, tema kood on täielikult ümber kirjutatud Go keeles ja dokumentatsioon on märkimisväärselt paranenud.

Kubernetes

Teine valmis Open Source-tööriist, mis on juba professionaalses keskkonnas märkimisväärset tunnustust saanud, on Kubernetes, Dockeri haldusklaaster. Tema kasutamine Dockeril põhinevate projektide töötluses ületab raporti piire, seega on esitus piiratud mõnede huvitavate võimaluste ülevaatega.

Kubernetes pakub järgmisi võimalusi:

valmiduse kontroll — uue rakenduse versiooni valmisoleku kontroll (liikluse selle suunamiseks);
järkjärguline uuendus — eksemplari järkjärguline uuendamine klastris konteineritest (väljalülitamine, uuendamine, käivitamiseks ettevalmistamine, liikluse suunamine);
sünkroonne uuendus — eksemplari uuendamine klastris teise lähenemisega: esmalt poolele konteineritele, seejärel ülejäänutele;
kanari versioonid — uue eksemplari käivitamine piiratud (väikese) arvu konteinerite peal anomaaliate jälgimiseks.

Kuna pidev tarnimine ei tähenda ainult uue versiooni väljaandmist, siis on Kubernetesel mitmeid võimalusi infrastruktuuri edasiseks hoolduseks: integreeritud jälgimine ja logimine kõigis konteinerites, automaatne skaleerimine jne. Kõik see töötab juba ja ootab vaid teie protsessidesse oskuslikku integreerimist.