{"id":37667,"date":"2019-10-31T22:18:58","date_gmt":"2019-10-31T19:18:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry\/"},"modified":"2019-10-31T22:18:58","modified_gmt":"2019-10-31T19:18:58","slug":"podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"St\u00f6d f\u00f6r monorepo och multirepo i werf och vad Docker Registry har med det att g\u00f6ra","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"St\u00f6d
\n
\n\u00c4mnet monorepo har diskuterats flera g\u00e5nger och brukar oftast leda till ganska livliga diskussioner. N\u00e4r vi skapar werf<\/a><\/noindex> som ett Open Source-verktyg som syftar till att f\u00f6rb\u00e4ttra bygprocesserna f\u00f6r applikationskod fr\u00e5n Git till Docker-avbilder (och deras efterf\u00f6ljande leverans till Kubernetes), t\u00e4nker vi s\u00e4llan p\u00e5 vilket val som \u00e4r b\u00e4st. F\u00f6r oss \u00e4r det prim\u00e4ra att tillhandah\u00e5lla allt n\u00f6dv\u00e4ndigt f\u00f6r anh\u00e4ngare av olika \u00e5sikter (om det inte strider mot sunt f\u00f6rnuft, f\u00f6rst\u00e5s).<\/p>\n

Det nyligen tillkomna st\u00f6det f\u00f6r mono-repo i werf \u00e4r ett bra exempel p\u00e5 detta. Men l\u00e5t oss f\u00f6rst f\u00f6rst\u00e5 hur detta st\u00f6d \u00f6verhuvudtaget relaterar till anv\u00e4ndningen av werf och vad Docker Registry har att g\u00f6ra med det\u2026<\/a><\/noindex><\/p>\n

Problemomr\u00e5det<\/h2>\n

\nL\u00e5t oss f\u00f6rest\u00e4lla oss en situation. F\u00f6retaget har m\u00e5nga utvecklingsteam som arbetar med oberoende projekt. De flesta applikationer k\u00f6rs i Kubernetes och \u00e4r d\u00e4rf\u00f6r containrar. F\u00f6r att lagra containrar och avbilder kr\u00e4vs ett register (registry). I f\u00f6retaget anv\u00e4nds Docker Hub med en enda konto F\u00d6RETAG<\/code>. I likhet med de flesta system f\u00f6r lagring av k\u00e4llkod, till\u00e5ter Docker Hub inte att skapa en inre hierarki av f\u00f6rr\u00e5d<\/b>, s\u00e5som F\u00d6RETAG\/PROJEKT\/BILD<\/code>. I s\u00e5 fall\u2026 hur ska vi lagra icke-monolitiska applikationer i registret utan att skapa ett separat konto f\u00f6r varje projekt? <\/p>\n

\"St\u00f6d
\n
\nM\u00f6jligen k\u00e4nns den beskrivna situationen bekant f\u00f6r n\u00e5gon, men l\u00e5t oss titta p\u00e5 fr\u00e5gan om organisationen av lagring av applikationer generellt, dvs utan att knyta det till det ovan beskrivna exemplet och Docker Hub.<\/p>\n

L\u00f6sningar<\/h3>\n

\nOm applikationen \u00e4r monolitisk<\/b>, levereras i en bild, s\u00e5 uppst\u00e5r inga fr\u00e5gor och vi sparar helt enkelt avbilder i projektets containerregister.<\/p>\n

N\u00e4r applikationen presenteras i flera komponenter, mikrotj\u00e4nster<\/b>, kr\u00e4vs det att en viss metod v\u00e4ljs. Med ett exempel av en typisk webbapplikation som best\u00e5r av tv\u00e5 avbilder: front-end<\/code> och backend<\/code> \u2014 m\u00f6jliga alternativ \u00e4r:<\/p>\n

    \n
  1. Spara avbilder i separata inre f\u00f6rr\u00e5d:\n

    \"St\u00f6d<\/li>\n

  2. Spara allt i ett f\u00f6rr\u00e5d och ta h\u00e4nsyn till bildens namn i taggen, till exempel p\u00e5 f\u00f6ljande s\u00e4tt:\n

    \"St\u00f6d<\/li>\n<\/ol>\n

    \nNB<\/b>: Faktiskt finns det ett ytterligare alternativ med att spara i olika f\u00f6rr\u00e5d, PROJEKT-frontend<\/code> och PROJEKT-backend<\/code>, men vi kommer inte att \u00f6verv\u00e4ga det p\u00e5 grund av sv\u00e5righeterna med st\u00f6d, organisation och f\u00f6rdelning av r\u00e4ttigheter mellan anv\u00e4ndare.<\/i><\/p>\n

    St\u00f6d i werf<\/h2>\n

    \nInitialt begr\u00e4nsade werf sig till inneslutna register \u2014 lyckligtvis st\u00f6der de flesta register den m\u00f6jligheten. Fr\u00e5n och med version v1.0.4-alpha.3<\/a><\/noindex>, har arbete med register d\u00e4r inb\u00e4ddning inte st\u00f6ds<\/b>, inklusive Docker Hub. Fr\u00e5n och med nu hade anv\u00e4ndaren valet att lagra applikationsbilder.<\/p>\n

    Implementeringen \u00e4r tillg\u00e4nglig inom alternativet --images-repo-mode=multirepo|monorepo<\/code> (som standard multirepo<\/code>, dvs. lagring i inneslutna register). Det definierar m\u00f6nstren f\u00f6r hur bilder lagras i registret. Det r\u00e4cker att v\u00e4lja r\u00e4tt l\u00e4ge n\u00e4r man anv\u00e4nder huvudkommandon, s\u00e5 f\u00f6rblir allt annat of\u00f6r\u00e4ndrat.<\/p>\n

    Eftersom de flesta alternativen i werf kan st\u00e4llas in med milj\u00f6variabler<\/b>, \u00e4r lagringsl\u00e4get vanligtvis enkelt att ange globalt f\u00f6r hela projektet i CI\/CD-system. Till exempel, i fallet med GitLab<\/b> r\u00e4cker det med att l\u00e4gga till en milj\u00f6variabel i projektinst\u00e4llningarna: Settings -> CI \/ CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    N\u00e4r det kommer till publicering av bilder och distribution av applikationer (dessa processer beskrivs i detalj i de motsvarande artiklarna i dokumentationen: Publish process<\/a><\/noindex> och Deploy process<\/a><\/noindex>), s\u00e5 best\u00e4mmer l\u00e4get enbart m\u00f6nstret f\u00f6r hur man kan arbeta med bilden.<\/p>\n

    Demon ligger i detaljerna<\/h3>\n

    \nSkillnaden och den st\u00f6rsta utmaningen vid till\u00e4gg av ett nytt lagringss\u00e4tt \u2014 vid st\u00e4dning av registret (borttagning av m\u00f6jligheter, st\u00f6djs av werf, se i Cleaning process<\/a><\/noindex>)<\/i>.<\/p>\n

    Vid st\u00e4dning tar werf h\u00e4nsyn till de bilder som anv\u00e4nds i Kubernetes-kluster, samt de riktlinjer som anv\u00e4ndaren st\u00e4ller in. Policyn baseras p\u00e5 uppdelning av taggar i strategier. F\u00f6r n\u00e4rvarande st\u00f6ds f\u00f6ljande strategier:<\/p>\n

      \n
    1. 3 strategier relaterade till Git-primitiv, s\u00e5som tagg, gren och commit;<\/li>\n
    2. 1 strategi f\u00f6r godtyckliga anv\u00e4ndartaggar.<\/li>\n<\/ol>\n

      \nInformationen om taggstrategin sparas vid publicering av bilden i etiketter f\u00f6r den slutliga bilden. Sj\u00e4lva v\u00e4rdet \u2014 den s\u00e5 kallade metataggen<\/b> \u2014 \u00e4r n\u00f6dv\u00e4ndig f\u00f6r till\u00e4mpning av vissa riktlinjer. Till exempel, vid borttagning av en gren eller tagg fr\u00e5n Git-repositoriet, \u00e4r det logiskt att ta bort ocks\u00e5 relaterade oanv\u00e4nda<\/i> bilder fr\u00e5n registret, vilket omfattas av vissa av v\u00e5ra riktlinjer.<\/p>\n

      Vid lagring i ett enda register (monorepo<\/code>), kan f\u00f6rutom metataggen \u00e4ven namnet p\u00e5 bilden lagras i taggen f\u00f6r bilden: PROJEKT:front-end<\/b>-META-TAG<\/code>. F\u00f6r att separera dem anv\u00e4nde vi ingen specifik avskiljare utan lade bara till det n\u00f6dv\u00e4ndiga v\u00e4rdet i etiketten f\u00f6r den slutliga bilden vid publicering.<\/p>\n

      NB<\/b>: Om du \u00e4r intresserad av att se allt som beskrivs i k\u00e4llkoden f\u00f6r werf, kan en utg\u00e5ngspunkt vara PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      I denna artikel kommer vi inte att \u00e4gna mer uppm\u00e4rksamhet \u00e5t problematiken och motiveringen bakom v\u00e5r metod: strategier f\u00f6r taggning, datalagring i etiketter och publiceringsprocessen i allm\u00e4nhet \u2014 det har allt beskrivits utf\u00f6rligt i en recent rapport av Dmitrij Stolyarov: \u201cwerf \u2014 v\u00e5rt verktyg f\u00f6r CI\/CD i Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      Sammanfattningsvis<\/h2>\n

      \nAvsaknaden av st\u00f6d f\u00f6r register utan inb\u00e4ddning var inte ett blockerande faktor f\u00f6r oss eller k\u00e4nda anv\u00e4ndare av werf \u2014 eftersom det alltid g\u00e5r att starta ett separat bildregister (eller \u00f6verg\u00e5 till det hypotetiska Container Registry i Google Cloud)\u2026 Men att ta bort en s\u00e5dan begr\u00e4nsning verkade logiskt f\u00f6r att g\u00f6ra verktyget mer anv\u00e4ndarv\u00e4nligt f\u00f6r det bredare DevOps-gemenskapen. N\u00e4r vi genomf\u00f6rde det st\u00f6tte vi p\u00e5 den st\u00f6rsta sv\u00e5righeten i omarbetningen av mekanismen f\u00f6r att rensa containerregistret. Nu n\u00e4r allt \u00e4r klart \u00e4r det trevligt att inse att det har blivit l\u00e4ttare f\u00f6r n\u00e5gon, och vi (som de fr\u00e4msta utvecklarna av projektet) inte f\u00f6rutser n\u00e5gra m\u00e4rkbara sv\u00e5righeter i det framtida underh\u00e5llet av denna funktion.<\/p>\n

      Forts\u00e4tt att f\u00f6lja oss s\u00e5 kommer vi snart att ber\u00e4tta om andra nyheter inom werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nL\u00e4s \u00e4ven i v\u00e5r blogg:<\/p>\n