Comment fonctionnent les balises Docker?

Les images Docker utilisent des registres pour le contrôle de version, comme le Docker Hub qui héberge des images publiques que tout le monde peut télécharger et exécuter. Cependant, avant de télécharger une image sur le Hub ou tout autre registre, vous devez lui attribuer les balises appropriées.

Conteneur vs image

Il est important de comprendre la différence entre les conteneurs et les images avant de parler de balises, car elles sont souvent utilisées de manière assez interchangeable et cela peut prêter à confusion.

Une image Docker est ce que vous obtenez en exécutant docker build avec votre Dockerfile. Il est composé de plusieurs couches pour optimiser l'utilisation du disque et de la mémoire. Une image est en lecture seule.

Un conteneur Docker est une instance d'une image dans laquelle les processus s'exécutent réellement. Il s'agit d'un système de fichiers en lecture / écriture, donc essentiellement, une image est un modèle à partir duquel vous créez plusieurs conteneurs. Il contient le code de base et tout ce dont l'application a besoin pour démarrer. Les conteneurs sont initialisés avec l'image lors de leur création, puis ils peuvent modifier le système de fichiers à leur guise.

Les images sont ce que vous transmettez au registre de conteneurs. Ensuite, sur vos serveurs, vous pouvez référencer l'image dans le registre pour télécharger le conteneur.

Balises Suivi des versions des images construites

Chaque fois que vous exécutez un docker build, vous créez une nouvelle image avec un identifiant unique, tel que "38054d5e8a27".

Les balises sont simplement des étiquettes qui fournissent un meilleur moyen de gérer le contrôle de version et les versions. Ce sont comme des libellés que vous pouvez attribuer à n'importe quelle version terminée. Plutôt que de référencer l'ID de build, vous pouvez baliser une image avec une étiquette au format major.minor.patch et être facilement en mesure de dire quelle image est quelle image ou quel que soit le format que votre organisation préfère.

Le marquage est assez simple. Vous pouvez utiliser docker tag pour le faire après coup, mais il est beaucoup plus facile de le faire lorsque vous créez à l'aide de -t drapeau:

 docker build -t repository/image:tag .

Cela construit l'image à partir du Dockerfile et la balise avec la balise que vous avez spécifiée. Le tag est le (:TAG) partie, après le point-virgule, même si Docker dira "Successfully tagged repository/image:tag. » le repository/image partie est juste le nom de l'image, et si vous prévoyez de pousser vers un référentiel, vous devez le taguer dans le repository/image:tag format.

Pour Docker Hub, le nom du référentiel est juste votre nom d'utilisateur, donc la commande ressemblerait à quelque chose comme:

 docker build -t anthonyheddings/nginx:tag .

Si vous ne spécifiez pas de tag spécifique, Docker le marque automatiquement comme "le plus récent".

Une autre pratique courante consiste à étiqueter l'image avec l'ID de validation git, liant ainsi le contrôle de version aux images construites. Vous pouvez automatiser cela assez facilement avec git rev-parse:

docker build -t vicerust/core:$(git rev-parse --verify HEAD) .

Une fois qu'une image est balisée, vous pouvez la pousser dans le registre avec docker push, passant dans le repository/image Nom:

docker push repository/image

À partir de là, vous pourrez y accéder en docker run comme d'habitude. Si vous ne spécifiez pas de tag, docker run utilise automatiquement latest.

Le dernier ne signifie pas toujours "le plus récent"

le "Latest" tag est un peu déroutant. Malgré la façon dont le nom sonne, il ne pointe pas toujours vers la dernière version. Il s’agit simplement d’une balise spéciale qui est attribuée automatiquement chaque fois que vous ne spécifiez pas de balise. Cela a pour effet d'éviter complètement les balises et de simplement pousser une «dernière» version.

Vous pouvez utiliser la dernière balise en ne spécifiant simplement pas de balise spécifique:

 docker build -t repository/image .

Ou en marquant manuellement une image comme latest:

 docker build -t repository/image:latest .

ce qui fonctionne bien si vous n'utilisez que la dernière balise. Mais si vous souhaitez également utiliser des balises d'ID de version, vous devrez à chaque fois baliser deux fois vos images, ce qui peut conduire à une «dernière» ne signifiant pas toujours la dernière image créée. Il est recommandé d’éviter d’utiliser latest aux côtés d'autres balises pour éviter cette confusion. Version de vos balises, à chaque fois, soit avec des numéros de patch manuels, soit avec des ID de commit git.