Efni eingeymsla hefur verið rædd oftar en einu sinni og veldur að jafnaði mjög virkum deilum. Með því að búa til sem opinn uppspretta tól hannað til að bæta ferlið við að búa til forritakóða frá Git til Docker myndum (og afhenda þær síðan til Kubernetes), veltum við ekki mikið fyrir okkur hvaða val er best. Fyrir okkur er það fyrst og fremst að útvega allt sem þarf fyrir stuðningsmenn ólíkra skoðana (ef þetta stangast auðvitað ekki á við heilbrigða skynsemi).
Nýlegur stuðningur werf með eingreiðslu er gott dæmi um þetta. En fyrst skulum við reikna út hvernig þessi stuðningur tengist almennt notkun werf og hvað Docker Registry hefur með það að gera ...
Vandamál
Við skulum ímynda okkur slíkar aðstæður. Fyrirtækið hefur mörg þróunarteymi sem vinna að sjálfstæðum verkefnum. Flest forrit keyra á Kubernetes og eru því ílát. Til að geyma ílát, myndir þarftu skrásetningu (skrá). Fyrirtækið notar Docker Hub sem slíka skráningu með einum reikningi COMPANY. Svipað og flest frumkóðageymslukerfi, Docker Hub leyfir ekki hreiðrað geymslustigveldi, eins og COMPANY/PROJECT/IMAGE. Í því tilviki... hvernig geturðu geymt forrit sem ekki eru einlita í skránni með þessari takmörkun án þess að búa til sérstakan reikning fyrir hvert verkefni?
Kannski er lýst ástandi kunnuglegt fyrir einhvern af eigin raun, en við skulum íhuga vandamálið um að skipuleggja geymslu forrita almennt, þ.e. án tilvísunar í dæmið hér að ofan og Docker Hub.
Lausnir
Ef umsóknin einhæfur, kemur í einni mynd, þá eru engar spurningar og við vistum einfaldlega myndirnar í gámaskrá verkefnisins.
Þegar forrit er sett fram sem margir þættir, örþjónustur, þá þarf ákveðna nálgun. Um dæmi um dæmigerð vefforrit sem samanstendur af tveimur myndum: frontend и backend - mögulegir valkostir eru:
- Geymdu myndir í aðskildum hreiðri geymslum:
- Geymdu allt í einni geymslu og skoðaðu nafn myndarinnar í merkinu, til dæmis, eins og hér segir:
NB: Reyndar er annar valkostur með vistun í mismunandi geymslum, PROJECT-frontend и PROJECT-backend, en við munum ekki íhuga það vegna flókins stuðnings, skipulags og dreifingar réttinda milli notenda.
werf stuðningur
Upphaflega takmarkaði werf sig við hreiður geymslur - sem betur fer styðja flestar skrár þennan eiginleika. Byrjar frá útgáfu , bætt við vinnu með skrám þar sem hreiður er ekki stutt, og Docker Hub er einn þeirra. Frá þeim tímapunkti hefur notandinn val um hvernig á að geyma forritamyndirnar.
Framkvæmd í boði undir valmöguleika --images-repo-mode=multirepo|monorepo (sjálfgefið multirepo, þ.e. geymsla í hreiðri geymslum). Það skilgreinir mynstur sem myndir eru geymdar í skránni. Það er nóg að velja viðeigandi stillingu þegar grunnskipanirnar eru notaðar og allt annað verður óbreytt.
Vegna þess að hægt er að stilla flesta werf valkosti Umhverfisbreytur, í CI/CD kerfum er venjulega auðvelt að stilla geymsluhaminn á heimsvísu fyrir allt verkefnið. Til dæmis, í tilviki GitLab bættu bara við umhverfisbreytu í verkefnisstillingunum: Stillingar -> CI / CD -> Breytur: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Ef við tölum um að birta myndir og setja út forrit (þú getur lesið um þessi ferli í smáatriðum í viðeigandi skjalagreinum: и ), þá ákvarðar stillingin eingöngu sniðmátið sem þú getur unnið með myndina.
Djöfullinn er í smáatriðunum
Munurinn og helsti erfiðleikinn þegar nýrri geymsluaðferð er bætt við er að þrífa skrárinn (fyrir hreinsunareiginleika studd af werf, sjá ).
Við hreinsun tekur werf tillit til myndanna sem notaðar eru í Kubernetes klösum, sem og stefnu sem notandinn stillir. Stefna byggist á skiptingu merkja í aðferðir. Aðferðir sem nú eru studdar:
- 3 aðferðir tengdar af Git frumstæðum eins og tag, branch og commit;
- 1 stefna fyrir handahófskennd sérsniðin merki.
Við vistum upplýsingar um merkjastefnuna þegar myndin er birt í merkimiðum lokamyndarinnar. Merkingin sjálf er svokölluð metamerki - Nauðsynlegt að beita sumum reglnanna. Til dæmis, þegar útibú eða merki er eytt úr Git geymslu, er rökrétt að eyða tengdum ónotað myndir úr skránni, sem fellur undir hluta af stefnum okkar.
Þegar það er vistað í einni geymslu (monorepo), í myndmerkinu, auk metamerkisins, er einnig hægt að geyma nafn myndarinnar: PROJECT:frontend-META-TAG. Til að aðskilja þá tókum við ekki upp neina sérstaka skilju heldur bættum einfaldlega nauðsynlegu gildi við merkimiðann á lokamyndinni við birtingu.
NB: Ef þú hefur áhuga á að skoða allt sem lýst er í werf frumkóðanum, þá getur upphafspunkturinn verið .
Í þessari grein munum við ekki gefa meiri gaum að vandamálum og réttlætingu nálgunar okkar: um merkingaraðferðir, vistun gagna í merkimiðum og útgáfuferlinu í heild - öllu þessu er lýst í smáatriðum í nýlegri skýrslu Dmitry Stolyarov: "'.
Til að draga saman
Skortur á stuðningi við óreidda skrár var ekki hindrandi þáttur fyrir okkur eða werf notendur sem við þekktum - þegar öllu er á botninn hvolft geturðu alltaf stofnað sérstaka myndaskrá (eða skipt yfir í skilyrta gámaskrá í Google Cloud) ... Hins vegar, að fjarlægja slíka takmörkun virtist rökrétt til þess að tólið væri þægilegra fyrir breiðari DevOps samfélagið. Við innleiðingu þess stóðum við frammi fyrir helstu erfiðleikum við að endurvinna hreinsunarkerfi gámaskrár. Nú þegar allt er tilbúið er gaman að átta sig á því að það er orðið auðveldara fyrir einhvern og við (sem aðalhönnuðir verkefnisins) munum ekki eiga í neinum merkjanlegum erfiðleikum með að styðja þennan eiginleika frekar.
Vertu hjá okkur og mjög fljótlega munum við segja þér frá öðrum nýjungum í !
PS
Lestu líka á blogginu okkar:
- «»;
- «'.
Heimild: www.habr.com