{"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\/fr\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Support monorepo et multirepo dans werf et quel rapport avec Docker Registry","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Support
\n
\nLe sujet du monorepo a d\u00e9j\u00e0 \u00e9t\u00e9 discut\u00e9 \u00e0 plusieurs reprises et, en g\u00e9n\u00e9ral, suscite des d\u00e9bats assez anim\u00e9s. En cr\u00e9ant werf<\/a><\/noindex> un outil Open Source destin\u00e9 \u00e0 am\u00e9liorer lesprocessus de construction de code d'applications \u00e0 partir de Git en images Docker (et leur livraison subs\u00e9quente dans Kubernetes), nous r\u00e9fl\u00e9chissons peu \u00e0 la question de savoir quel choix est le meilleur. Pour nous, il est prioritaire de fournir tout ce qu'il faut pour les partisans de diff\u00e9rents avis (si cela ne contredit pas le bon sens, bien s\u00fbr).<\/p>\n

La r\u00e9cente prise en charge du mono-repo dans werf en est un bon exemple. Mais d'abord, clarifions comment cette prise en charge est li\u00e9e \u00e0 l'utilisation de werf et quel est le rapport avec Docker Registry...<\/a><\/noindex><\/p>\n

Probl\u00e9matique<\/h2>\n

\nImaginons une telle situation. Dans une entreprise, plusieurs \u00e9quipes de d\u00e9veloppeurs travaillent sur des projets ind\u00e9pendants. La majorit\u00e9 des applications fonctionnent dans Kubernetes, et donc \u2014 sont conteneuris\u00e9es. Pour stocker les conteneurs et les images, il faut un registre (registry). Dans cette entreprise, Docker Hub est utilis\u00e9 avec un seul compte COMPANY<\/code>. Par analogie avec la plupart des syst\u00e8mes de stockage de code source, Docker Hub ne permet pas de cr\u00e9er une hi\u00e9rarchie imbriqu\u00e9e de d\u00e9p\u00f4ts<\/b>, comme COMPANY\/PROJECT\/IMAGE<\/code>. Dans ce cas... comment g\u00e9rer cette limitation pour stocker des applications non monolithiques dans le registre sans cr\u00e9er un compte s\u00e9par\u00e9 pour chaque projet ? <\/p>\n

\"Support
\n
\nPeut-\u00eatre que la situation d\u00e9crite est famili\u00e8re \u00e0 certains, mais examinons la question de l'organisation du stockage des applications en g\u00e9n\u00e9ral, c'est-\u00e0-dire sans se limiter \u00e0 l'exemple mentionn\u00e9 ci-dessus et \u00e0 Docker Hub.<\/p>\n

Voies de solution<\/h3>\n

\nSi l'application est monolithique<\/b>, livr\u00e9e dans une seule image, il n'y a pas de questions et nous sauvegardons simplement les images dans le registre des conteneurs du projet.<\/p>\n

Quand l'application est pr\u00e9sent\u00e9e sous la forme de plusieurs composants, microservices<\/b>, il faut choisir une approche d\u00e9finie. Prenons l'exemple d'une application web typique, compos\u00e9e de deux images : frontend<\/code> et backend<\/code> \u2014 les options possibles sont :<\/p>\n

    \n
  1. Stocker les images dans des d\u00e9p\u00f4ts imbriqu\u00e9s s\u00e9par\u00e9s :\n

    \"Support<\/li>\n

  2. Tout conserver dans un seul d\u00e9p\u00f4t, en consid\u00e9rant le nom de l'image dans le tag, par exemple, comme suit :\n

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

    \nNB<\/b>: En fait, il existe encore une option avec le stockage dans diff\u00e9rents d\u00e9p\u00f4ts, PROJECT-frontend<\/code> et PROJECT-backend<\/code>, mais nous ne la consid\u00e9rerons pas en raison de la complexit\u00e9 de la prise en charge, de l'organisation et de la distribution des droits entre les utilisateurs.<\/i><\/p>\n

    Prise en charge dans werf<\/h2>\n

    \n\u00c0 l'origine, werf se limitait aux d\u00e9p\u00f4ts imbriqu\u00e9s, ce qui est pratique \u00e9tant donn\u00e9 que la plupart des registres supportent cette fonctionnalit\u00e9. \u00c0 partir de la version v1.0.4-alpha.3<\/a><\/noindex>, le support des registres o\u00f9 l'imbrication n'est pas prise en charge<\/b>, y compris Docker Hub, a \u00e9t\u00e9 ajout\u00e9. D\u00e8s lors, l'utilisateur a eu le choix de la mani\u00e8re de stocker les images de l'application.<\/p>\n

    L'impl\u00e9mentation est disponible via l'option --images-repo-mode=multirepo|monorepo<\/code> (par d\u00e9faut, multirepo<\/code>, c'est-\u00e0-dire le stockage dans des d\u00e9p\u00f4ts imbriqu\u00e9s). Elle d\u00e9finit les mod\u00e8les selon lesquels les images sont stock\u00e9es dans le registre. Il suffit de choisir le mode appropri\u00e9 lors de l'utilisation des commandes principales, tout le reste restant inchang\u00e9.<\/p>\n

    \u00c9tant donn\u00e9 que la plupart des options de werf peuvent \u00eatre d\u00e9finies par des variables d'environnement<\/b>, dans les syst\u00e8mes CI\/CD, le mode de stockage est g\u00e9n\u00e9ralement facilement configur\u00e9 de mani\u00e8re globale pour l'ensemble du projet. Par exemple, dans le cas de GitLab,<\/b> il suffit d'ajouter une variable d'environnement dans les param\u00e8tres du projet : R\u00e9glages -> CI \/ CD -> Variables : WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    Concernant la publication des images et le d\u00e9ploiement des applications (ces processus sont expliqu\u00e9s en d\u00e9tail dans les articles correspondants de la documentation : Processus de publication<\/a><\/noindex> et Processus de d\u00e9ploiement<\/a><\/noindex>), le mode d\u00e9termine exclusivement le mod\u00e8le utilis\u00e9 pour travailler avec l'image.<\/p>\n

    Le diable est dans les d\u00e9tails<\/h3>\n

    \nLa diff\u00e9rence et la principale difficult\u00e9 lors de l'ajout d'un nouveau mode de stockage se trouvent dans le processus de nettoyage du registre (pour plus d'informations sur les capacit\u00e9s de nettoyage prises en charge par werf, voir Processus de nettoyage<\/a><\/noindex>)<\/i>.<\/p>\n

    Lors du nettoyage, werf prend en compte les images utilis\u00e9es dans les clusters Kubernetes, ainsi que les politiques d\u00e9finies par l'utilisateur. La base des politiques repose sur la division des balises en strat\u00e9gies. Les strat\u00e9gies actuellement prises en charge sont :<\/p>\n

      \n
    1. 3 strat\u00e9gies li\u00e9es aux primitives Git, telles que la balise, la branche et le commit ;<\/li>\n
    2. 1 strat\u00e9gie pour les balises utilisateur arbitraires.<\/li>\n<\/ol>\n

      \nLes informations concernant la strat\u00e9gie de balise sont conserv\u00e9es lors de la publication de l'image dans les labels de l'image finale. La valeur elle-m\u00eame \u2014 le soi-disant m\u00e9tatag<\/b> \u2014 est n\u00e9cessaire pour l'application de certaines politiques. Par exemple, il est logique de supprimer les images<\/i> non utilis\u00e9es du registre lors de la suppression d'une branche ou d'une balise dans le d\u00e9p\u00f4t Git, ce que couvre une partie de nos politiques.<\/p>\n

      Lors de la sauvegarde dans un m\u00eame d\u00e9p\u00f4t (monorepo<\/code>), outre le m\u00e9tatag, le nom de l'image peut \u00e9galement \u00eatre stock\u00e9 dans la balise de l'image : PROJET :frontend<\/b>-META-TAG<\/code>. Pour les s\u00e9parer, nous n'avons pas introduit de s\u00e9parateur sp\u00e9cifique, mais avons simplement ajout\u00e9 la valeur n\u00e9cessaire dans l'\u00e9tiquette de l'image finale lors de la publication.<\/p>\n

      NB<\/b>Si vous souhaitez voir tout ce qui est d\u00e9crit dans le code source de werf, le point de d\u00e9part peut \u00eatre PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      Dans cet article, nous ne nous attarderons pas davantage sur la probl\u00e9matique et la justification de notre approche : des strat\u00e9gies d'\u00e9tiquetage, du stockage des donn\u00e9es dans les \u00e9tiquettes et du processus de publication en g\u00e9n\u00e9ral \u2014 tout cela a \u00e9t\u00e9 d\u00e9crit en d\u00e9tail dans le r\u00e9cent rapport de Dmitri Stolyarov : \u00abwerf \u2014 notre outil pour CI\/CD dans Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      En r\u00e9sum\u00e9<\/h2>\n

      \nL'absence de prise en charge des registres non imbriqu\u00e9s n'\u00e9tait pas un facteur bloquant pour nous ou pour les utilisateurs de werf que nous connaissons \u2014 il est toujours possible de cr\u00e9er un registre d'images s\u00e9par\u00e9 (ou de passer \u00e0 un registre de conteneurs dans Google Cloud)... Cependant, lever une telle limitation semblait logique pour rendre l'outil plus pratique pour une communaut\u00e9 DevOps plus large. En r\u00e9alisant cela, nous avons \u00e9t\u00e9 confront\u00e9s \u00e0 la principale difficult\u00e9 de la refonte du m\u00e9canisme de nettoyage du registre de conteneurs. Maintenant que tout est pr\u00eat, c'est agr\u00e9able de savoir que cela a facilit\u00e9 les choses pour quelqu'un, et nous (en tant que principaux d\u00e9veloppeurs du projet) ne pr\u00e9voyons pas de difficult\u00e9s majeures dans le support futur de cette fonctionnalit\u00e9.<\/p>\n

      Restez avec nous et tr\u00e8s bient\u00f4t nous parlerons des autres nouveaut\u00e9s dans werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nLisez aussi dans notre blog :<\/p>\n