Le sujet d'un mono-répertoire a été discuté plus d'une fois et, en règle générale, suscite une controverse très active. En créant en tant qu'outil open source conçu pour améliorer le processus de création de code d'application à partir d'images Git vers Docker (puis de leur livraison à Kubernetes), nous ne réfléchissons pas beaucoup au meilleur choix. Pour nous, il est primordial de fournir tout le nécessaire aux supporters d'opinions différentes (si cela ne contredit pas le bon sens, bien sûr).
Le récent support mono-repo de werf en est un bon exemple. Mais d'abord, voyons comment ce support est généralement lié à l'utilisation de werf et ce que le registre Docker a à voir avec cela ...
Problèmes
Imaginons une telle situation. La société dispose de nombreuses équipes de développement travaillant sur des projets indépendants. La plupart des applications s'exécutent sur Kubernetes et sont donc conteneurisées. Pour stocker des conteneurs, des images, vous avez besoin d'un registre (registre). En tant que registre, l'entreprise utilise Docker Hub avec un seul compte COMPANY. Semblable à la plupart des systèmes de stockage de code source, Docker Hub n'autorise pas la hiérarchie des référentiels imbriqués, tel que COMPANY/PROJECT/IMAGE. Dans ce cas… comment pouvez-vous stocker des applications non monolithiques dans le registre avec cette limitation sans créer un compte séparé pour chaque projet ?
Peut-être que la situation décrite est familière à quelqu'un de première main, mais considérons la question de l'organisation du stockage des applications en général, c'est-à-dire. sans référence à l'exemple ci-dessus et Docker Hub.
Des solutions
Si la demande monolithique, vient dans une image, alors il n'y a pas de questions et nous enregistrons simplement les images dans le registre de conteneurs du projet.
Lorsqu'une application se présente sous la forme de plusieurs composants, microservices, alors une certaine approche est nécessaire. Sur l'exemple d'une application web type composée de deux images : frontend и backend - les options possibles sont :
- Stockez les images dans des référentiels imbriqués séparés :
- Stockez tout dans un référentiel et considérez le nom de l'image dans la balise, par exemple, comme suit :
NB: En fait, il existe une autre option avec l'enregistrement dans différents référentiels, PROJECT-frontend и PROJECT-backend, mais nous ne l'envisagerons pas en raison de la complexité du support, de l'organisation et de la répartition des droits entre les utilisateurs.
prise en charge
Initialement, werf se limitait aux référentiels imbriqués - heureusement, la plupart des registres prennent en charge cette fonctionnalité. A partir de la version , travail ajouté avec les registres dans lesquels l'imbrication n'est pas prise en charge, et Docker Hub en fait partie. À partir de ce moment, l'utilisateur a le choix de la manière de stocker les images de l'application.
Mise en œuvre disponible sous option --images-repo-mode=multirepo|monorepo (défaut multirepo, c'est à dire. stockage dans des référentiels imbriqués). Il définit les modèles selon lesquels les images sont stockées dans le registre. Il suffit de sélectionner le mode souhaité lors de l'utilisation des commandes de base, et tout le reste restera inchangé.
Parce que la plupart des options werf peuvent être définies Variables d'environnement, dans les systèmes CI / CD, le mode de stockage est généralement facile à définir globalement pour l'ensemble du projet. Par exemple, dans le cas de GitLab ajoutez simplement une variable d'environnement dans les paramètres du projet : Paramètres -> CI/CD -> Variables : WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Si nous parlons de publication d'images et de déploiement d'applications (vous pouvez lire ces processus en détail dans les articles de documentation pertinents : и ), alors le mode détermine uniquement le modèle avec lequel vous pouvez travailler avec l'image.
Le diable est dans les détails
La différence et la principale difficulté lors de l'ajout d'une nouvelle méthode de stockage est dans le processus de nettoyage du registre (pour les fonctionnalités de purge prises en charge par werf, voir ).
Lors du nettoyage, werf prend en compte les images utilisées dans les clusters Kubernetes, ainsi que les politiques configurées par l'utilisateur. Les politiques sont basées sur la division des balises en stratégies. Stratégies actuellement prises en charge :
- 3 stratégies liées par des primitives Git telles que tag, branch et commit ;
- 1 stratégie pour les balises personnalisées arbitraires.
Nous enregistrons des informations sur la stratégie de balises lors de la publication de l'image dans les étiquettes de l'image finale. Le sens lui-même est le soi-disant balise méta - Obligation d'appliquer certaines des politiques. Par exemple, lors de la suppression d'une branche ou d'une balise d'un référentiel Git, il est logique de supprimer les inutilisé images du registre, qui est couvert par une partie de nos politiques.
Lorsqu'il est enregistré dans un référentiel (monorepo), dans la balise image, en plus de la balise meta, le nom de l'image peut également être stocké : PROJECT:frontend-META-TAG. Pour les séparer, nous n'avons introduit aucun séparateur spécifique, mais avons simplement ajouté la valeur nécessaire au libellé de l'image finale lors de la publication.
NB: Si vous souhaitez examiner tout ce qui est décrit dans le code source werf, le point de départ peut être .
Dans cet article, nous n'accorderons pas plus d'attention aux problèmes et à la justification de notre approche: à propos des stratégies de marquage, du stockage des données dans les étiquettes et du processus de publication dans son ensemble - tout cela est décrit en détail dans un récent rapport de Dmitry Stolyarov: "».
résumant
Le manque de prise en charge des registres non imbriqués n'était pas un facteur bloquant pour nous ou les utilisateurs de werf que nous connaissons - après tout, vous pouvez toujours créer un registre d'images séparé (ou passer à un registre de conteneurs conditionnel dans Google Cloud) ... Cependant, supprimer une telle restriction semblait logique pour que l'outil soit plus pratique pour la communauté DevOps au sens large. Lors de sa mise en œuvre, nous avons été confrontés à la principale difficulté consistant à retravailler le mécanisme de nettoyage du registre des conteneurs. Maintenant que tout est prêt, il est bon de se rendre compte que c'est devenu plus facile pour quelqu'un, et nous (en tant que principaux développeurs du projet) n'aurons aucune difficulté notable à soutenir davantage cette fonctionnalité.
Restez avec nous et très bientôt nous vous parlerons d'autres innovations dans !
PS
A lire aussi sur notre blog :
- «";
- «».
Source: habr.com