Краткое вступление в теги Docker

1656678968 kratkoe vstuplenie v tegi docker

Если вы работали с Docker хотя бы некоторое время, я уверен, что вы сталкивались с тегами. Они часто выглядят как «имя_мое_изображение:1», где часть после двоеточия называется тегом. Тег не всегда указывается при добавлении тегов к изображениям, но мы разберемся с этим позже.

С тех пор как я начал использовать Docker, я был очень смущен по поводу тегов. Документация не очень хорошо объясняет их, и на самом деле нет никаких исчерпывающих разъяснений по теме. Вот почему я решил написать этот пост.

Что такое теги Docker?

Итак, что же такое тэги Docker? Простыми словами, теги Docker передают полезную информацию о конкретной версии/варианте изображения. Это псевдонимы идентификатора вашего изображения, которые часто выглядят так: f1477ec11d12. Это просто способ ссылки на ваш образ. Хорошая аналогия в том, как теги Git ссылаются на определенный коммит в вашей истории.

Два наиболее распространенных случая, когда теги вступают в силу:

  1. При создании изображения мы используем следующую команду:
docker build -t username/image_name:tag_name .

Давайте немного попытаемся распаковать, что делает эта команда. Мы приказываем демону Docker получить файл Docker, имеющийся в текущем каталоге (это то, что . в конце делает). Далее мы приказываем демону Docker создать образ и предоставить ему указанный тег. Если вы бежите docker imagesвы должны увидеть изображение, репозиторий которого есть username/image_name и тег есть tag_name.

username/image_name не является обязательным форматом для указания имени изображения. Это просто полезное соглашение, чтобы избежать повторного обозначения изображения тегами, когда вам нужно отправить его в реестр.

Ваше изображение можно назвать как угодно. Для публичного реестра Docker вы ограничены двухуровневой иерархией при именовании изображений. Например, ваше изображение не может называться a/b/c:1. Это ограничение обычно не существует в частных реестрах. Как отмечалось ранее, указывать a tag_name. В скором времени увидим, что будет в этом случае.

2. Явное тегирование изображения через tag команда.

docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]

Эта команда просто создает псевдоним (ссылку) под названием TARGET_IMAGE что относится к SOURCE_IMAGE. Это все, что он делает. Это как назначить существующему изображению другое название для ссылки на него. Обратите внимание, что тег здесь также определен как необязательный с помощью [:TAG] .

Что произойдет, если вы не укажете тег?

Хорошо, теперь давайте разберемся, что произойдет, если вы не укажете тег при добавлении тегов к изображению. Вот где latest тег появляется на изображении. Каждый раз, когда изображение обозначается без явного тега, ему предоставляется latest по умолчанию. Это неудачный выбор названия, вызывающий много путаницы. Но мне нравится думать об этом как о тег по умолчанию который предоставляется изображением, если вы его не указали.

Вокруг много путаницы latest вызвано ожиданием, что это последняя версия образа, особенно в Dockerfiles. Рассмотрим разные сценарии на примере:

Сценарий 1:

Предположим, что в нашем файле Docker присутствует такой оператор:

FROM debian

Поскольку мы не указали ни одного тега, Docker добавит latest отметьте и попробуйте вытащить изображение debian:latest .

Сценарий 2:

FROM debian:9.3

Поскольку тег здесь явно упоминается, Docker вытащит образ Debian с тегом 9.3

Другое дело, о котором следует помнить, заключается в том, что нет правила, утверждающего, что изображение должно иметь лишь один тег. Изображение может иметь несколько меток, и они обычно используются для указания основной и второстепенной версий. Например, рассмотрим это:

bOvBoIYQodn8oPnc9D39cLmXRwp4i-vcgIUc
Страница Docker Hub для Debian

На момент написания этого сообщения latest тег для изображения Debian указывает на 9.3 релиз и в 9 релиз. Это, скорее всего, изменится в будущем всякий раз, когда основная или вспомогательная версия будет столкнуться с изображением.

Обратите внимание, что теги, используемые для семантического управления версиями, являются соблюдаемой конвенцией, но теги не были разработаны просто для этой цели.

Подытоживая, последний не является специальным тегом.

Основной вывод из того, что мы освещали до сих пор, состоит в том last как и любой другой тэг. Разработчик обязан обозначить изображение должным образом, чтобы latest всегда указывает на последний стабильный выпуск образа.

Итак, мы явно не указываем тег в наших файлах Docker при получении изображений, поскольку мы можем получить совсем другую версию базового изображения, чем то, что мы использовали раньше. Нет никаких гарантий относительно того, будет ли это большая или незначительная шишка. Даже старый выпуск можно обозначить как latest.

PS Если вы обнаружили какие-либо неправильные представления/ошибки в сообщении, пожалуйста, напишите мне в твиттере @ScribbingOn.

Спасибо Жерому Петаццони за то, что помог мне разобраться в этом.

Добавить комментарий

Ваш адрес email не будет опубликован.