Mono-biltegi baten gaia behin baino gehiagotan eztabaidatu da eta, oro har, oso eztabaida aktiboa sortzen du. Sortzen Git-etik Docker irudietan aplikazio-kodea eraikitzeko prozesua hobetzeko diseinatutako Kode Irekiko tresna gisa (eta gero Kubernetesera entregatzeko), ez dugu asko pentsatzen zein den onena. Guretzat, oinarrizkoa da iritzi ezberdinen aldekoei behar den guztia eskaintzea (horrek zentzuarekin kontraesanean jartzen ez badu, noski).
Duela gutxi sartu den mono-repo laguntza werf-en horren adibide ona da. Baina lehenik eta behin, ikus dezagun euskarri hau werf erabiltzearekin nola erlazionatuta dagoen orokorrean eta Docker Erregistroak zer egin behar duen horrekin...
Gaiak
Imajina dezagun egoera hau. Enpresak garapen talde asko ditu proiektu independenteetan lanean. Aplikazio gehienak Kubernetesen exekutatzen dira eta, beraz, edukiontzietan daude. Ontziak eta irudiak gordetzeko, erregistroa behar da. Erregistro gisa, konpainiak Docker Hub erabiltzen du kontu bakar batekin COMPANY. Iturburu-kodea biltegiratzeko sistema gehienen antzera, Docker Hub-ek ez dizu biltegien hierarkia habiaraturik sortzen uzten, esaterako COMPANY/PROJECT/IMAGE. Kasu horretan... nola gorde ditzakezu erregistroan aplikazio ez-monolitikoak muga honekin proiektu bakoitzerako aparteko kontu bat sortu gabe?
Beharbada, deskribatutako egoera norbaitek lehen eskutik ezagutzen du, baina ikus dezagun orokorrean aplikazioen biltegiratzea antolatzearen gaia, hau da. goiko adibideari eta Docker Hubari erreferentziarik egin gabe.
Irtenbideak
Aplikazioa bada monolitikoki, irudi batean dator, orduan ez dago galderarik eta irudiak proiektuaren edukiontzien erregistroan gordetzen ditugu besterik gabe.
Aplikazio bat osagai anitz gisa aurkezten denean, mikrozerbitzuak, orduan hurbilketa jakin bat behar da. Bi irudiz osatutako web aplikazio tipiko baten adibidean: frontend ΠΈ backend - Aukera posibleak hauek dira:
- Gorde irudiak habiaratutako biltegi bereizietan:
- Gorde dena biltegi batean eta sartu irudiaren izena etiketan, adibidez, honela:
NB: Egia esan, beste aukera bat dago hainbat biltegitan gordetzearekin, PROJECT-frontend ΠΈ PROJECT-backend, baina ez dugu kontuan hartuko erabiltzaileen arteko laguntza, antolaketa eta eskubideen banaketaren konplexutasunagatik.
werf laguntza
Hasieran, werf habiaratutako biltegietara mugatu zen; zorionez, erregistro gehienek funtzio hau onartzen dute. Bertsiotik hasita , erregistroekin lana gehitu zuen habiaratzea ez da onartzen, eta Docker Hub horietako bat da. Une horretatik aurrera, erabiltzaileak aukera du aplikazioaren irudiak nola gorde.
Inplementazioa aukeraren zati gisa eskuragarri --images-repo-mode=multirepo|monorepo (lehenetsia multirepo, hau da. biltegiratze habiaratuetan). Irudiak erregistroan gordetzeko ereduak definitzen ditu. Nahikoa da oinarrizko komandoak erabiltzean nahi den modua hautatzea, eta gainerako guztia aldatu gabe geratuko da.
Werf aukera gehienak ezar daitezkeelako ingurune-aldagaiak, CI / CD sistemetan, biltegiratze modua orokorrean erraza da proiektu osorako ezartzeko. Adibidez, GitLab-en kasuan gehitu ingurumen-aldagai bat proiektuaren ezarpenetan: Ezarpenak -> CI / CD -> Aldagaiak: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Irudiak argitaratzeari eta aplikazioak zabaltzeari buruz hitz egiten badugu (prozesu hauei buruz zehatz-mehatz irakurri dezakezu dagokion dokumentazio-artikuluetan: ΠΈ ), orduan moduak irudiarekin lan egin dezakezun txantiloia zehazten du soilik.
Deabrua xehetasunetan dago
Biltegiratze metodo berri bat gehitzean aldea eta zailtasun nagusia erregistroa garbitzeko prozesuan dago (Werf-ek onartzen dituen garbiketa-eginbideetarako, ikus ).
Garbiketan, werf-ek Kubernetes klusterretan erabiltzen diren irudiak hartzen ditu kontuan, baita erabiltzaileak konfiguratutako politikak ere. Politikak etiketak estrategietan banatzean oinarritzen dira. Gaur egun onartzen diren estrategiak:
- Git primitiboekin erlazionatutako 3 estrategia, hala nola etiketa, adar eta konpromezua;
- Etiketa pertsonalizatu pertsonalizatuetarako 1 estrategia.
Etiketa estrategiari buruzko informazioa gordetzen dugu irudia azken irudiaren etiketetan argitaratzean. Esanahia bera deiturikoa da meta etiketa β politika batzuk aplikatzeko beharrezkoak. Adibidez, Git biltegi batetik adar edo etiketa bat ezabatzean, logikoa da asoziatuak ezabatzea erabili gabe Erregistroko irudiak, gure politiken zati batek barne hartzen dituena.
Biltegi batean gordetzen denean (monorepo), irudi-etiketan, meta-etiketaz gain, irudiaren izena ere gorde daiteke: PROJECT:frontend-META-TAG. Horiek bereizteko, ez dugu bereizle zehatzik sartu, baizik eta azken irudiaren etiketari beharrezko balioa gehitu besterik ez dago argitaratzean.
NB: werf iturburu-kodean deskribatutako guztia aztertzea interesatzen bazaizu, abiapuntua izan daiteke .
Artikulu honetan ez diegu arreta gehiago jarriko gure ikuspegiaren arazoei eta justifikazioari: etiketatze-estrategiei, etiketetan datuak biltegiratzeari eta, oro har, argitaratze-prozesuari buruz - hori guztia zehatz-mehatz deskribatzen da Dmitry Stolyarov-ek egindako azken txostenean: "'.
Laburbilduz
Hari gabeko erregistroetarako laguntza eza ez zen guretzat edo ezagutzen ditugun werf erabiltzaileentzat blokeo-faktore bat izan - azken finean, beti egin dezakezu aparteko irudi-erregistro bat (edo baldintzapeko edukiontzi-erregistro batera aldatu Google Cloud-en) ... Hala ere, murrizketa hori kentzea logikoa zirudien tresna DevOps komunitate zabalagoarentzat erosoagoa izan zedin. Ezartzean, edukiontzien erregistroa garbitzeko mekanismoa berritzeko zailtasun nagusiari aurre egin genion. Orain dena prest dagoenez, atsegina da norbaitentzat errazagoa bihurtu dela konturatzea, eta guk (proiektuaren garatzaile nagusi gisa) ez dugu zailtasun nabarmenik izango funtzio hau gehiago laguntzeko.
Egon gurekin eta laster beste berrikuntzen berri emango dizugu !
PS
Irakurri ere gure blogean:
- «»;
- Β«'.
Iturria: www.habr.com