我对这两个选项有些困惑。它们似乎是相关的。但是,它们并不是真正兼容的。
例如,似乎使用Dockerfiles意味着您实际上不应该提交映像,因为您应该只在git中跟踪Dockerfile并对其进行更改。这样一来,权威性就没有歧义。
但是,图像提交看起来确实不错。太好了,您可以直接修改容器并标记更改以创建另一个图像。我了解您甚至可以从映像提交历史记录中获得类似文件系统差异的信息。太棒了 但是,您不应该使用Dockerfiles。否则,如果提交了映像,则必须返回到Dockerfile并进行一些更改,以表示所做的工作。
所以我很伤心。我喜欢图像提交的想法:您不必在Dockerfile中表示图像状态- 您可以直接对其进行跟踪。但是,我对于放弃某种清单文件的想法感到不安,该清单文件使您可以快速概览图像中的内容。同样在同一软件包中看到两个似乎不兼容的功能也令人不安。
有人对此有任何想法吗?使用图像提交是否被认为是不好的做法?还是我应该放开我的附件来存放人偶时代的清单文件?我该怎么办?
更新 :
对于所有认为这是一个基于意见的问题的人,我不确定。它具有一些主观上的特质,但我认为这主要是一个客观问题。此外,我相信就该主题进行良好的讨论将提供信息。
最后,我希望阅读本文的任何人都能对Dockerfile和映像提交如何相互关联有更好的了解。
更新-2017/7/18 :
我最近才发现图像提交的合法用途。我们只是在公司建立了一条CI管道,在管道的一个阶段中,我们的应用程序测试在容器内运行。在测试运行程序进程在容器的文件系统中生成覆盖结果之后,我们需要从已存在的容器中检索覆盖结果。我们使用图像提交来执行此操作,方法是提交已停止的容器以创建新图像,然后运行显示覆盖文件并将其转储到stdout的命令。所以拥有这个很方便。除了这种非常具体的情况之外,我们还使用Dockerfiles定义我们的环境。
Dockerfiles是用于创建映像的工具。
运行的结果docker build .是带有提交的映像,因此 无法在未创建提交的情况下使用Dockerfile 。问题是,每当发生任何变化,您是否应该手动更新图像,从而 注定自己会 遭受 黄金图像的诅咒 ?
docker build .
黄金图像的诅咒是一个可怕的诅咒,它使人们不得不继续使用漏洞百出的安全漏洞缠身的基础图像来运行其软件,因为创建它的人很久以前就被古代人吞噬(或转移到新工作),没有人知道他们从哪里获得了进入该图像的imagemagic版本。这是唯一可以与老板的儿子三年前雇用的顾问提供的c 模块链接的东西,无论如何都没关系,因为即使您弄清楚了imagemagic来自于libstdc 所使用的版本, JNI在支持工具中称,创建长发的实习生仅存在于不受支持的ubuntu版本中。