Изображения в докере называются ссылками, наиболее распространенными из которых являются хранилище изображений и тег. И этот тег является относительной свободно сформированной строкой, которая указывает на конкретное изображение. Теги лучше всего рассматривать как изменяемый указатель, его можно изменить, вы можете иметь несколько указателей, указывающих на одно и то же изображение, и его можно удалить, в то время как основное изображение может остаться нетронутым.
Поскольку докер не применяет много структуры к тегам (кроме проверки того, что он содержит допустимые символы и не превышает ограничение длины), применение этого правила остается за каждым сопровождающим хранилища, и в результате появилось много разных решений.
Для сопровождающих репозитория, есть несколько распространенных реализаций:
Вариант A: В идеале сопровождающие хранилища следуют некоторой форме semver . Этот номер версии должен соответствовать версии упакованного программного обеспечения, часто с дополнительным номером патча для ревизии образа. Важно отметить, что изображения, помеченные таким образом, должны включать теги не только для версии 1.2.3-1, но также для 1.2.3, 1.2 и 1, каждое из которых обновляется до последнего выпуска в рамках соответствующей иерархии. Это позволяет последующим пользователям зависеть от версии 1.2 и автоматически получать обновления для 1.2.4, 1.2.5 и т. Д. По мере появления исправлений ошибок и обновлений безопасности.
Вариант B: Подобно приведенному выше параметру semver, многие проекты включают в свои теги другие важные метаданные, например, какая архитектура или базовый образ был использован для этой сборки. Обычно это наблюдается в изображениях Alpine и Debian / Slim, или в коде ARM или AMD. Они часто комбинируются с semver, поэтому вы можете увидеть теги типа alpine-1.5 в дополнение к тегам alpine-1 и alpine.
Вариант C: В некоторых проектах используется более ранняя версия, в которой нет обещаний обратной совместимости. Это часто делается с номерами сборки или строкой даты, и действительно, сам Docker использует это, хотя и с процессом, который не поддерживает функции и не допускает серьезных изменений. Я видел довольно много внутренних проектов, в которых компании используют эту стратегию для создания версий своих изображений, полагаясь на номер сборки с CI-сервера.
Вариант D: Я не очень люблю помещать ревизионные хиты Git в качестве тегов изображений, поскольку они не передают подробности без обращения к репозиторию Git. Не каждый пользователь может иметь такой доступ или умение понимать эту ссылку. И, глядя на два разных хэша, я не представляю, что является более новым или совместимым с моим приложением без внешней проверки. Они также предполагают, что единственный важный номер версии от Git, и игнорируют то, что одна и та же версия Git может использоваться для создания нескольких изображений из разных родительских изображений, разных архитектур или просто нескольких Dockerfiles / многоступенчатых целей в одном и том же репозитории Git. Вместо этого я предпочитаю использовать схему меток и, в конечном итоге, аннотации спецификации изображения , как только мы получим инструменты для обработки аннотаций изображений, для отслеживания таких деталей, как ревизии Git. Это помещает редакцию Git в метаданные, которые вы можете запросить для проверки изображения, но при этом сам тег остается для информации пользователя.
Для пользователей изображений, если у вас есть требование избегать непредвиденных изменений в апстриме, есть два варианта, которые я знаю.
Первый - запустить собственный сервер реестра и перенести внешние зависимости на локальный сервер. Docker включает в себя образ для автономного реестра , который вы можете установить, и открытый API, который позволил многим поставщикам хранилищ артефактов поддерживать реестр докеров. Старайтесь регулярно обновлять этот реестр и включайте способ возврата к предыдущим версиям, если обновление нарушает вашу среду.
Второй вариант - остановить в зависимости от изменяемых тегов. Вместо этого вы можете использовать закрепление изображений, которое ссылается на уникальную ссылку реестра на sha256 на манифест, который нельзя изменить. Вы можете найти это значение в RepoDigests при проверке изображения, полученного с сервера реестра:
$ docker inspect -f '{{json .RepoDigests}}' debian:latest
["debian@sha256:de3eac83cd481c04c5d6c7344cd7327625a1d8b2540e82a8231b5675cef0ae5f"]
$ docker run -it --rm debian@sha256:de3eac83cd481c04c5d6c7344cd7327625a1d8b2540e82a8231b5675cef0ae5f /bin/bash
root@ac9db398dc03:/#
Самый большой риск от привязки к определенному изображению, как это, это отсутствие обновлений безопасности и важных исправлений ошибок. Если вы выберете эту опцию, убедитесь, что у вас есть процедура для регулярного обновления этих изображений.
Независимо от того, какое решение вы используете для извлечения изображений, использование последних полезно только для быстрого тестирования разработчика, а не для каких-либо производственных случаев. Поведение последнего полностью зависит от сопровождающего репозитория, некоторые всегда обновляют его до последнего выпуска, некоторые делают его последним стабильным выпуском, а некоторые вообще забывают его обновить. Если вы зависите от последних версий, вы, скорее всего, столкнетесь с перебоями при смене исходных изображений с версии, подобной 1.5 на 2.0, с изменениями, несовместимыми с предыдущими версиями. Ваше следующее развертывание будет непреднамеренно включать эти изменения, если вы явно не зависите от тега, который обещает исправления ошибок и исправления безопасности без внесения изменений.