Чи слід використовувати Dockerfiles чи коміти зображення?

Я трохи заплутаний у цих двох варіантах. Здається, вони пов’язані між собою. Однак вони насправді не сумісні.

Наприклад, здається, що використання файлів Dockerfiles означає, що ви не повинні насправді робити коміти для зображень, тому що ви насправді повинні просто відстежувати файл Docker у git і вносити в нього зміни. Тоді не виникає двозначності щодо того, що є авторитетним.

Однак, коміти з зображеннями здаються справді приємними. Це настільки чудово, що ви можете просто змінити контейнер безпосередньо і позначити зміни, щоб створити інше зображення. Я розумію, що ви навіть можете отримати щось на зразок файлової системи, що відрізняється від історії фіксації зображень. Приголомшливо Але тоді ви не повинні використовувати Dockerfiles. В іншому випадку, якщо ви зробили коміт зображення, вам доведеться повернутися до вашого файлу Docker і внести деякі зміни, які відображають те, що ви зробили.

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

Хтось має якісь думки з цього приводу? Чи вважається поганою практикою використання комітів зображення? Або я повинен просто відмовитись від вкладення, щоб маніфестувати файли з моїх лялькових днів? Що я повинен зробити?

Оновлення :

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

Врешті-решт, я сподіваюся, що хтось, хто читає цю публікацію, краще зрозуміє, як Dockerfiles та коміти для зображень співвідносяться між собою.

Оновлення - 2017/7/18 :

Нещодавно я виявив правомірне використання комітів зображень. Ми щойно створили конвеєр CI у нашій компанії, і на одному етапі конвеєра наші тести програм запускаються всередині контейнера. Нам потрібно отримати результати покриття з контейнера, що вийшов, після того, як процес тестового запуску їх створив (у файловій системі контейнера) і контейнер перестав працювати. Для цього ми використовуємо коміти image, фіксуючи зупинений контейнер для створення нового зображення, а потім виконуючи команди, які відображають і скидають файл покриття в stdout. Тож зручно це мати. Окрім цього цілком конкретного випадку, ми використовуємо Dockerfiles для визначення нашого середовища.

Dockerfiles - це інструмент, який використовується для створення зображень.

Результатом запуску docker build .є зображення з комітом, тому неможливо використовувати файл Docker без створення коміту . Питання полягає в тому, чи слід оновлювати зображення вручну кожного разу, коли що-небудь змінюється, і тим самим прирікати себе на прокляття золотого зображення ?

Прокляття золотого образу - це жахливе прокляття, кинуте на людей, які повинні продовжувати жити з баггі, захищеним діркою безпеки, для запуску свого програмного забезпечення, тому що людину, яка його створила, давно поглинули древні (або перейшли на нова робота), і ніхто не знає, звідки у них версія образної магії, яка увійшла в цей образ. і є єдиним, що буде пов’язувати модуль c ++, який надав той консультант, якого син боса найняв три роки тому, і в будь-якому випадку це не має значення, бо навіть якщо ви зрозуміли, звідки imagemagic походить із версії libstdc ++, яку використовує JNI викликає в інструменті підтримки, що стажер зі створеним довгим волоссям і так існує лише у непідтримуваній версії ubuntu.

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

Недолік: уникайте золотого тупика:

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

Як додаткове зауваження , ймовірно, що використання комітів над комітами було б приємніше, якщо журнал історії був би зручним для використання (зверніться до розбіжностей і повторіть їх на інших зображеннях), як це є у git: ви помітите, що git не має ця дилема.

Pro: гладкі оновлення для розповсюдження

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

Спробуйте отримати найкраще з двох світів:

У цьому типі сценаріїв ви, мабуть, захочете позначити основну версію своїх зображень, і вони повинні надходити Dockerfiles. А ви можете надавати версії безперервної інтеграції завдяки комітам, заснованим на тегованій версії. Це пом'якшує переваги та незручності сценарію Dockerfiles і комірування шарів. Тут ключовим моментом є те, що ви ніколи не припиняєте відстежувати свої зображення, обмежуючи кількість комітів, які ви дозволяєте робити з ними.

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