Я бы не использовал фиксацию докера,
Это кажется действительно хорошей идеей, но вы не можете воспроизвести образ по своему желанию, как вы можете с Dockerfile, и вы также не можете изменить базовый образ после того, как это будет сделано, поэтому очень сложно зафиксировать, например, безопасность патч к базовому образу ОС.
Если вы используете полный подход Dockerfile, вы можете повторно запустить сборку docker, и вы снова получите тот же образ. И вы можете изменить базовое изображение.
Поэтому мое эмпирическое правило таково: если вы создаете временный инструмент и не заботитесь о повторном использовании или воспроизведении изображения по своему усмотрению, тогда коммит удобен в использовании.
Насколько я понимаю, Docker каждый образ контейнера состоит из двух частей: это группа слоев только для чтения, составляющих основную часть образа, а затем небольшой слой, доступный для записи, где фиксируются любые изменения.
Когда вы запускаете коммит, Docker создает новый образ, это базовый образ плюс внесенные вами изменения (созданный образ — это отдельный образ), он копирует код на тонкий доступный для записи слой. Таким образом, новый слой только для чтения не создается, он просто сохраняет дельты, которые вы делаете, в тонкий записываемый слой.
Не верьте мне на слово, возьмите Совет Redhat
Для ясности в статье на шаге 5 говорится:
5) Не создавайте образы из запущенных контейнеров. Другими словами, не используйте «docker commit» для создания образа. Этот метод создания изображения нельзя воспроизвести, и его следует полностью избегать. Всегда используйте Dockerfile или любой другой подход S2I (от источника к образу), который полностью воспроизводим, и вы можете отслеживать изменения в Dockerfile, если вы храните его в репозитории системы управления версиями (git).
person
krystan honour
schedule
09.08.2018
