我应该使用Dockerfiles还是映像提交？

我对这两个选项有些困惑。它们似乎是相关的。但是，它们并不是真正兼容的。

例如，似乎使用Dockerfiles意味着您不应该真正提交映像，因为您实际上应该只在git中跟踪Dockerfile并对其进行更改。那么什么是权威性就没有歧义。

但是，图像提交看起来确实不错。太好了，您可以直接修改容器并标记更改以创建另一个图像。我了解您甚至可以从映像提交历史记录中获得类似文件系统差异的信息。太棒了 但是，您不应该使用Dockerfiles。否则，如果您提交了映像，则必须返回到Dockerfile并进行一些更改，以代表您的所作所为。

所以我很伤心。我喜欢图像提交的想法：您不必在Dockerfile中表示图像状态-您可以直接对其进行跟踪。但是，我对于放弃某种清单文件的想法感到不安，该清单文件使您可以快速概览图像中的内容。同样在同一软件包中看到两个似乎不兼容的功能也令人不安。

有人对此有任何想法吗？使用图像提交是否被认为是不好的做法？还是我应该放开我的附件来存放人偶时代的清单文件？我该怎么办？

更新资料：

对于所有认为这是基于意见的问题的人，我不确定。它具有一些主观上的特质，但我认为这主要是一个客观问题。此外，我相信就该主题进行良好的讨论将提供信息。

最后，我希望阅读本文的任何人都能对Dockerfile和映像提交之间的相互关系有更好的了解。

更新-2017/7/18：

我最近才发现图像提交的合法用途。我们只是在公司建立了一条CI管道，在管道的一个阶段中，我们的应用程序测试在容器内运行。在测试运行程序进程在容器的文件系统中生成覆盖结果之后，我们需要从已存在的容器中检索覆盖结果。我们使用图像提交来执行此操作，方法是提交已停止的容器以创建新图像，然后运行显示覆盖文件并将其转储到stdout的命令。所以拥有这个很方便。除了这种非常具体的情况之外，我们使用Dockerfiles定义我们的环境。

Dockerfiles是用于创建映像的工具。

运行的结果docker build .是带有提交的映像，因此无法在未创建提交的情况下使用Dockerfile。问题是，每次发生任何变化时，您是否都要手动更新图像，从而注定自己会遭受黄金图像的诅咒？

黄金图像的诅咒是一个可怕的诅咒，对那些必须继续使用漏洞百出的安全漏洞和基础图像来运行其软件的人们来说，这是一个可怕的诅咒，因为创建该图像的人很久以前就被古代的人吞噬（或转移到新工作），没人知道他们从哪里获得了进入该图像的imagemagic版本。这是唯一可以与老板的儿子三年前雇用的顾问提供的c ++模块链接的东西，无论如何都没关系，因为即使您弄清楚了imagemagic来自于libstdc ++所使用的版本， JNI在支持工具中称创建长发的实习生仅存在于不受支持的ubuntu版本中。

知道解决方案的优点和不便之处是一个好的开始。因为将两者混合可能是一种有效的方法。

缺点：避免黄金形象死角：

如果您不了解如何重建映像，则仅使用提交是不好的。您不想处于无法重建映像的状态。这种最终状态在这里称为黄金形象因为该图像将是您在每个阶段的唯一参考，起点和终点。如果您松开它，将会遇到很多麻烦，因为您无法重建它。致命的死角是有一天您需要重建一个新的一天（例如，因为所有系统库都已过时），而且您也不知道要安装什么...最终会浪费大量时间。

附带说明一下，如果历史记录日志像git一样容易使用（请咨询diff，并在其他图像上重复它们），那么使用commits而不是commits会更好：您会注意到git没有这个难题。

专业版：精巧升级可分发

另一方面，分层提交在分布式升级方面（因此在带宽和部署时间方面）具有相当可观的优势。如果您是在面包师正在处理煎饼时开始处理docker映像（这正是docker所允许的），或者想要立即部署测试版本，则您会更愿意以小提交（而不是小提交）的形式发送小更新全新的形象。特别是在与客户进行持续集成的情况下，应尽快并经常部署错误修复程序。

尝试充分利用两个世界：

在这种情况下，您可能需要标记图像的主要版本，它们应该来自Dockerfiles。由于基于标记版本的提交，因此您可以提供连续的集成版本。这缓解了Dockerfile和分层提交场景的优点和不便之处。在这里，关键是您永远不会通过限制允许对图像进行的提交次数来跟踪图像。

因此，我想这取决于您的情况，您可能不应尝试找到一条规则。但是，无论解决方案如何，您都应避免使用某些实际的死胡同（最终以“黄金形象”场景结束）。