Які найкращі практики для версії тегів докер?

Нещодавно я підключив наші сервери CI для створення зображень докера під час git.

У нас є близько 8 різних контейнерів, які будуються, кожен зі своєю мовою / рамками. Деякі є вузлом і мають package.json, інші - служби python, які не містять інформації про семантичну версію.

Моє питання не в тому, як створити теги, а в тому, щоб створити значення для тегу.

Як забезпечити, щоб кожен тег мав унікальний семантичний номер версії для конкретних зображень? Хто повинен бути авторитетом щодо відстеження / збільшення версії збірки?

Я спрямував би вас до мого реєстру докерів з’єднання та контролю джерел, де dmaze відповів з офіційного forums.docker.com . Введіть хеш і назву гілки або тегів достатньо.

У своєму Dockerfile використовуйте LABEL для запису джерела збірки. Це, ймовірно, включає хеш-коміт з контролю розподіленого джерела (git, Mercurial), ім'я гілки, якщо це доречно, будь-які теги випуску, якщо вони є, та, можливо, деталі, як часова мітка останнього комітету. історія докера та перевірка докера повинні мати можливість їх показувати.

Коли ви докер натискаєте свої зображення, натискайте на них щонайменше двічі, з хешем фіксації та з назвою гілки як частиною "версії" (quay.io/mycorp/imagename:123abc7, quay.io/mycorp/imagename:dmaze-test ). Якщо теги випуску легко доступні, система CI повинна також висувати зображення з цими тегами.

Наразі ми використовуємо комбінацію хеш-назви гілки / фіксування. Нам цього, здається, достатньо. часові позначки, хоча вони є корисними IMO, просто додають захаращеність, оскільки вони не надають нічого, що не робить хеш.

Я згоден з 030 щодо:

хто повинен бути авторитетом щодо відстеження / збільшення версії збірки

На 100% відповідальність КІ веде за підтримку таких речей при належному спілкуванні між іншими командами.

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

Можна створити тег, який складається з декількох елементів, наприклад, комбінація часової позначки, хеш-хет-хеш і семантична версія. Останнє потрібно встановити вручну, тоді як перші два можна автоматизувати. Такий тег може виглядати так:

20171015141729-58617f500f7efe236c7ba6a1dfdf37a478b4c878-0.1.4

Цей тег містить дату складання, фіксацію та семантичну версію. Якщо зображення докера працює у виробництві і виявлено помилку, тоді відома версія продукту, код, який знаходиться всередині, і коли зображення було побудоване та за яких обставин.

Хто повинен бути авторитетом щодо відстеження / збільшення версії збірки?

На мою думку, це повинно бути обов'язком КІ, оскільки це здатне автоматизувати процеси, і оскільки створення тегів може бути автоматизовано, такий інструмент є правильним інструментом для роботи.

Я вважаю, що ви використовуєте один із інструментів DevOps для CI / CD, наприклад, Дженкінс, я пропоную наступний підхід,

Якщо ви використовуєте щось на зразок Дженкінса,

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

колишній: - sudo docker build -t <image_name>:<BUILD_ID>

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