Mada ya hazina moja imejadiliwa zaidi ya mara moja na, kama sheria, husababisha mjadala mkali sana. Kuunda Kama zana ya Open Source iliyoundwa ili kuboresha mchakato wa kuunda nambari ya maombi kutoka kwa Git hadi picha za Docker (na kisha kuziwasilisha kwa Kubernetes), hatufikirii sana ni chaguo gani bora. Kwa sisi, ni msingi kutoa kila kitu muhimu kwa wafuasi wa maoni tofauti (ikiwa hii haipingani na akili ya kawaida, bila shaka).
Usaidizi ulioletwa hivi majuzi wa mono-repo katika werf ni mfano mzuri wa hii. Lakini kwanza, hebu tuone jinsi msaada huu kwa ujumla unahusiana na matumizi ya werf na Usajili wa Docker una uhusiano gani nayo ...
Mambo
Hebu fikiria hali hii. Kampuni ina timu nyingi za maendeleo zinazofanya kazi kwenye miradi ya kujitegemea. Programu nyingi zinafanya kazi katika Kubernetes na, ipasavyo, zimewekwa kwenye vyombo. Ili kuhifadhi vyombo na picha, Usajili unahitajika. Kampuni hutumia Docker Hub iliyo na akaunti moja kama sajili kama hiyo. COMPANY. Sawa na mifumo mingi ya uhifadhi wa msimbo wa chanzo, Docker Hub haikuruhusu kuunda safu ya hazina ya hazina, kama vile COMPANY/PROJECT/IMAGE. Katika kesi hii... tunawezaje kuhifadhi maombi yasiyo ya monolithic kwenye sajili na kizuizi hiki bila kuunda akaunti tofauti kwa kila mradi?
Labda hali iliyoelezwa inajulikana kwa mtu wa kwanza, lakini hebu tuangalie suala la kuandaa hifadhi ya maombi kwa ujumla, i.e. bila kumbukumbu ya mfano hapo juu na Docker Hub.
Ufumbuzi
Ikiwa maombi monolithically, inakuja kwa picha moja, basi hakuna maswali yanayotokea na tunahifadhi tu picha kwenye sajili ya chombo cha mradi.
Wakati maombi yanawasilishwa kama vipengele vingi, huduma ndogo ndogo, basi unahitaji kuchagua mbinu fulani. Kwa kutumia mfano wa programu ya kawaida ya wavuti inayojumuisha picha mbili: frontend ΠΈ backend - chaguzi zinazowezekana ni:
- Hifadhi picha katika hazina tofauti zilizowekwa:
- Hifadhi kila kitu kwenye hazina moja, na ujumuishe jina la picha kwenye lebo, kwa mfano, kama ifuatavyo:
NB: Kwa kweli, kuna chaguo jingine na kuhifadhi katika hazina mbalimbali, PROJECT-frontend ΠΈ PROJECT-backend, lakini hatutazingatia kwa sababu ya ugumu wa usaidizi, shirika na usambazaji wa haki kati ya watumiaji.
msaada wa werf
Hapo awali, werf ilipunguzwa kwa hazina zilizowekwa - kwa bahati nzuri, sajili nyingi zinaunga mkono kipengele hiki. Tangu toleo , aliongeza kazi na sajili ambayo kuweka kiota hakutumiki, na Docker Hub ni mmoja wao. Kuanzia wakati huu na kuendelea, mtumiaji alikuwa na chaguo la jinsi ya kuhifadhi picha za programu.
Utekelezaji unapatikana kama sehemu ya chaguo --images-repo-mode=multirepo|monorepo (chaguo-msingi multirepo, i.e. uhifadhi katika hazina zilizowekwa). Inafafanua mifumo ambayo picha huhifadhiwa kwenye Usajili. Inatosha kuchagua hali inayotakiwa wakati wa kutumia amri za msingi, na kila kitu kingine kitabaki bila kubadilika.
Kwa kuwa chaguzi nyingi za werf zinaweza kuwekwa vigezo vya mazingira, katika mifumo ya CI/CD, hali ya uhifadhi kwa kawaida ni rahisi kuweka kimataifa kwa mradi mzima. Kwa mfano, kwa upande wa GitLab Ongeza tu kutofautisha kwa mazingira katika mipangilio ya mradi: Mipangilio -> CI / CD -> Vigezo: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Ikiwa tunazungumza juu ya kuchapisha picha na kusambaza programu (unaweza kusoma juu ya michakato hii kwa undani katika nakala zinazofaa za hati: ΠΈ ), basi hali huamua tu template ambayo unaweza kufanya kazi na picha.
Ibilisi yuko katika maelezo
Tofauti na ugumu kuu wakati wa kuongeza njia mpya ya kuhifadhi ni katika mchakato wa kusafisha Usajili (vipengele vya kusafisha vinavyoungwa mkono katika werf, ona ).
Wakati wa kusafisha, werf huzingatia picha zinazotumiwa katika makundi ya Kubernetes, pamoja na sera zilizosanidiwa na mtumiaji. Sera zinatokana na kugawa vitambulisho katika mikakati. Mikakati inayotumika kwa sasa:
- Mikakati 3 inayohusiana na primitives ya Git kama vile tag, tawi na ahadi;
- Mbinu 1 ya lebo maalum maalum.
Tunahifadhi maelezo kuhusu mkakati wa lebo tunapochapisha picha katika lebo za picha ya mwisho. Maana yenyewe ndiyo inayoitwa meta tag - muhimu kwa kutumia baadhi ya sera. Kwa mfano, wakati wa kufuta tawi au lebo kutoka kwa hazina ya Git, ni busara kufuta isiyotumika picha kutoka kwa sajili, ambayo inafunikwa na sehemu ya sera zetu.
Wakati wa kuhifadhi kwenye hazina moja (monorepo), kwenye tepe ya picha, pamoja na tepe ya meta, jina la picha pia linaweza kuhifadhiwa: PROJECT:frontend-META-TAG. Ili kuwatenganisha, hatukuanzisha kitenganishi chochote mahususi, lakini tuliongeza tu thamani inayohitajika kwenye lebo ya picha ya mwisho wakati wa kuchapisha.
NB: Ikiwa una nia ya kuangalia kila kitu kilichoelezwa katika msimbo wa chanzo cha werf, basi hatua ya kuanzia inaweza kuwa .
Katika nakala hii hatutazingatia zaidi shida na uhalali wa mbinu yetu: juu ya mikakati ya kuweka alama, uhifadhi wa data kwenye lebo na mchakato wa kuchapisha kwa ujumla - yote haya yameelezewa kwa undani katika ripoti ya hivi karibuni ya Dmitry Stolyarov: "'.
Kufupisha
Ukosefu wa usaidizi wa sajili bila kuweka kiota haikuwa sababu ya kuzuia kwetu au watumiaji wa werf tunaowajua - baada ya yote, unaweza daima kuongeza sajili tofauti ya picha (au kubadili Usajili wa Kontena wa masharti katika Wingu la Google) ... Hata hivyo , kuondoa kizuizi kama hicho kulionekana kuwa na mantiki ili kufanya zana iwe rahisi zaidi kwa jumuiya pana ya DevOps. Wakati wa kuitekeleza, tulikumbana na ugumu kuu katika kurekebisha tena utaratibu wa kusafisha sajili ya kontena. Sasa kwa kuwa kila kitu kiko tayari, ni vizuri kujua kuwa imekuwa rahisi kwa mtu, na sisi (kama watengenezaji wakuu wa mradi) hatuoni ugumu wowote unaoonekana katika kusaidia zaidi kipengele hiki.
Kaa nasi na hivi karibuni tutakuambia kuhusu ubunifu mwingine ndani !
PS
Soma pia kwenye blogi yetu:
- Β«";
- Β«'.
Chanzo: mapenzi.com