我对这两个选项有点困惑。它们似乎是相关的。但是，它们并不真正兼容。
例如，似乎使用Dockerfiles意味着你不应该真正提交图像，因为你应该只是在git中跟踪Dockerfile并对其进行更改。然后，对权威性没有任何含糊之处。
然而，图像提交似乎非常好。它非常棒，您可以直接修改容器并标记更改以创建另一个图像。我知道你甚至可以从图像提交历史中获得类似文件系统差异的东西。真棒。但是你不应该使用Dockerfiles。否则，如果您提交了图像提交，则必须返回Dockerfile并进行一些更改，以表示您的操作。
所以我被撕裂了。我喜欢图片提交的想法：你不必在Dockerfile中表示你的图像状态 - 你可以直接跟踪它。但我对放弃某种清单文件的想法感到不安，它可以让您快速了解图像中的内容。在同一软件包中看到两个看似不兼容的功能也令人不安。
有没有人对此有任何想法？使用图片提交被认为是不好的做法吗？或者我应该放弃我对Puppet天文件中的清单文件的附件？我该怎么办？
更新：
对于那些认为这是一个基于意见的问题的人，我不太确定。它有一些主观的特质，但我认为它主要是一个客观的问题。此外，我相信对这个主题的一个很好的讨论将提供信息。
最后，我希望阅读这篇文章的人能够更好地理解Dockerfiles和图像提交如何相互关联。
更新 - 2017/7/18 ：
我刚刚发现了图片提交的合法用途。我们只是在我们公司设置CI管道，在管道的一个阶段，我们的app测试在容器内运行。我们需要在测试运行程序生成它们之后（在容器的文件系统中）从已退出的容器中检索覆盖结果，并且容器已停止运行。我们使用图像提交来执行此操作，方法是提交已停止的容器以创建新图像，然后运行显示并将coverage文件转储到stdout的命令。这样做很方便。除了这个非常具体的案例，我们使用Dockerfiles来定义我们的环境。
答案 0 :(得分：40)
Dockerfiles是一种用于创建图像的工具。
运行docker build .的结果是带有提交的图像，所以不能使用Dockerfile而不创建提交。问题是，每当有任何变化时你应该手动更新图像吗？因此让自己陷入金色图像的诅咒？
黄金形象的诅咒是一个可怕的诅咒，他们必须继续生活在一个安全漏洞的基础图像来运行他们的软件，因为创建它的人很久以前被古代人吞噬（或移动）一个新工作）并且没有人知道他们在哪里获得了进入该图像的imagemagic版本。并且是唯一可以链接到三年前老板的儿子雇用的顾问提供的c ++模块，无论如何它并不重要，因为即使你想出了imagemagic来自libstdc ++版本所使用的版本JNI在支持工具中调用了创建长发的实习生，无论如何都只存在于不受支持的ubuntu版本中。
答案 1 :(得分：22)
了解这两种解决方案的优势和不便是一个良好的开端。因为两者的混合可能是一种有效的方法。
骗局：避免黄金映像死胡同：
如果您忘记了如何重建图像，那么仅使用提交很糟糕。 您不希望处于无法重建图像的状态。这个最终状态在这里被称为黄金图像，因为图像将是您唯一的参考，每个阶段的起点和终点。如果你松开它，你会遇到很多麻烦，因为你无法重建它。致命的死胡同是有一天你需要重建一个新的（因为所有的系统库都已经过时了），而且你不知道要安装什么......结束了很长的时间。
作为旁注，如果历史日志很容易使用（参考差异，并在其他图像上重复它们），那么使用提交提交会更好，就像在git中一样：你会注意到git没有这种困境。
Pro：光滑升级以分发
另一方面，分层提交在分布式升级方面具有一些相当大的优势，因此在带宽和部署时间方面具有相当大的优势。如果你开始处理docker图像，因为面包师正在处理煎饼（这正是docker允许的），或者想要立即部署测试版本，你会更乐意以小提交的形式发送一个小更新，而不是全新的形象。特别是当您的客户持续集成时，应尽快并经常部署错误修复。
尝试充分利用两个世界：
在这种情况下，您可能希望标记图片的主要版本，它们应来自Dockerfiles。由于基于标记版本的提交，您可以提供持续集成版本。这减轻了Dockerfiles和分层提交方案的优点和不便。在这里，关键是你永远不会通过限制你允许对它们进行的提交来停止跟踪你的图像。
所以我想这取决于你的情况，你可能不应该试图找到一个规则。但是，无论解决方案如何，都应该有一些真正应该避免的死胡同（最终会出现“黄金图像”情景）。