{"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\/cs\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Podpora monorepo a multirepo v werf a jak to souvis\u00ed s Docker Registry","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Podpora
\n
\nT\u00e9ma monorepo bylo ji\u017e mnohokr\u00e1t diskutov\u00e1no a obvykle vyvol\u00e1v\u00e1 velmi aktivn\u00ed debaty. Kdy\u017e vytv\u00e1\u0159\u00edme werf<\/a><\/noindex> jako Open Source n\u00e1stroj, kter\u00fd m\u00e1 zlep\u0161it procesy sestaven\u00ed k\u00f3du aplikac\u00ed z Git do Docker obraz\u016f (a jejich n\u00e1sledn\u00e9ho dod\u00e1n\u00ed do Kubernetes), m\u00e1lo p\u0159em\u00fd\u0161l\u00edme o tom, jak\u00e1 volba je lep\u0161\u00ed. Na\u0161\u00edm prim\u00e1rn\u00edm c\u00edlem je poskytnout v\u0161echno pot\u0159ebn\u00e9 pro zast\u00e1nce r\u016fzn\u00fdch n\u00e1zor\u016f (pokud to samoz\u0159ejm\u011b nen\u00ed v rozporu se zdrav\u00fdm rozumem).<\/p>\n

Ned\u00e1vno se objevila podpora mono-repo ve werf \u2014 dobr\u00fd p\u0159\u00edklad toho. Ale nejprve si ujasn\u011bme, jak tato podpora vlastn\u011b souvis\u00ed s pou\u017e\u00edv\u00e1n\u00edm werf a co m\u00e1 spole\u010dn\u00e9ho s Docker Registry\u2026<\/a><\/noindex><\/p>\n

Problematika<\/h2>\n

\nP\u0159edstavme si takovou situaci. Ve firm\u011b je mnoho t\u00fdm\u016f v\u00fdvoj\u00e1\u0159\u016f, kte\u0159\u00ed pracuj\u00ed na nez\u00e1visl\u00fdch projektech. V\u011bt\u0161ina aplikac\u00ed funguje v Kubernetes, a tud\u00ed\u017e jsou kontejnerizov\u00e1ny. Pro ukl\u00e1d\u00e1n\u00ed kontejner\u016f a obraz\u016f je pot\u0159eba registr (registry). Jako takov\u00fd registr ve firm\u011b slou\u017e\u00ed Docker Hub s jedin\u00fdm \u00fa\u010dtem COMPANY<\/code>. Podobn\u011b jako v\u011bt\u0161ina syst\u00e9m\u016f pro ukl\u00e1d\u00e1n\u00ed zdrojov\u00e9ho k\u00f3du, Docker Hub neumo\u017e\u0148uje vytv\u00e1\u0159et vno\u0159enou hierarchii repozit\u00e1\u0159\u016f<\/b>, jako nap\u0159\u00edklad COMPANY\/PROJECT\/IMAGE<\/code>. Jak tedy s t\u00edmto omezen\u00edm uchov\u00e1vat v registru nemonolitn\u00ed aplikace, ani\u017e bychom vytv\u00e1\u0159eli samostatn\u00fd \u00fa\u010det pro ka\u017ed\u00fd projekt? <\/p>\n

\"Podpora
\n
\nMo\u017en\u00e1 je uveden\u00e1 situace n\u011bkomu zn\u00e1m\u00e1, ale poj\u010fme se pod\u00edvat na ot\u00e1zku organizace \u00falo\u017en\u00fdch syst\u00e9m\u016f aplikac\u00ed obecn\u011b, tedy bez vazby na v\u00fd\u0161e uveden\u00fd p\u0159\u00edklad a Docker Hub.<\/p>\n

Mo\u017enosti \u0159e\u0161en\u00ed<\/h3>\n

\nPokud je aplikace monolitn\u00ed<\/b>, dod\u00e1v\u00e1 se v jednom obraze, pak nen\u00ed \u017e\u00e1dn\u00fd probl\u00e9m a jednodu\u0161e uchov\u00e1v\u00e1me obrazy v registru kontejner\u016f projektu.<\/p>\n

Kdy\u017e je aplikace p\u0159edstavena jako n\u011bkolik komponent\u016f, mikroslu\u017eby<\/b>, je t\u0159eba zvolit ur\u010ditou strategii. Na p\u0159\u00edkladu typick\u00e9 webov\u00e9 aplikace, kter\u00e1 se skl\u00e1d\u00e1 ze dvou obraz\u016f: frontend<\/code> a backend<\/code> \u2014 mo\u017en\u00e9 varianty jsou n\u00e1sleduj\u00edc\u00ed:<\/p>\n

    \n
  1. Ukl\u00e1dat obrazy v samostatn\u00fdch vno\u0159en\u00fdch repozit\u00e1\u0159\u00edch:\n

    \"Podpora<\/li>\n

  2. Ukl\u00e1dat v\u0161e v jednom repozit\u00e1\u0159i a n\u00e1zev obrazu zohled\u0148ovat v tagu, nap\u0159\u00edklad n\u00e1sleduj\u00edc\u00edm zp\u016fsobem:\n

    \"Podpora<\/li>\n<\/ol>\n

    \nNB<\/b>: Existuje tak\u00e9 dal\u0161\u00ed mo\u017enost s ukl\u00e1d\u00e1n\u00edm v r\u016fzn\u00fdch repozit\u00e1\u0159\u00edch, PROJECT-frontend<\/code> a PROJECT-backend<\/code>, ale tu nebudeme rozeb\u00edrat kv\u016fli slo\u017eitosti podpory, organizace a rozd\u011blen\u00ed pr\u00e1v mezi u\u017eivateli.<\/i><\/p>\n

    Podpora ve werf<\/h2>\n

    \nZpo\u010d\u00e1tku werf pracoval pouze s vno\u0159en\u00fdmi repozit\u00e1\u0159i \u2014 na\u0161t\u011bst\u00ed v\u011bt\u0161ina registr\u016f tuto mo\u017enost podporuje. Od verze v1.0.4-alpha.3<\/a><\/noindex>, byla p\u0159id\u00e1na podpora pro registry, kter\u00e9 nepodporuj\u00ed vno\u0159enost<\/b>, a Docker Hub je jedn\u00edm z nich. Od t\u00e9 doby m\u011bl u\u017eivatel mo\u017enost vybrat, jak ukl\u00e1dat obrazov\u00e9 soubory aplikace.<\/p>\n

    Implementace je dostupn\u00e1 v r\u00e1mci mo\u017enosti --images-repo-mode=multirepo|monorepo<\/code> (v\u00fdchoz\u00ed hodnota je multirepo<\/code>, tedy ukl\u00e1d\u00e1n\u00ed v vno\u0159en\u00fdch repozit\u00e1\u0159\u00edch). Ur\u010duje vzory, podle kter\u00fdch jsou obrazy ulo\u017eeny v registru. Sta\u010d\u00ed zvolit po\u017eadovan\u00fd re\u017eim p\u0159i pou\u017eit\u00ed z\u00e1kladn\u00edch p\u0159\u00edkaz\u016f, zbytek z\u016fstane nezm\u011bn\u011bn.<\/p>\n

    Jeliko\u017e v\u011bt\u0161inu voleb werf lze nastavovat pomoc\u00ed prom\u011bnn\u00fdch prost\u0159ed\u00ed<\/b>, v CI\/CD syst\u00e9m byl re\u017eim ukl\u00e1d\u00e1n\u00ed obvykle snadno nastavit glob\u00e1ln\u011b pro cel\u00fd projekt. Nap\u0159\u00edklad, v p\u0159\u00edpad\u011b GitLab<\/b> sta\u010d\u00ed p\u0159idat prom\u011bnnou prost\u0159ed\u00ed v nastaven\u00ed projektu: Nastaven\u00ed -> CI \/ CD -> Prom\u011bnn\u00e9: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    Pokud jde o publikaci obraz\u016f a nasazen\u00ed aplikac\u00ed (o t\u011bchto procesech si m\u016f\u017eete p\u0159e\u010d\u00edst podrobn\u011b v p\u0159\u00edslu\u0161n\u00fdch \u010dl\u00e1nc\u00edch dokumentace: Proces publikace<\/a><\/noindex> a Proces nasazen\u00ed<\/a><\/noindex>), re\u017eim v\u00fdhradn\u011b ur\u010duje vzor, podle kter\u00e9ho lze pracovat s obrazem.<\/p>\n

    \u010e\u00e1bel je v detailech<\/h3>\n

    \nRozd\u00edl a hlavn\u00ed obt\u00ed\u017e p\u0159i p\u0159id\u00e1v\u00e1n\u00ed nov\u00e9ho zp\u016fsobu ukl\u00e1d\u00e1n\u00ed spo\u010d\u00edv\u00e1 v procesu \u010di\u0161t\u011bn\u00ed registry (mo\u017enosti \u010di\u0161t\u011bn\u00ed podporovan\u00e9 ve werf, viz Proces \u010di\u0161t\u011bn\u00ed<\/a><\/noindex>)<\/i>.<\/p>\n

    ). P\u0159i \u010di\u0161t\u011bn\u00ed werf bere v \u00favahu obrazy pou\u017e\u00edvan\u00e9 v clusterech Kubernetes a tak\u00e9 politiky nastaven\u00e9 u\u017eivateli. Z\u00e1kladem politik je rozd\u011blen\u00ed tag\u016f na strategie. Moment\u00e1ln\u011b podporovan\u00e9 strategie jsou:<\/p>\n

      \n
    1. 3 strategie spojen\u00e9 s Git primitivy, jako jsou tag, v\u011btev a commity;<\/li>\n
    2. 1 strategie pro libovoln\u00e9 u\u017eivatelsk\u00e9 tagy.<\/li>\n<\/ol>\n

      \nInformace o strategii tagu uchov\u00e1v\u00e1me p\u0159i publikaci obrazu v etiket\u00e1ch kone\u010dn\u00e9ho obrazu. Samotn\u00e1 hodnota \u2014 tzv. metatag<\/b> \u2014 je pot\u0159ebn\u00e1 pro aplikaci \u010d\u00e1st\u00ed politik. Nap\u0159\u00edklad, p\u0159i odstra\u0148ov\u00e1n\u00ed v\u011btve nebo tagu z Git repozit\u00e1\u0159e je logick\u00e9 odstranit tak\u00e9 souvisej\u00edc\u00ed nepou\u017e\u00edvan\u00e9<\/i> obrazy z registru, co\u017e pokr\u00fdv\u00e1 \u010d\u00e1st na\u0161ich politik.<\/p>\n

      P\u0159i ukl\u00e1d\u00e1n\u00ed do jednoho repozit\u00e1\u0159e (monorepo<\/code>), v tagu obrazu m\u016f\u017ee krom\u011b metatagu b\u00fdt tak\u00e9 ulo\u017eeno jm\u00e9no obrazu: PROJEKT:frontend<\/b>-META-TAG<\/code>. Pro jejich odd\u011blen\u00ed jsme nezavedli \u017e\u00e1dn\u00fd specifick\u00fd odd\u011blova\u010d, ale jednodu\u0161e jsme p\u0159idali po\u017eadovanou hodnotu do popisu koncov\u00e9ho obrazu p\u0159i publikaci.<\/p>\n

      NB<\/b>: Pokud m\u00e1te z\u00e1jem pod\u00edvat se na v\u0161e popsan\u00e9 v zdrojov\u00e9m k\u00f3du werf, m\u016f\u017ee b\u00fdt v\u00fdchoz\u00edm bodem PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      V tomto \u010dl\u00e1nku se nebudeme d\u00e1le zab\u00fdvat problematikou a od\u016fvodn\u011bn\u00edm na\u0161eho p\u0159\u00edstupu: o strategi\u00edch ozna\u010dov\u00e1n\u00ed, ukl\u00e1d\u00e1n\u00ed dat v popisech a procesu publikace jako celku \u2014 o tom v\u0161em bylo podrobn\u011b pojedn\u00e1no v ned\u00e1vn\u00e9 p\u0159edn\u00e1\u0161ce Dmitrije Stojarova: \u201ewerf - n\u00e1\u0161 n\u00e1stroj pro CI\/CD v Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      Shrnuto<\/h2>\n

      \nNedostatek podpory registr\u016f bez vno\u0159en\u00ed nebyl blokuj\u00edc\u00edm faktorem pro n\u00e1s ani pro zn\u00e1m\u00e9 u\u017eivatele werf \u2014 v\u017edy je mo\u017en\u00e9 zprovoznit samostatn\u00fd registr obraz\u016f (nebo p\u0159ej\u00edt na jak\u00fdsi Container Registry v Google Cloud)... Nicm\u00e9n\u011b, zru\u0161en\u00ed takov\u00e9ho omezen\u00ed se zd\u00e1lo logick\u00e9, aby byl n\u00e1stroj pohodln\u011bj\u0161\u00ed pro \u0161ir\u0161\u00ed DevOps komunitu. P\u0159i jeho implementaci jsme narazili na hlavn\u00ed obt\u00ed\u017enost p\u0159i p\u0159epracov\u00e1n\u00ed mechanismu \u010di\u0161t\u011bn\u00ed registru kontejner\u016f. Nyn\u00ed, kdy\u017e je v\u0161e hotovo, je pot\u011b\u0161uj\u00edc\u00ed v\u011bd\u011bt, \u017ee to n\u011bkomu usnadnilo pr\u00e1ci a n\u00e1m (jako hlavn\u00edm v\u00fdvoj\u00e1\u0159\u016fm projektu) se v budoucnosti nejev\u00ed \u017e\u00e1dn\u00e9 v\u00fdznamn\u00e9 obt\u00ed\u017ee p\u0159i dal\u0161\u00ed podpo\u0159e t\u00e9to funkce.<\/p>\n

      Z\u016fsta\u0148te s n\u00e1mi a brzy v\u00e1m pov\u00edme o dal\u0161\u00edch novink\u00e1ch v werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nP\u0159e\u010dt\u011bte si tak\u00e9 n\u00e1\u0161 blog:<\/p>\n