我应该使用Dockerfiles还是图片提交？

Question

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

例如,似乎使用Dockerfiles意味着你不应该真正提交图像,因为你应该只是在git中跟踪Dockerfile并对其进行更改.关于什么是权威的,没有任何歧义.

但是,图像提交似乎非常好.它非常棒,您可以直接修改容器并标记更改以创建另一个图像.我知道你甚至可以从图像提交历史中获得类似文件系统差异的东西.真棒.但是你不应该使用Dockerfiles.否则,如果您进行了图像提交,则必须返回Dockerfile并进行一些更改,以表示您的操作.

所以我被撕裂了.我喜欢图像提交的想法:你不必在Dockerfile中表示你的图像状态 - 你可以直接跟踪它.但是我对放弃某种清单文件的想法感到不安,它可以让你快速了解图像中的内容.看到同一软件包中的两个功能似乎不兼容,这也令人不安.

有没有人对此有任何想法？使用图片提交被认为是不好的做法吗？或者我应该放弃我对Puppet天文件中的清单文件的附件？我该怎么办？

更新:

对于那些认为这是基于意见的问题的人,我不太确定.它有一些主观的特质,但我认为这主要是一个客观的问题.此外,我相信对这个主题的一个很好的讨论将提供信息.

最后,我希望阅读这篇文章的人能够更好地理解Dockerfiles和图像提交如何相互关联.

更新 - 2017/7/18:

我刚刚发现了图片提交的合法用途.我们只是在我们公司设置CI管道,在管道的一个阶段,我们的app测试在容器内运行.我们需要在测试运行程序生成它们之后(在容器的文件系统中)从已退出的容器中检索覆盖结果,并且容器已停止运行.我们使用图像提交来执行此操作,方法是提交已停止的容器以创建新图像,然后运行显示并将coverage文件转储到stdout的命令.这样做很方便.除了这个非常具体的案例,我们使用Dockerfiles来定义我们的环境.

Answer 1

Dockerfiles是一种用于创建图像的工具.

运行的结果docker build .是带有提交的图像,因此无法在不创建提交的情况下使用Dockerfile.问题是,每当有任何变化时你应该手动更新图像,从而使自己陷入金色图像的诅咒之中吗？

黄金形象的诅咒是一个可怕的诅咒,对于那些必须继续生活在一个安全漏洞的基础图像来运行他们的软件的人来说,因为创造它的人很久以前就被古代人所吞噬(或者转移到了新工作)并且没有人知道他们在哪里获得了进入该图像的imagemagic版本.并且是唯一可以链接到三年前老板的儿子雇用的顾问提供的c ++模块,无论如何它并不重要,因为即使你弄清楚imagemagic来自libstdc ++的版本所使用的JNI在支持工具中调用了创建长发的实习生,无论如何都只存在于不受支持的ubuntu版本中.

Answer 2

了解解决方案的优点和不便是一个良好的开端.因为两者的混合可能是一种有效的方法.

骗局:避免黄金形象死胡同:

如果您忘记了如何重建图像,那么仅使用提交是很糟糕的.您不希望处于无法重建映像的状态.这个最终状态在这里称为黄金图像,因为图像将是您唯一的参考,每个阶段的起点和终点.如果你松开它,你将遇到很多麻烦,因为你无法重建它.致命的死胡同是,有一天你需要重建一个新的(因为所有的系统库都已经过时了),你将不知道要安装什么......结束了大量的时间损失.

作为旁注,如果历史日志可以很容易地使用(参考差异,并在其他图像上重复它们),那么使用提交提交会更好,因为它在git中:你会发现git没有这种困境.

亲:光滑的升级分发

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

尝试充分利用两个世界:

在这些类型的场景中,您可能希望标记图像的主要版本,它们应该来自Dockerfiles.由于基于标记版本的提交,您可以提供持续集成版本.这减轻了Dockerfiles和分层提交方案的优点和不便.在这里,关键是你永远不会通过限制你允许对它们进行的提交次数来停止跟踪你的图像.

所以我想这取决于你的情况,你可能不应该试图找到一个规则.然而,可能会有一些真正的死角你应该避免(如"金像"的场景结束了)什么解决方案.