Monohoidla teemat on käsitletud rohkem kui korra ja see tekitab reeglina väga aktiivset poleemikat. Luues avatud lähtekoodiga tööriistana, mis on loodud rakenduskoodi loomise protsessi parandamiseks Gitist Dockeri piltideni (ja seejärel Kubernetesesse toimetamiseks), ei mõtle me palju sellele, milline valik on parim. Meie jaoks on esmatähtis pakkuda kõike vajalikku erinevate arvamuste pooldajatele (kui see muidugi terve mõistusega vastuollu ei lähe).
werfi hiljutine mono-repo toetus on selle hea näide. Kuid kõigepealt selgitame välja, kuidas see tugi on üldiselt seotud werfi kasutamisega ja mis on Dockeri registril sellega pistmist ...
Probleemid
Kujutagem ette sellist olukorda. Ettevõttel on palju iseseisvate projektidega tegelevaid arendusmeeskondi. Enamik rakendusi töötab Kubernetesis ja on seetõttu konteineris. Konteinerite, piltide salvestamiseks vajate registrit (registrit). Sellise registrina kasutab ettevõte Docker Hubi ühe kontoga COMPANY. Sarnaselt enamiku lähtekoodi salvestussüsteemidega, Docker Hub ei luba pesastatud hoidlate hierarhiat, nagu näiteks COMPANY/PROJECT/IMAGE. Sellisel juhul… kuidas saate selle piiranguga mittemonoliitseid rakendusi registris salvestada ilma iga projekti jaoks eraldi kontot loomata?
Võib-olla on kirjeldatud olukord kellelegi tuttav, kuid vaatleme rakenduste salvestusruumi korraldamise küsimust üldiselt, st. viitamata ülaltoodud näitele ja Docker Hubile.
Lahendused
Kui rakendus monoliitne, tuleb ühe pildina, siis küsimusi ei teki ja salvestame pildid lihtsalt projekti konteinerregistrisse.
Kui rakendus on esitatud mitme komponendina, mikroteenused, siis on vaja teatud lähenemist. Kahest pildist koosneva tüüpilise veebirakenduse näitel: frontend и backend - võimalikud valikud on järgmised:
- Salvestage pilte eraldi pesastatud hoidlates:
- Salvestage kõik ühte hoidlasse ja arvestage sildis oleva pildi nimega, näiteks järgmiselt:
NB: Tegelikult on erinevatesse hoidlatesse salvestamiseks veel üks võimalus, PROJECT-frontend и PROJECT-backend, kuid me ei võta seda arvesse tugiteenuste, korralduse ja kasutajatevahelise õiguste jagamise keerukuse tõttu.
werfi tugi
Algselt piirdus werf pesastatud hoidlatega – õnneks toetab enamik registreid seda funktsiooni. Alates versioonist , lisatud töö registritega, milles pesastamist ei toetataja Docker Hub on üks neist. Sellest hetkest alates on kasutajal valida, kuidas rakenduse pilte salvestada.
Rakendus saadaval valiku all --images-repo-mode=multirepo|monorepo (vaikimisi multirepo, st. pesastatud hoidlates). See määratleb mustrid, mille järgi pilte registris salvestatakse. Põhikäskude kasutamisel piisab soovitud režiimi valimisest ja kõik muu jääb muutumatuks.
Kuna enamikku werfi valikuid saab seadistada keskkonnamuutujadCI/CD süsteemides on salvestusrežiimi tavaliselt lihtne kogu projekti jaoks globaalselt seadistada. Näiteks, GitLabi puhul lihtsalt lisage projekti seadetesse keskkonnamuutuja: Seadistused -> CI / CD -> Muutujad: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Kui räägime piltide avaldamisest ja rakenduste juurutamisest (nende protsesside kohta saate üksikasjalikult lugeda asjakohastest dokumentatsiooni artiklitest: и ), siis määrab režiim ainult malli, mille abil saate pildiga töötada.
Kurat peitub detailides
Erinevus ja peamine raskus uue salvestusmeetodi lisamisel on registri puhastamise protsess (werf-i toetatud puhastusfunktsioonide kohta vt ).
Puhastamisel võtab werf arvesse Kubernetese klastrites kasutatavaid pilte ja kasutaja konfigureeritud poliitikaid. Eeskirjad põhinevad siltide jagamisel strateegiateks. Praegu toetatud strateegiad:
- 3 strateegiat, mis on seotud Giti primitiividega, nagu silt, haru ja commit;
- 1 strateegia suvaliste kohandatud siltide jaoks.
Salvestame pildi avaldamisel info sildistrateegia kohta lõpliku pildi siltidesse. Tähendus ise on nö metasilt - Mõne poliitika rakendamiseks nõutav. Näiteks Giti hoidlast haru või sildi kustutamisel on loogiline kustutada seotud kasutamata pilte registrist, mis on hõlmatud osaga meie eeskirjadest.
Kui salvestatakse ühte hoidlasse (monorepo), pildisildis saab lisaks metasildile salvestada ka pildi nime: PROJECT:frontend-META-TAG. Nende eraldamiseks ei võtnud me kasutusele mingit konkreetset eraldajat, vaid lihtsalt lisasime avaldamisel vajaliku väärtuse lõpliku pildi sildile.
NB: Kui teil on huvi vaadata kõike, mida werf-i lähtekoodis kirjeldatakse, võib lähtepunktiks olla .
Selles artiklis ei pööra me rohkem tähelepanu meie lähenemisviisi probleemidele ja põhjendustele: märgistamise strateegiate, andmete salvestamise kohta siltidesse ja avaldamisprotsessile tervikuna - kõike seda kirjeldatakse üksikasjalikult Dmitri Stolyarovi hiljutises aruandes: "'.
Kokku võtma
Pesastamata registrite toe puudumine ei olnud meie ega meile tuntud werf-kasutajate jaoks blokeeriv tegur – alati saab ju eraldi pildiregistri tõsta (või Google Cloudis tinglikule konteineriregistrile üle minna)... Samas, sellise piirangu eemaldamine tundus loogiline, et tööriist oleks laiemale DevOpsi kogukonnale mugavam. Selle rakendamisel seisime silmitsi peamise raskusega konteineri registri puhastusmehhanismi ümbertöötamisel. Nüüd, kui kõik on valmis, on tore tõdeda, et kellegi jaoks on see muutunud lihtsamaks ja meil (projekti peamistel arendajatel) ei teki selle funktsiooni edasisel toetamisel märgatavaid raskusi.
Jääge meiega ja peagi räägime teile ka muudest uuendustest !
PS
Loe ka meie blogist:
- «";
- «'.
Allikas: www.habr.com