容器化（Docker）会取代持续集成吗？答案

【问题标题】：Will Containerization (Docker) replace Continuous Integration?容器化（Docker）会取代持续集成吗？
【发布时间】：2016-02-20 15:33:29
【问题描述】：

或者，换句话说，“图像”胜过“脚本”吗？

我是 Docker 故事的新手，不幸的是，我目前在 CI 尚未成为现实的环境中工作；-P

但是，我在“图像”击败“脚本”方面有以下经验：

如果我想为我的一些同事分发（即使只是出于探索/培训目的）（桌面）应用程序，我必须经历一个漫长而昂贵的过程，从而产生一个安装脚本用于安装在工作站上的软件。最终结果是脚本需要相当长的时间来执行，并且可能会由于狗狗上下文的变化而失败。

所以，我没有那样做。相反，我要求测试 AWS 和 Google Cloud Platform ;-) 然后，我安装了一个带有我想要分发的软件的虚拟机，以及一个无客户端 (HTML5) 远程桌面网关（例如Guacamole），然后我为它拍摄了图像。

那么，当同事需要尝试时，我可以根据图像创建一个新的 VM 实例，它就完成了！创建虚拟机需要时间（

“形象”战胜了“剧本”。

现在，我想在我们的 DevOps 团队中做同样的“捷径”。开发人员可能会交付一个可以运行的容器，而不是一个可以构建的源代码。没有？

而且，为什么不走得更远……为什么不在 PRODUCTION 中对一小部分选定的用户进行（系统地）测试？如果我有可以并行运行的版本化容器 - 稳定的容器和全新的容器 - 如果我只能将有限（选择的）用户子集“重定向”到新的......我还需要这个吗内部测试阶段哪个不真正起作用？

这有意义吗？或者，我错过了什么？

【问题讨论】：

【解决方案1】：

您缺少的是 Docker 映像只能在 Linux 3.10+ 内核中运行。
在实际的生产服务器中并不总是可以看到该内核级别。

目前在生产中运行的大多数 LTS（长期支持）发行版都是 RedHat 或 Suse，它们仍然基于 2.6 或 3.0 内核。最新版本是 3.1+，但仍在由我们的 IT Unix 团队进行验证。

当然，这仅适用于在 Linux 上运行的程序。也许是 Solaris（尽管它有自己的包含全局/本地区域的容器化系统）。
还不是 Windows。

最后，CI 的目标是持续部署接近生产环境的映像。如果您的 prod 正在运行 Suse 发行版，那么您还没有 Suse 映像（仅 OpenSuse 13+）。因此，您可能无法在图像中实现与实际生产服务器的环境完全相同相同的环境。

结论：它不会替代 CI，但可以补充 CI，因为它（基于 Docker 的 CI）涉及自己的一组要求。

【讨论】：

【解决方案2】：

简短的回答，不（至少恕我直言）。

容器化和 CI 的用途和目标相当正交/不相关 - 当你不做某事正在做的事情时，很难替换某事；）

对于打算在可包含环境中执行的软件，容器化技术充其量只能被视为执行某些类型测试的一种可能方式。

目前并非所有构建/测试环境都是可包含的 - 没有通用容器技术（能够在容器任何软件/固件中运行）。

某些 CI 系统可能涉及多个验证步骤，这些步骤不一定适合单个容器。虽然容器化可能有助于/很好地配合 CI 执行特定的验证步骤，但 CI/脚本将继续存在于容器之外/之上，即使只是为了跨多个容器协调验证步骤。

“图像”胜过“脚本”吗？

不——没有脚本，图像就无法存在；）

切换到更具体的子问题...

在您的情况下，只有当同事想要准确地查看您的容器内容（即您在某个标签上的更改）时，“图像”才会胜过“脚本”。无法检查您的更改是否与其他更改集成在一起或在其他标签之上。非常有限（重新）使用恕我直言。

开发人员提供的即用型容器？这种容器的测试中的“PASS”与“但它在我的工作区中构建良好”的论点有何不同？

类似地，新容器与稳定容器并排进行分段测试的成功结果意味着什么？只不过是一些（

以防万一 - 这不是特定于基于容器的测试的限制，它只是隔离验证的工作方式（基于脚本或图像，没关系） - 结果并不意味着太多 -当代码实际集成到分支中时，他们可以轻松地采用另一种方式。

CI 验证是有意义的，因为它反映了实际集成的代码上下文。

【讨论】：