Должен ли я использовать файлы Dockerfiles или изображения?

Я немного запутался в этих двух вариантах. Они, похоже, связаны между собой. Однако они не совместимы.

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

Однако, компиляция изображения кажется действительно приятной. Это так здорово, что вы можете просто изменить контейнер непосредственно и пометить изменения, чтобы создать другое изображение. Я понимаю, что вы даже можете получить что-то вроде файловой системы diff от истории фиксации изображения. Потрясающие. Но тогда вы не должны использовать Dockerfiles. В противном случае, если вы сделали фиксацию изображения, вам придется вернуться к своему файлу Docker и внести некоторые изменения, которые представляют, что вы сделали.

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

Есть ли у кого-нибудь мысли по этому поводу? Является ли плохая практика использовать коммиты изображения? Или я должен просто отпустить мою привязанность к файлам манифеста из моих кукольных дней? Что мне делать?

Обновление

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

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

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

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

Ответ 1

Dockerfiles - это инструмент, который используется для создания изображений.

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

Проклятие золотого изображения - это ужасное проклятие, которое бросает людей, которые должны продолжать жить с баггией безопасности, находящейся под базовым изображением, чтобы запустить свое программное обеспечение, потому что человек, который его создал, давно был поглощен древними (или перенесенными на новую работу), и никто не знает, где они получили версию imagemagic, которая попала в этот образ. и это единственное, что будет связано с модулем С++, который был предоставлен этим консультантом, сыном босса, нанятым три года назад, и в любом случае это не имеет значения, потому что даже если вы выяснили, где imagemagic пришел из версии libstdС++, используемой JNI вызывает в инструменте поддержки, что стажер с длинными волосами, созданный, существует только в неподдерживаемой версии ubuntu.

Ответ 2

Зная оба решения, преимущества и неудобства - хорошее начало. Потому что сочетание двух, вероятно, является правильным способом.

Кон: избегайте мертвого конца золотого изображения:

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

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

Pro: плавные обновления для распространения

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

Попробуйте получить лучшее из двух миров:

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

Итак, я думаю, это зависит от вашего сценария, и вам, вероятно, не стоит пытаться найти одно правило. Тем не менее, могут возникнуть некоторые реальные тупики, которые вы должны действительно избегать (как в конечном итоге с сценарием "золотого изображения" ) независимо от решения.

Ответ 3

Обе команды dockerfile и docker commit полезны, и я использую их оба.

Использование dockerfile для базового изображения с настройкой только OS и сервера.
Использование docker commit для включения всех библиотек и скомпилированных файлов (в CI/CD).

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