或者，换句话说，“图像”会击败“剧本”吗？
我是Docker故事的新手，不幸的是我目前正在CI尚未成为现实的环境中工作;-P
但是，我在“图像”击败“剧本”方面有以下经验：
如果我想为某些同事分发（甚至仅用于探索/培训目的）（桌面）应用程序，我必须经历漫长而昂贵的过程，从而导致安装脚本用于在工作站上安装的软件。最终结果是脚本需要相当长的时间才能执行，并且由于狗狗的上下文变化而可能会失败。
所以，我没有这样做。相反，我已经要求测试AWS和Google Cloud Platform ;-)然后，我安装了一个虚拟机，其中包含我想要分发的软件，以及一个无客户端（HTML5）远程桌面网关（例如Guacamole），我已经采用了图像。
然后，当一位同事需要尝试时，我可以根据图像创建一个新的VM实例并完成！创建VM需要花费时间（<30秒），没有安装脚本，没有部署任何东西！
“形象”赢得了“剧本”。
现在，我想象在DevOps团队中做同样的“捷径”。开发人员可能会提供一个可立即运行的容器，而不是一个可以构建的源代码。否？
而且，为什么不进一步...为什么不在生产中使用细分的一小组选定用户进行（系统地）测试？如果我有版本化的容器可以并行运行 - 稳定的容器和全新的容器 - 如果我能“重定向”我的用户的有限（选择）子集到新的...我还需要这个吗？内部测试相位这此结果未真正工作？
这有意义吗？或者，我错过了什么？
答案 0 :(得分：1)
您缺少的是Docker镜像只能在Linux 3.10+内核中运行 在实际的生产服务器中并不总能看到该内核级别。
目前在生产中运行的大多数LTS（长期支持）发行版都是RedHat或Suse，它们仍然基于2.6或3.0内核。最新版本为3.1+，但仍由我们的IT Unix团队验证。
当然，这仅适用于在Linux上运行的程序。也许是Solaris（尽管它有自己的包含全局/本地区域的包含系统） 还不是Windows。
最后，CI的目标是持续部署靠近生产环境的图像。如果您的产品正在运行Suse发行版，那么您还没有Suse图像（仅限OpenSuse 13+）。因此，您可能无法在映像中实现完全与实际生产服务器相同的环境。
结论：它不会被替换，但可以补充CI，因为它（基于Docker的CI）涉及其自己的一系列要求。
答案 1 :(得分：0)
简短回答，不（恕我直言，至少）。
集装箱运输和CI的用途和目标是相当正交/无关的 - 当你没有做某事正在做的事情时很难取代某些东西;）
对于旨在在可包含环境中执行的软件，Containerisation技术充其量只能被视为仅执行某些类型的测试的可能方式。
并非所有构建/测试环境都可以包含在内 - 没有通用容器技术（能够在容器任何软件/固件中运行）。
某些CI系统可能涉及多个验证步骤，这些步骤不一定适合单个容器。虽然容器化可以帮助/充分利用CI来执行特定的验证步骤，但CI /脚本将继续存在于容器之外/之上，即使只是为了协调跨多个容器的验证步骤。
做＆＃34;图像＆＃34;击败＆＃34;脚本＆＃34;？
不 - 没有脚本，图像就无法存在;）
切换到更具体的子请求......
在你的情况下，＆＃34;图像＆＃34;赢得＆＃34;脚本＆＃34;只有当同事想要在您的容器内容中查看完全时（即您在某个标签上的更改）。无法检查您的更改是否与其他更改集成或在其他标签之上。非常有限（重新）使用恕我直言。
开发人员提供的可立即运行的容器？一个＆＃34; PASS＆＃34;在这样一个容器的测试中，它不同于一个容器，但它在我的工作空间中构建正常。争论？
同样 - 对于一个新容器的分段测试与稳定容器并行测试的成功结果是什么意思？当变化最终被集成到分支中时，它不会超过一些（<100％）的信心，它会导致破坏（为此＆＃34;即将建立的源代码＆ ＃34;无论如何都是必需的，BTW）。
如果不清楚 - 这不是针对基于容器化的测试的特定限制，它只是隔离验证的工作原理（基于脚本或图像，它并不重要） ） - 结果并不是很有意义 - 当代码实际集成到分支中时，它们可以轻松地走另一条路。
CI验证是有意义的，因为它反映了实际集成的代码上下文。