Við byrjum bloggið okkar með útgáfum sem byggja á nýjustu ræðum tæknistjórans okkar (Dmitry Stolyarov). Öll fóru þau fram árið 2016 á ýmsum faglegum viðburði og voru tileinkuð efninu DevOps og Docker. Eitt myndband frá Docker Moscow fundinum á Badoo skrifstofunni höfum við nú þegar Á netinu. Nýjum munu fylgja greinar sem flytja kjarna skýrslunnar. Svo…
31. maí á ráðstefnunni , sem haldin var sem hluti af hátíðinni "Russian Internet Technologies" (RIT++ 2016), opnaði hlutinn "Stöðug dreifing og dreifing" með skýrslunni "Best Practices of Continuous Delivery with Docker". Það tók saman og kerfisbundið bestu starfsvenjur til að byggja upp stöðuga afhendingu (CD) ferli með því að nota Docker og aðrar opinn uppspretta vörur. Við vinnum með þessar lausnir í framleiðslu sem gerir okkur kleift að treysta á hagnýta reynslu.
Ef þú hefur tækifæri til að eyða klukkutíma , við mælum með að horfa á hana í heild sinni. Annars er hér að neðan aðalyfirlitið í textaformi.
Stöðug sending með Docker
undir Stöðug Afhending við skiljum atburðarásina sem leiðir af því að forritskóðinn frá Git geymslunni kemur fyrst í framleiðslu og endar síðan í skjalasafninu. Hún lítur svona út: Git → Byggja → Próf → Losa → Vinna.
Megnið af skýrslunni er varið til byggingarstigsins (umsóknasamsetningu) og fjallað er stuttlega um efnin sem gefa út og starfa. Við munum tala um vandamál og mynstur sem gera þér kleift að leysa þau og sérstakar útfærslur á þessum mynstrum geta verið mismunandi.
Hvers vegna þarf Docker hérna yfirleitt? Það er ekki fyrir neitt sem við ákváðum að tala um samfellda afhendingu í samhengi við þetta Open Source tól. Þrátt fyrir að öll skýrslan sé helguð notkun þess, koma margar ástæður í ljós þegar litið er til meginmynsturs útfærslu forritakóða.
Aðalútsetningarmynstur
Svo þegar við birtum nýjar útgáfur af forritinu stöndum við vissulega frammi fyrir vandamál í niðri, sem myndast við skiptingu á framleiðsluþjóninum. Umferð frá gömlu útgáfunni af forritinu yfir í þá nýju getur ekki skipt samstundis: fyrst verðum við að ganga úr skugga um að nýju útgáfunni sé ekki aðeins hlaðið niður, heldur einnig „hitað upp“ (þ.e. alveg tilbúið til að þjóna beiðnum).
Þannig munu báðar útgáfur forritsins (gamla og nýjar) virka samtímis í nokkurn tíma. Sem leiðir sjálfkrafa til átök um sameiginlega auðlind: netkerfi, skráarkerfi, IPC osfrv. Með Docker er þetta vandamál auðveldlega leyst með því að keyra mismunandi útgáfur af forritinu í aðskildum ílátum, þar sem auðlindaeinangrun er tryggð innan sama hýsils (miðlara/sýndarvél). Auðvitað geturðu komist af með nokkrar brellur án einangrunar yfirleitt, en ef það er tilbúið og þægilegt tól, þá er það gagnstæða ástæðan - að vanrækja það ekki.
Gámavæðing veitir marga aðra kosti þegar hún er notuð. Sérhver umsókn fer eftir sérstakri útgáfu (eða útgáfusvið) túlkur, framboð á einingum/viðbótum o.s.frv., sem og útgáfur þeirra. Og þetta á ekki aðeins við um nánasta executable umhverfi, heldur einnig um allt umhverfið, þar á meðal kerfishugbúnaður og útgáfu þess (allt að Linux dreifingunni sem notuð er). Vegna þess að gámar innihalda ekki aðeins forritakóða, heldur einnig fyrirfram uppsettan kerfis- og forritahugbúnað af nauðsynlegum útgáfum, geturðu gleymt vandamálum með ósjálfstæði.
Við skulum alhæfa aðal útsetningarmynstur nýjar útgáfur með hliðsjón af eftirfarandi þáttum:
- Í fyrstu keyrir gamla útgáfan af forritinu í fyrsta ílátinu.
- Nýja útgáfan er síðan rúlluð út og „hituð upp“ í öðru íláti. Það er athyglisvert að þessi nýja útgáfa sjálf getur borið ekki aðeins uppfærðan forritakóða, heldur einnig hvers kyns ósjálfstæði hans, auk kerfishluta (til dæmis ný útgáfa af OpenSSL eða dreifingunni í heild sinni).
- Þegar nýja útgáfan er að fullu tilbúin til að þjóna beiðnum skiptir umferð úr fyrsta gámnum yfir í það síðara.
- Nú er hægt að stöðva gömlu útgáfuna.
Þessi nálgun að dreifa mismunandi útgáfum af forritinu í aðskildum ílátum veitir annan þægindi - fljótur afturköllun í gömlu útgáfuna (enda er nóg að skipta um umferð yfir í viðkomandi gám).
Síðasta fyrstu tilmælin hljóma eins og eitthvað sem jafnvel skipstjórinn gat ekki fundið sök á: "[þegar þú skipuleggur stöðuga afhendingu með Docker] Notaðu Docker [og skilja hvað það gefur]" Mundu að þetta er ekki silfurkúla sem mun leysa öll vandamál, heldur tæki sem gefur frábæran grunn.
Afritunarhæfni
Með „afritunarhæfni“ er átt við almennt safn vandamála sem upp koma við notkun forrita. Við erum að tala um slík tilvik:
- Forskriftir sem gæðadeild hefur athugað fyrir sviðsetningu verða að vera nákvæmlega afrituð í framleiðslu.
- Forrit eru birt á netþjónum sem geta tekið á móti pakka frá mismunandi geymsluspeglum (með tímanum eru þeir uppfærðir og með þeim útgáfur uppsettra forrita).
- „Allt virkar fyrir mig á staðnum! (...og verktaki er ekki leyft að fara í framleiðslu.)
- Þú þarft að athuga eitthvað í gömlu (geymdu) útgáfunni.
- ...
Almennur kjarni þeirra snýst um þá staðreynd að fullkomið samræmi við umhverfið sem notað er (sem og fjarveru mannlegs þáttar) er nauðsynlegt. Hvernig getum við tryggt endurgerðanleika? Gerðu Docker myndir byggt á kóða frá Git, og notaðu þá í hvaða verkefni sem er: á prófunarstöðum, í framleiðslu, á staðbundnum vélum forritara... Á sama tíma er mikilvægt að lágmarka aðgerðir sem eru gerðar eftir að setja saman myndina: því einfaldari sem hún er, því minni líkur eru á villum.
Innviðir eru kóða
Ef innviðakröfur (aðgengi á netþjónahugbúnaði, útgáfa hans o.s.frv.) eru ekki formlegar og „forritaðar“ þá getur útfærsla hvers kyns forritauppfærslu haft hörmulegar afleiðingar. Til dæmis, í sviðsetningu hefurðu þegar skipt yfir í PHP 7.0 og endurskrifað kóðann í samræmi við það - þá mun útlit hans í framleiðslu með einhverju gömlu PHP (5.5) örugglega koma einhverjum á óvart. Þú gætir ekki gleymt meiriháttar breytingu á túlkútgáfunni, en „djöfullinn er í smáatriðunum“: undrunin gæti verið í minniháttar uppfærslu á hvers kyns ósjálfstæði.
Aðferð til að leysa þetta vandamál er þekkt sem IaC (Infrastructure as Code, „innviði sem kóða“) og felur í sér að geyma kröfur um innviði ásamt umsóknarkóða. Með því að nota það geta verktaki og DevOps sérfræðingar unnið með sömu Git forritageymsluna, en á mismunandi hlutum hennar. Úr þessum kóða er Docker mynd búin til í Git, þar sem forritið er notað með hliðsjón af öllum sérstöðu innviðanna. Einfaldlega sagt ættu forskriftirnar (reglurnar) til að setja saman myndir að vera í sömu geymslu og frumkóðann og sameinast saman.
Ef um er að ræða fjöllaga forritaarkitektúr - til dæmis, það er nginx, sem stendur fyrir framan forrit sem þegar er í gangi inni í Docker ílát - Docker myndir verða að vera búnar til úr kóða í Git fyrir hvert lag. Þá mun fyrsta myndin innihalda forrit með túlk og öðrum „nánum“ ósjálfstæðum, og önnur myndin mun innihalda andstreymis nginx.
Docker myndir, samskipti við Git
Við skiptum öllum Docker myndum sem safnað er frá Git í tvo flokka: tímabundnar og útgáfur. Tímabundnar myndir merkt með nafni útibúsins í Git, hægt er að skrifa yfir það með næstu skuldbindingu og eru aðeins settar út til forskoðunar (ekki til framleiðslu). Þetta er lykilmunurinn á þeim frá útgáfum: þú veist aldrei hvaða ákveðin skuldbinding er í þeim.
Það er skynsamlegt að safna í tímabundnar myndir: aðalútibúið (þú getur sjálfkrafa rúllað því út á sérstaka síðu til að sjá stöðugt núverandi útgáfu af master), útibú með útgáfum, útibú tiltekinna nýjunga.
Eftir að forskoðun tímabundinna mynda kemur að þörfinni fyrir þýðingu í framleiðslu, settu verktaki ákveðin merki. Sjálfkrafa safnað með merki gefa út mynd (merkið hans samsvarar merkinu frá Git) og er rúllað út í sviðsetningu. Ef það er staðfest af gæðadeildinni fer það í framleiðslu.
dapp
Allt sem lýst er (útrás, myndsamsetning, síðari viðhald) er hægt að útfæra sjálfstætt með því að nota Bash forskriftir og önnur „spuna“ verkfæri. En ef þú gerir þetta, þá mun framkvæmdin á einhverjum tímapunkti leiða til mikillar flóknar og lélegs stjórnunar. Með því að skilja þetta, komum við að því að búa til okkar eigið sérhæfða verkflæðistæki til að byggja upp CI/CD - dapp.
Frumkóði hans er skrifaður í Ruby, opinn uppspretta og birtur á . Því miður er skjölun veikasti punkturinn í tækinu eins og er, en við erum að vinna í því. Og við munum skrifa og tala um dappið oftar en einu sinni, vegna þess að... Við getum í einlægni ekki beðið eftir að deila getu þess með öllu áhugasama samfélaginu, en á meðan, sendu mál þín og dragðu beiðnir og/eða fylgstu með þróun verkefnisins á GitHub.
Uppfært 13. ágúst 2019: sem stendur verkefni dapp endurnefnt í , Kóðinn hans hefur verið endurskrifaður að fullu í Go og skjöl hans hafa verið verulega endurbætt.
Kubernetes
Annað tilbúið Open Source tól sem þegar hefur hlotið verulega viðurkenningu í faglegu umhverfi er Kubernetes, Docker stjórnunarklasi. Umfjöllunarefnið um notkun þess í rekstri verkefna sem byggð eru á Docker er utan gildissviðs skýrslunnar, þannig að kynningin er takmörkuð við yfirlit yfir nokkra áhugaverða eiginleika.
Fyrir útfærslu býður Kubernetes:
- viðbúnaðarrannsókn — athuga hvort nýr útgáfa af forritinu sé reiðubúinn (til að skipta um umferð yfir á það);
- rúllandi uppfærsla - mynduppfærsla í röð í þyrpingu gáma (lokun, uppfærsla, undirbúningur fyrir ræsingu, umferðarskipti);
- samstillt uppfærsla - uppfærsla á mynd í klasa með annarri nálgun: fyrst á helming gámanna, síðan á restinni;
- kanaríútgáfur - setja af stað nýja mynd á takmarkaðan (lítinn) fjölda íláta til að fylgjast með frávikum.
Þar sem Continuous Delivery er ekki aðeins útgáfa nýrrar útgáfu, hefur Kubernetes fjölda möguleika fyrir síðari innviðaviðhald: innbyggt eftirlit og skráningu fyrir alla gáma, sjálfvirka mælingu osfrv. Allt þetta er nú þegar að virka og bíður bara eftir réttu innleiðingu í ferlum þínum.
Lokatillögur
- Notaðu Docker.
- Búðu til Docker myndir af forritum fyrir allar þarfir þínar.
- Fylgdu meginreglunni "Infrastructure is code."
- Tengdu Git við Docker.
- Stjórna röð útsetningar.
- Notaðu tilbúinn vettvang (Kubernetes eða annan).
Myndbönd og glærur
Myndband frá gjörningnum (um klukkutíma) (skýrslan sjálf hefst á 5. mínútu - fylgdu hlekknum til að spila frá þessari stundu).
Kynning á skýrslunni:
PS
Aðrar skýrslur um efnið á blogginu okkar:
- «» (Dmitry Stolyarov; 27. maí 2019 á DevOpsConf);
- «» (Dmitry Stolyarov; 8. nóvember 2018 á HighLoad++);
- «» (Dmitry Stolyarov; 7. nóvember 2017 á HighLoad++);
- «» (Dmitry Stolyarov; 6. júní 2017 á RootConf).
Heimild: www.habr.com