Quelles sont les meilleures pratiques pour le contrôle de version des balises Docker?

J'ai récemment connecté nos serveurs CI pour créer des images de docker lors de la validation de git.

Nous avons environ 8 conteneurs différents qui sont construits, chacun avec son propre langage / framework. Certains sont des nœuds et ont un package.json, d'autres sont des services python qui ne contiennent aucune information de version sémantique.

Ma question n'est pas de savoir comment créer des balises, mais de créer les valeurs de la balise.

Comment s'assurer que chaque balise possède un numéro de version sémantique unique pour les images spécifiques? Qui devrait être l'autorité pour suivre / incrémenter une version de build?

Je vous dirigerais vers mon registre de couplage Docker et contrôle des sources où dmaze a répondu depuis les forums officiels.docker.com . Valider le hachage et le nom ou les balises de branche suffit.

Dans votre Dockerfile, utilisez un LABEL pour enregistrer la source de la construction. Cela inclut probablement le hachage de validation du contrôle de source distribué (git, Mercurial), le nom de la branche s'il y a lieu, toutes les balises de version si elles sont présentes, et éventuellement des détails comme l'horodatage du dernier commit. l'historique des dockers et l'inspection des dockers devraient pouvoir les montrer.

Lorsque vous dockez poussez vos images, poussez-les au moins deux fois, avec le hachage de validation et avec le nom de la branche comme partie «version» (quay.io/mycorp/imagename:123abc7, quay.io/mycorp/imagename:dmaze-test ). Si des balises de version sont facilement disponibles, le système CI doit également envoyer des images avec ces balises.

Nous utilisons actuellement une combinaison de nom de branche / hachage de validation. Pour nous, cela semble suffisant. les horodatages alors qu'ils sont utiles IMO ajoutent simplement de l'encombrement car ils ne fournissent rien que le hachage de validation ne fournit pas.

Je suis d'accord avec 030 concernant:

qui devrait être l'autorité sur le suivi / l'incrémentation d'une version de build

100% est la responsabilité du CI de maintenir de telles choses, avec une bonne communication entre les autres équipes.

Comment s'assurer que chaque balise possède un numéro de version sémantique unique pour les images spécifiques?

On pourrait créer une balise qui se compose de plusieurs éléments, par exemple une combinaison d'un horodatage, d'un hachage de validation git et d'une version sémantique. Ce dernier doit être réglé manuellement, tandis que les deux premiers pourraient être automatisés. Une telle balise pourrait ressembler à ceci:

20171015141729-58617f500f7efe236c7ba6a1dfdf37a478b4c878-0.1.4

Cette balise contient la date de construction, la validation et la version sémantique. Si une image docker s'exécute en production et qu'un bogue est détecté, alors on connaît la version du produit, le code qui se trouve à l'intérieur et quand l'image a été construite et dans quelles circonstances.

Qui devrait être l'autorité pour suivre / incrémenter une version de build?

À mon avis, cela devrait être la responsabilité du CI car il est capable d'automatiser les processus et comme la création de balises pourrait être automatisée, un tel outil est le bon outil pour le travail.

Je suppose que vous utilisez l'un des outils DevOps pour CI / CD comme Jenkins, je suggère l'approche suivante,

Si vous utilisez quelque chose comme Jenkins-

• Vous pouvez configurer votre travail de manière à pouvoir utiliser la variable d'environnement Jenkins "BUILD_ID", qui récupère l'ID de construction du travail lorsqu'il est déclenché pour le marquer sur votre image. De cette façon, vous pouvez contrôler la version de vos images Docker. Veuillez vérifier l'exemple ci-dessous.

ex:- sudo docker build -t <image_name>:<BUILD_ID>

Donc, si vous avez un mécanisme de type balise pour votre SCM, vous pouvez vérifier la balise dans l'ID de build respectif, soit dans les builds basés sur le travail, soit dans config.xml de l'ID de build dans JENKINS HOME_FOLDER.