Le sujet du monoréposition a été discuté plus d'une fois et, en règle générale, suscite un débat très actif. En créant
werf en tant qu'outil Open Source conçu pour améliorer le processus de
compilation du code d'application des images Git vers Docker (et leur livraison ultérieure à Kubernetes), nous ne pensons pas beaucoup au choix le meilleur. Il est primordial pour nous de fournir tout ce qui est nécessaire aux partisans d’opinions différentes (si cela ne contredit pas le bon sens, bien sûr).
La prise en charge récente du mono-repo dans werf en est un bon exemple. Mais d'abord, voyons comment ce support est généralement associé à l'utilisation de werf et qu'est-ce que le Docker Registry a à voir avec cela ...
Problème
Imaginez cette situation. L'entreprise dispose de nombreuses équipes de développement impliquées dans des projets indépendants. La plupart des applications s'exécutent sur Kubernetes et, par conséquent, sont conteneurisées. Pour stocker des conteneurs, des images, un registre est requis. La société utilise le Docker Hub avec un seul compte
COMPANY comme un tel registre. Semblable à la plupart des systèmes de stockage de code source, le
Docker Hub ne vous permet pas de créer une hiérarchie imbriquée de référentiels tels que
COMPANY/PROJECT/IMAGE . Dans ce cas ... comment peut-on conserver des applications non monolithiques dans le registre avec cette restriction sans créer un compte séparé pour chaque projet?
Peut-être que la situation décrite est familière à quelqu'un, 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 au Docker Hub.
Des solutions
Si l'application est
monolithique , vient dans une image, alors il n'y a pas de questions et nous enregistrons simplement les images dans le référentiel du projet.
Lorsqu'une application se présente sous la forme de plusieurs composants,
microservices , il est nécessaire de choisir une approche spécifique. En utilisant un exemple d'une application Web typique composée de deux images:
frontend et
backend , les options possibles sont les suivantes:
- Stockez les images dans des référentiels imbriqués distincts:
- Stockez tout dans un référentiel et prenez le nom de l'image dans la balise, par exemple, comme suit:
NB : En fait, il y a toujours la possibilité de sauvegarder le PROJECT-frontend et PROJECT-backend dans divers référentiels, 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.Assistance Werf
Au départ, werf s'est limité aux référentiels imbriqués - heureusement, la plupart des registres prennent en charge cette fonctionnalité. À partir de la version
v1.0.4-alpha.3 , du travail a été ajouté avec des registres dans lesquels l'
imbrication n'est
pas prise en charge , et Docker Hub parmi eux. À partir de ce moment, l'utilisateur avait le choix de stocker les images d'application.
L'implémentation est disponible dans le cadre de l'option
--images-repo-mode=multirepo|monorepo (par défaut
multirepo , c'est-à-dire stockage dans des référentiels imbriqués). Il définit les modèles par lesquels les images sont stockées dans le registre. Il suffit de choisir le mode souhaité lors de l'utilisation des commandes de base, et tout le reste restera inchangé.
Étant donné que la plupart des options werf peuvent être définies
avec des 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 la 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 en savoir plus sur ces processus dans les articles pertinents de la documentation:
processus de publication et
processus de déploiement ), alors le mode détermine exclusivement le modèle avec lequel vous pouvez travailler avec l'image.
Diable en détail
La différence et la principale difficulté lors de l'ajout d'une nouvelle méthode de stockage résident dans le processus de nettoyage du registre
(pour les options de nettoyage prises en charge par werf, voir le processus de nettoyage ) .
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 aux primitives Git, telles que tag, branch et commit;
- 1 stratégie pour les tags personnalisés.
Nous enregistrons des informations sur la stratégie de balise lors de la publication de l'image dans les étiquettes de l'image finale. La signification elle-même - la soi-disant
balise meta - est nécessaire pour l'application de certaines politiques. Par exemple, lors de la suppression d'une branche ou d'une balise du référentiel Git, il est logique de supprimer les images
inutilisées associées du registre, ce qui est couvert par une partie de nos politiques.
Lors de l'enregistrement dans un référentiel (
monorepo ), en plus de la balise meta, le nom de l'image peut également être stocké dans la balise image:
PROJECT: frontend -META-TAG . Pour les séparer, nous n'avons pas introduit de séparateur spécifique, mais simplement ajouté la valeur nécessaire à l'étiquette de l'image finale lors de la publication.
NB : Si vous êtes intéressé à regarder tout ce qui est décrit dans le code source werf, alors PR 1684 peut servir de point de départ.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: «
werf est notre outil pour CI / CD dans Kubernetes . "
Résumer
L'absence de prise en charge du registre sans imbrication n'était pas un facteur de blocage pour nous ou les utilisateurs werf que nous connaissons - vous pouvez toujours créer un registre d'images distinct (ou basculer vers le registre de conteneurs conditionnel dans Google Cloud) ... Cependant, la suppression de cette restriction semblait logique pour rendre l'outil plus pratique large communauté DevOps. Lors de sa mise en œuvre, nous avons rencontré la principale difficulté de traitement du mécanisme de nettoyage du registre des conteneurs. Maintenant que tout est prêt, il est agréable de réaliser que c'est devenu plus facile pour quelqu'un, et nous (en tant que principaux développeurs du projet) n'avons aucune difficulté significative à continuer à soutenir cette fonctionnalité.
Restez avec nous et très bientôt nous vous parlerons d'autres innovations de
werf !
PS
Lisez aussi dans notre blog: