容器化（Docker）将取代持续集成？

或者换句话说， “图像”是否击败了“脚本”？

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

但是，我对“形象”跳动“脚本”有以下经验：

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

所以，我没有那样做。 相反，我要求testingAWS和Google Cloud Platform ;-)然后，我安装了一个虚拟机，包含我想要发布的软件，以及一个无客户端（HTML5）远程桌面网关（例如Guacamole ），我已经它的形象 。

那么，当一个同事需要尝试的时候，我可以根据这个镜像创build一个新的VM实例，完成！ 创buildVM需要花费时间（<30秒），没有安装脚本，没有部署！

“形象”赢得了“剧本”。

现在，我正在想象在我们的DevOps团队中做同样的“捷径”。 开发人员可能会提供一个随时可以运行的容器，而不是一个随时可以build立的源代码。 没有？

而且，为什么不进一步……为什么不用一小群选定的用户来testing（系统地）在生产中？ 如果我有可以并行运行的版本容器 – 稳定版本和全新版本的容器 – 如果我只能将用户的有限（select）子集“redirect到”新的版本…我是否仍然需要内部testing阶段，这 – 不 – 不真的工作？

这有道理吗？ 或者，我错过了什么？

Answer 1

你所缺less的是Docker镜像只能在Linux 3.10+内核中运行。
该内核级别并不总是在实际的生产服务器中看到。

目前正在运行的大部分LTS（长期支持）发行版都是基于2.6或3.0内核的RedHat或Suse。 最新的版本是3.1+，但仍然由我们的IT Unix团队validation。

当然，这只适用于在Linux上运行的程序。 也许Solaris（尽pipe它有自己的带有全局/本地区域的包含系统）。
还没有Windows。

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

结论：它不会取代，但可以补充configuration项，因为它（基于Docker的configuration项）涉及到自己的一套要求。

Answer 2

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

集装箱化和CI的用途和目标是相当正交/不相关的 – 当你不做某事时，很难取代某些东西;）

Containerisation技术在最好的情况下可以被看作是一种可能的方式，只对某些types的testing进行testing。

目前并不是所有的构build/testing环境都是可以容纳的 – 目前还没有通用容器技术（能够在容器中运行任何软件/固件）。

一些CI系统可能涉及多个validation步骤，这些步骤不一定适合于单个容器。 虽然集装箱化可能对CI执行特定的validation步骤有帮助/发挥作用，但CI /脚本将继续存在于集装箱外部/上方，即使只是为了跨多个集装箱协调validation步骤。

做“图像”击败“脚本”？

不要 – 没有脚本的图像不能存在;）

切换到更具体的子问题…

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

开发人员提供的准备运行的容器？ 在这样一个容器的testing中，“PASS”将如何与“但是在我的工作空间中build立好”的争论呢？

同样，一个新的集装箱与稳定的集装箱并行分段testing的成功结果是什么意思呢？ 没有什么比一些（<100％）的信心水平，当这些变化最终被整合到分支中时，它不会导致破坏（无论如何需要“准备好的源代码” BTW）。

以防万一，这不是一个明确的限制 – 这是一个基于集装箱的testing的具体限制，只是validation隔离是如何工作的（基于脚本或图片的，这并不重要） – 结果并不意味着太多 – 他们可以很容易当代码实际上集成到分支中时，可以采取另一种方式。

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