La temo de mono-deponejo estis diskutita pli ol unufoje kaj, kiel regulo, kaŭzas tre aktivan diskutadon. Per kreado kiel malfermfonteca ilo desegnita por plibonigi la procezon de konstruado de aplikaĵkodo de Git al Docker-bildoj (kaj poste liveri ilin al Kubernetes), ni ne multe pensas pri kiu elekto estas plej bona. Por ni, estas unuavice provizi ĉion necesan por subtenantoj de malsamaj opinioj (se tio ne kontraŭas la komunan prudenton, kompreneble).
La lastatempa mono-repo-subteno de werf estas bona ekzemplo de tio. Sed unue, ni eltrovu kiel ĉi tiu subteno ĝenerale rilatas al uzado de werf kaj kion la Docker Registry devas fari kun ĝi ...
Temoj
Ni imagu tian situacion. La firmao havas multajn evoluigajn teamojn laborantajn pri sendependaj projektoj. Plej multaj aplikaĵoj funkcias per Kubernetes kaj tial estas enhavitaj. Por konservi ujojn, bildojn, vi bezonas registron (registro). Kiel tia registro, la kompanio uzas Docker Hub kun ununura konto COMPANY. Simila al la plej multaj fontkodaj stokadsistemoj, Docker Hub ne permesas nestitan deponejan hierarkion, kiel COMPANY/PROJECT/IMAGE. En tiu kazo... kiel vi povas konservi ne-monolitajn aplikojn en la registro kun ĉi tiu limigo sen krei apartan konton por ĉiu projekto?
Eble, la priskribita situacio estas konata al iu propraokule, sed ni konsideru la aferon organizi aplikaĵon ĝenerale, t.e. sen referenco al la supra ekzemplo kaj Docker Hub.
Solvoj
Se la aplikaĵo monolita, venas en unu bildo, tiam ne estas demandoj kaj ni simple konservas la bildojn al la ujo-registro de la projekto.
Kiam aplikaĵo estas prezentita kiel multoblaj komponantoj, mikroservoj, tiam certa aliro estas postulata. Sur la ekzemplo de tipa TTT-aplikaĵo konsistanta el du bildoj: frontend и backend - la eblaj opcioj estas:
- Konservu bildojn en apartaj nestitaj deponejoj:
- Konservu ĉion en unu deponejo, kaj konsideru la bildonomon en la etikedo, ekzemple, jene:
NB: Fakte, ekzistas alia opcio kun konservado en malsamaj deponejoj, PROJECT-frontend и PROJECT-backend, sed ni ne konsideros ĝin pro la komplekseco de subteno, organizo kaj distribuo de rajtoj inter uzantoj.
werf subteno
Komence, werf limigis sin al nestitaj deponejoj - feliĉe, plej multaj registroj subtenas ĉi tiun funkcion. Komencante de versio , aldonis laboron kun registroj en kiuj nestumado ne estas subtenata, kaj Docker Hub estas unu el ili. De tiu punkto, la uzanto havas elekton de kiel konservi la aplikajn bildojn.
Efektivigo havebla sub opcio --images-repo-mode=multirepo|monorepo (defaŭlte multirepo, t.e. stokado en nestitaj deponejoj). Ĝi difinas la ŝablonojn per kiuj bildoj estas konservitaj en la registro. Sufiĉas elekti la deziratan reĝimon kiam vi uzas la bazajn komandojn, kaj ĉio alia restos senŝanĝa.
Ĉar plej multaj werf-opcioj povas esti agorditaj mediaj variabloj, en CI / KD-sistemoj, la stokadreĝimo estas kutime facile agordi tutmonde por la tuta projekto. Ekzemple, en la kazo de GitLab simple aldonu mediovariablon en la projektaj agordoj: Agordoj -> CI / KD -> Variabloj: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Se ni parolas pri publikigado de bildoj kaj disvolvado de aplikaĵoj (vi povas legi pri ĉi tiuj procezoj detale en la koncernaj dokumentaj artikoloj: и ), tiam la reĝimo nur determinas la ŝablonon per kiu vi povas labori kun la bildo.
La diablo estas en la detaloj
La diferenco kaj la ĉefa malfacilaĵo aldonante novan stokan metodon estas en la procezo de purigado de la registro (por purigaj funkcioj subtenataj de werf, vidu ).
Dum purigado, werf konsideras la bildojn uzatajn en Kubernetes-grupoj, kaj ankaŭ politikojn agorditajn de la uzanto. Politikoj baziĝas sur divido de etikedoj en strategiojn. Nuntempe subtenataj strategioj:
- 3 strategioj ligitaj per Git-primitivoj kiel etikedo, branĉo kaj kommit;
- 1 strategio por arbitraj kutimaj etikedoj.
Ni konservas informojn pri la etikedstrategio kiam publikigas la bildon en la etikedoj de la fina bildo. La signifo mem estas la tn meta-etikedo - Bezonata por apliki kelkajn el la politikoj. Ekzemple, kiam vi forigas branĉon aŭ etikedon de Git-deponejo, estas logike forigi rilatajn neuzata bildoj de la registro, kiu estas kovrita de parto de niaj politikoj.
Se konservite en unu deponejo (monorepo), en la bilda etikedo, krom la meta-etikedo, la nomo de la bildo ankaŭ povas esti konservita: PROJECT:frontend-META-TAG. Por apartigi ilin, ni enkondukis neniun specifan apartigilon, sed simple aldonis la necesan valoron al la etikedo de la fina bildo dum eldonado.
NB: Se vi interesiĝas rigardi ĉion priskribitan en la werf fontkodo, tiam la deirpunkto povas esti .
En ĉi tiu artikolo, ni ne pli atentos la problemojn kaj pravigon de nia aliro: pri etikedaj strategioj, konservado de datumoj en etikedoj kaj la eldonprocezo entute - ĉio ĉi estas detale priskribita en lastatempa raporto de Dmitry Stolyarov: "".
Resumi
La manko de subteno por nenestitaj registroj ne estis bloka faktoro por ni aŭ la werf-uzantoj de ni konataj - finfine vi ĉiam povas levi apartan bildregistron (aŭ ŝanĝi al kondiĉa Container Registry en Google Cloud) ... Tamen, forigi tian limigon ŝajnis logika por ke la ilo estu pli oportuna al la pli larĝa DevOps-komunumo. Efektivigante ĝin, ni alfrontis la ĉefan malfacilaĵon pri relaborado de la ujregistra purigado-mekanismo. Nun kiam ĉio estas preta, estas agrable rimarki, ke ĝi fariĝis pli facila por iu, kaj ni (kiel la ĉefaj programistoj de la projekto) ne havos rimarkindajn malfacilaĵojn plu subteni ĉi tiun funkcion.
Restu kun ni kaj tre baldaŭ ni rakontos al vi pri aliaj novigoj en !
PS
Legu ankaŭ en nia blogo:
- «»;
- «".
fonto: www.habr.com