Каковы лучшие практики для управления версиями тегов Docker?

11

Я недавно подключил наши CI-серверы к созданию образов докеров после git commit.

У нас есть около 8 различных контейнеров, каждый из которых имеет свой собственный язык / фреймворки. Некоторые из них являются узлами и имеют package.json, другие - службы python, которые не содержат информации о семантической версии.

Мой вопрос не о том, как создавать теги, а о создании значений для тега.

Как обеспечить, чтобы каждый тег имел уникальный семантический номер версии для конкретных изображений? Кто должен быть органом по отслеживанию / увеличению версии сборки?

docker continuous-integration versioning

— Джек Мерфи
источник

Каков ваш нынешний подход к созданию тегов?

— 030

Слышно видеть, что вы спрашиваете. Вы говорите «номер семантической версии», который должен быть назначен человеком (наши ИИ еще недостаточно развиты, чтобы решить семантику коммита…). Но затем вы спрашиваете об «увеличении версии сборки». Чем же вы на самом деле интересуетесь? Вы хотите убедиться, что материал просто «увеличивается» (например, номер изменения SCN / системы или что-то еще)? Или вас интересует семантическое содержание номера версии (т.е. есть ли у него несовместимые изменения)?

— AnoE

6

Я бы направил вас в мой пост реестра регистрации и управления источниками Coupling, где dmaze ответил с официального форумов forum.docker.com . Фиксируйте хеш и имя ветви или теги достаточно.

В вашем Dockerfile используйте LABEL для записи источника сборки. Это, вероятно, включает в себя хэш коммита из распределенного управления исходным кодом (git, Mercurial), имя ветки, если это уместно, любые метки релиза, если они присутствуют, и, возможно, такие детали, как метка времени последнего коммита. История докеров и проверка докеров должны быть в состоянии показать это.

Когда вы вставляете изображения в докер, нажимайте их как минимум дважды, с хэшем коммита и с именем ветви в качестве части «version» (quay.io/mycorp/imagename:123abc7, quay.io/mycorp/imagename:dmaze-test ). Если теги релиза легко доступны, система CI также должна выдвигать изображения с этими тегами.

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

Я согласен с 030 относительно:

кто должен быть ответственным за отслеживание / увеличение версии сборки

Ответственность за поддержание таких вещей при надлежащей связи между другими командами лежит на 100%.

— Скот
источник

1

Как обеспечить, чтобы каждый тег имел уникальный семантический номер версии для конкретных изображений?

Можно создать тег, который состоит из нескольких элементов, например, комбинации временной метки, хеша git commit и семантической версии. Последний должен быть установлен вручную, в то время как первые два могут быть автоматизированы. Такой тег может выглядеть следующим образом:

20171015141729-58617f500f7efe236c7ba6a1dfdf37a478b4c878-0.1.4

Этот тег содержит дату сборки, фиксацию и семантическую версию. Если образ докера запускается в производство и обнаруживается ошибка, то известен вариант продукта, код, который находится внутри, когда образ был создан и при каких обстоятельствах.

Кто должен быть органом по отслеживанию / увеличению версии сборки?

По моему мнению, это должно быть обязанностью CI, так как он способен автоматизировать процессы и поскольку создание тегов может быть автоматизировано, такой инструмент является подходящим инструментом для работы.

— 030
источник

1

Я полагаю, что вы используете один из инструментов DevOps для CI / CD, такой как Jenkins, я предлагаю следующий подход,

Если вы используете что-то вроде Jenkins-

Вы можете настроить свою работу таким образом, чтобы вы могли использовать переменную среды Jenkins "BUILD_ID", которая извлекает идентификатор сборки задания при его запуске, чтобы пометить его на своем изображении. Таким образом, вы можете контролировать версии ваших образов докера. Пожалуйста, проверьте приведенный ниже пример.

например: - sudo docker build -t <image_name>:<BUILD_ID>

Итак, если у вас есть механизм, похожий на тег, для вашего SCM, вы можете проверить тег в соответствующем идентификаторе сборки либо в сборках на основе заданий, либо в config.xml идентификатора сборки в JENKINS HOME_FOLDER.

— Тези
источник