Ămnet monorepo har diskuterats flera gĂ„nger och brukar oftast leda till ganska livliga diskussioner. NĂ€r vi skapar som ett Open Source-verktyg som syftar till att förbĂ€ttra bygprocesserna för applikationskod frĂ„n Git till Docker-avbilder (och deras efterföljande leverans till Kubernetes), tĂ€nker vi sĂ€llan pĂ„ vilket val som Ă€r bĂ€st. För oss Ă€r det primĂ€ra att tillhandahĂ„lla allt nödvĂ€ndigt för anhĂ€ngare av olika Ă„sikter (om det inte strider mot sunt förnuft, förstĂ„s).
Det nyligen tillkomna stödet för mono-repo i werf Ă€r ett bra exempel pĂ„ detta. Men lĂ„t oss först förstĂ„ hur detta stöd överhuvudtaget relaterar till anvĂ€ndningen av werf och vad Docker Registry har att göra med detâŠ
ProblemomrÄdet
LĂ„t oss förestĂ€lla oss en situation. Företaget har mĂ„nga utvecklingsteam som arbetar med oberoende projekt. De flesta applikationer körs i Kubernetes och Ă€r dĂ€rför containrar. För att lagra containrar och avbilder krĂ€vs ett register (registry). I företaget anvĂ€nds Docker Hub med en enda konto FĂRETAG. I likhet med de flesta system för lagring av kĂ€llkod, tillĂ„ter Docker Hub inte att skapa en inre hierarki av förrĂ„d, sĂ„som FĂRETAG/PROJEKT/BILD. I sĂ„ fall⊠hur ska vi lagra icke-monolitiska applikationer i registret utan att skapa ett separat konto för varje projekt?
Möjligen kÀnns den beskrivna situationen bekant för nÄgon, men lÄt oss titta pÄ frÄgan om organisationen av lagring av applikationer generellt, dvs utan att knyta det till det ovan beskrivna exemplet och Docker Hub.
Lösningar
Om applikationen Àr monolitisk, levereras i en bild, sÄ uppstÄr inga frÄgor och vi sparar helt enkelt avbilder i projektets containerregister.
NĂ€r applikationen presenteras i flera komponenter, mikrotjĂ€nster, krĂ€vs det att en viss metod vĂ€ljs. Med ett exempel av en typisk webbapplikation som bestĂ„r av tvĂ„ avbilder: front-end och backend â möjliga alternativ Ă€r:
- Spara avbilder i separata inre förrÄd:
- Spara allt i ett förrÄd och ta hÀnsyn till bildens namn i taggen, till exempel pÄ följande sÀtt:
NB: Faktiskt finns det ett ytterligare alternativ med att spara i olika förrÄd, PROJEKT-frontend och PROJEKT-backend, men vi kommer inte att övervÀga det pÄ grund av svÄrigheterna med stöd, organisation och fördelning av rÀttigheter mellan anvÀndare.
Stöd i werf
Initialt begrĂ€nsade werf sig till inneslutna register â lyckligtvis stöder de flesta register den möjligheten. FrĂ„n och med version , har arbete med register dĂ€r inbĂ€ddning inte stöds, inklusive Docker Hub. FrĂ„n och med nu hade anvĂ€ndaren valet att lagra applikationsbilder.
Implementeringen Àr tillgÀnglig inom alternativet --images-repo-mode=multirepo|monorepo (som standard multirepo, dvs. lagring i inneslutna register). Det definierar mönstren för hur bilder lagras i registret. Det rÀcker att vÀlja rÀtt lÀge nÀr man anvÀnder huvudkommandon, sÄ förblir allt annat oförÀndrat.
Eftersom de flesta alternativen i werf kan stÀllas in med miljövariabler, Àr lagringslÀget vanligtvis enkelt att ange globalt för hela projektet i CI/CD-system. Till exempel, i fallet med GitLab rÀcker det med att lÀgga till en miljövariabel i projektinstÀllningarna: Settings -> CI / CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
NÀr det kommer till publicering av bilder och distribution av applikationer (dessa processer beskrivs i detalj i de motsvarande artiklarna i dokumentationen: och ), sÄ bestÀmmer lÀget enbart mönstret för hur man kan arbeta med bilden.
Demon ligger i detaljerna
Skillnaden och den största utmaningen vid tillĂ€gg av ett nytt lagringssĂ€tt â vid stĂ€dning av registret (borttagning av möjligheter, stödjs av werf, se i ).
Vid stÀdning tar werf hÀnsyn till de bilder som anvÀnds i Kubernetes-kluster, samt de riktlinjer som anvÀndaren stÀller in. Policyn baseras pÄ uppdelning av taggar i strategier. För nÀrvarande stöds följande strategier:
- 3 strategier relaterade till Git-primitiv, sÄsom tagg, gren och commit;
- 1 strategi för godtyckliga anvÀndartaggar.
Informationen om taggstrategin sparas vid publicering av bilden i etiketter för den slutliga bilden. SjĂ€lva vĂ€rdet â den sĂ„ kallade metataggen â Ă€r nödvĂ€ndig för tillĂ€mpning av vissa riktlinjer. Till exempel, vid borttagning av en gren eller tagg frĂ„n Git-repositoriet, Ă€r det logiskt att ta bort ocksĂ„ relaterade oanvĂ€nda bilder frĂ„n registret, vilket omfattas av vissa av vĂ„ra riktlinjer.
Vid lagring i ett enda register (monorepo), kan förutom metataggen Àven namnet pÄ bilden lagras i taggen för bilden: PROJEKT:front-end-META-TAG. För att separera dem anvÀnde vi ingen specifik avskiljare utan lade bara till det nödvÀndiga vÀrdet i etiketten för den slutliga bilden vid publicering.
NB: Om du Àr intresserad av att se allt som beskrivs i kÀllkoden för werf, kan en utgÄngspunkt vara .
I denna artikel kommer vi inte att Ă€gna mer uppmĂ€rksamhet Ă„t problematiken och motiveringen bakom vĂ„r metod: strategier för taggning, datalagring i etiketter och publiceringsprocessen i allmĂ€nhet â det har allt beskrivits utförligt i en recent rapport av Dmitrij Stolyarov: â».
Sammanfattningsvis
Avsaknaden av stöd för register utan inbĂ€ddning var inte ett blockerande faktor för oss eller kĂ€nda anvĂ€ndare av werf â eftersom det alltid gĂ„r att starta ett separat bildregister (eller övergĂ„ till det hypotetiska Container Registry i Google Cloud)⊠Men att ta bort en sĂ„dan begrĂ€nsning verkade logiskt för att göra verktyget mer anvĂ€ndarvĂ€nligt för det bredare DevOps-gemenskapen. NĂ€r vi genomförde det stötte vi pĂ„ den största svĂ„righeten i omarbetningen av mekanismen för att rensa containerregistret. Nu nĂ€r allt Ă€r klart Ă€r det trevligt att inse att det har blivit lĂ€ttare för nĂ„gon, och vi (som de frĂ€msta utvecklarna av projektet) inte förutser nĂ„gra mĂ€rkbara svĂ„righeter i det framtida underhĂ„llet av denna funktion.
FortsÀtt att följa oss sÄ kommer vi snart att berÀtta om andra nyheter inom !
P.S.
LÀs Àven i vÄr blogg:
- «»;
- «».
KĂ€lla: habr.com
