Monorepo teemat on juba korduvalt arutatud ja see tekitab tavaliselt aktiivseid vaidlusi. Luues avatud lähtekoodiga tööriist, mille eesmärk on parandada rakenduste koodide koostamisprotsesse Gitist Docker-piltideks (ja nende edastamist Kubernetesesse), mõtleme me vähe sellele, milline valik on parem. Meie peamine eesmärk on tagada kõik vajalik, et toetada erinevaid arvamusi (kui see ei ole vastuolus mõistusega, loomulikult).
Hiljuti sisse viidud mono-repo tugi werf'is on hea näide sellest. Kuid enne kui edasi minna, vaatame, kuidas see tugi on seotud werf'i kasutamisega ja kuidas siia sobib Docker Registry...
Probleemistik
Kujutage ette olukorda. Ettevõttes on palju arendajate meeskondi, kes tegelevad sõltumatute projektidega. Enamik rakendusi toimib Kuberneteses ja seega — on konteineriseeritud. Konteinerite ja piltide salvestamiseks on vajalik registri (registry) olemasolu. Sellise registrina kasutatakse ettevõttes Docker Hub'i koos ühe konto COMPANY. Sarnaselt enamikule lähtekoode salvestamise süsteemidele, Docker Hub ei luba luua sisemist hierarhiat registrite vahel, nagu ETTEVÕTE/PROJEKT/PILT. Sel juhul... kuidas selle piirangu puhul hallata mitmetasandilisi rakendusi, luues iga projekti jaoks eraldi konto?
Võib-olla on nimetatud olukord kellelegi tuttav, kuid vaatame rakenduste hoidmise korraldust laiemalt, st ilma eelnevalt mainitud näiteta ja Docker Hub'ita.
Lahenduste teed
Kui rakendus on monoliitne, ei tekki küsimusi ja salvestame lihtsalt projekti konteinerite registrisse.
Kui rakendus esindab end mitme komponendina, mikroteenustena, tuleb valida teatud lähenemine. Näite aluseks võttes tüüpiliselt veebirakendust, mis koosneb kahest pildist: eesmine ja tagaosa — võimalikud valikud on järgmised:
- Hoidke pilte eraldi sisemistes registrites:
- Hoidke kõik ühes registris ja võtke arvesse pildi nime silti, näiteks nii:
NB: Tegelikult on veel variant, mis on salvestamine erinevatesse registritesse, PROJEKT-eesmine ja PROJEKT-tagaosa, kuid me ei käsitle seda keerulise toe, organisatsiooni ja kasutajate vaheliste õiguste jagamise tõttu.
Tugi werf'is
Alguses piirdus werf sisemiste hoidlate, õnneks toetavad enamik registreid sellist võimalust. Alates versioonist , lisandus toimetamine registritega, kus sisemist ei toetata, ja Docker Hub kuulub nende hulka. Sellest hetkest alates on kasutajal valik, kuidas säilitada rakenduse pilte.
Rakendamine on saadaval valiku raames --images-repo-mode=multirepo|monorepo (vaikimisi multirepo, st hoidmine sisemistes hoidlates). See määratleb mustrid, mille alusel pildid registreeritud on. Peab vaid valima vajaliku režiimi põhikomandeid kasutades, kõik muu jääb muutumatuks.
Kuna enamik werf'i valikuid saab määrata keskkonnamuutujate kaudu, CI/CD süsteemides on salvestamisrežiimi tavaliselt lihtne määrata kogu projekti jaoks globaalselt. Näiteks GitLabi puhul piisab keskkonnamuutuja lisamisest projekti seadetes: Seaded -> CI / CD -> Muutujad: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Rääkides piltide avaldamisest ja rakenduste juurutamisest (need protsessid on põhjalikult käsitletud vastavates dokumentatsiooni artiklites: ja ), määrab režiim eksklusiivselt malli, mille alusel piltidega töötada.
Detailides peitub diibel
Uue salvestusviisi lisamise peamine erinevus ja keerukus seisneb registri puhastamise protsessis (puhastamisvõimalused, mida werf toetab, vt ).
Werf arvestab puhastamisel Kubernetes'i klastrites kasutatavaid pilte ning kasutaja määratud poliitikaid. Poliitikate aluseks on siltide jagamine strateegiateks. Hetkel toetatud strateegiad:
- 3 strateegiat, mis on seotud Git'i primitiividega, nagu silt, haru ja commit;
- 1 strateegia vabalt valitud kasutaja siltide jaoks.
Teave sildi strateegia kohta salvestatakse pildi avaldamisel lõpppildi etikettidesse. Isegi väärtus — nii nimetatud metasilt — on vajalik poliitika osade rakendamiseks. Näiteks, kui haru või silt eemaldatakse Git'i repos, on mõistlik eemaldada ka seotud kasutamata pildid registrist, mida katab osa meie poliitikatest.
Ühes repolis salvestades (monorepo), konteineri silti all võib peale meta-sildi hoida ka konteineri nime: PROJEKT:eesmine-META-SILT. Nende eraldamiseks ei ole me kasutanud mingit spetsiifilist eraldajat, vaid oleme lihtsalt lisanud vajaliku väärtuse lõppkonteineri silti avaldamisel.
NB: Kui soovite vaatama hakata kõike, mis on kirjeldatud werfi lähtekoodis, siis alguspunktiks võib olla .
Selles artiklis ei kavatse me rohkem tähelepanu pöörata meie lähenemise probleemidele ja põhjendusele: silti strateegiate, andmete säilitamise ja avaldamisprotsessi osas — kõigest sellest on põhjalikult räägitud Dmitri Stolyarovi hiljutises ettekandes: „».
Kokkuvõtteks
Registry ilma sügavat struktuuri toetamine ei olnud meie ega meie teadaolevate kasutajate jaoks probleem — alati on võimalik tõsta eraldi konteinerite registrit (või minna Google Cloudi tingimuslikku Container Registry'isse)… Kuid sellise piiri eemaldamine tundus loogiline, et tööriist oleks mugavam laiemale DevOps kogukonnale. Selle rakendamisel kohtasime peamist raskust konteinerite registri puhastusmehhanismi ümberkujundamisel. Nüüd, kui kõik on valmis, on hea teada, et kellelgi on lihtsam, ja meile (kui selle projekti peamistele arendajatele) ei ennustata tõsiseid raskusi selle funktsiooni täiendavas toetamises.
Jätkake meiega ja varsti räägime teistest uuendustest !
P.S.
Lugege ka meie blogist:
- «»;
- «».
Allikas: habr.com
