Что мне следует использовать: Dockerfiles или коммиты изображений?

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

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

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

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

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

Обновление :

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

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

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

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

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

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

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

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

Против: избегайте тупика с золотым изображением :

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

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

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

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

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

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

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