得先了解配置管理和持续部署工具的演变，便于更清晰直观看到Docker殴打传统持续交付的场景 - Girish Shilamkar

21世纪的第1个10年是一段有趣的光辉岁月，当时很多组织机构正着眼于基础设施自动化的发展以及在不断搭建持续集成/交付的体系。当时Chef（成立于2008年）和Puppet Labs（成立于2005年）在基础设施自动化早期的演变阶段独领风骚。

虽然Jenkins出来有一些岁月了，但较于持续集成，它在持续交付方面倒是发展得晚一些，不过并不影响它的广泛应用。Jez Humble在2010年出版的《持续交付》像一本行业圣经，你可以清楚看到企业级CD工具的兴起。

比如前几年，考虑到IBM在2013年收购UrbanCode平台，CA于2013年收购了Nolio，Xebia Labs在2008年成立……等等都彰显这是PaaS平台崛起的时代。不过，后面发生可一件有趣的事：CloudFoundry，GAE App Engine，DotCloud，Heroku以及更多组织机构联合起来却在提升交付效率上撞了一鼻子灰。

俗话说，命中有时终会有。2013年，并行发展（parallel development）横空出世并KO了IBM和CA等一票玩家。这个历史进程极其重要，它彻底改变了软件开发和部署方式。

没错，就是Docker元年。从那时起，经过几年摸索，容器成了今天部署应用的公认方式。（其实我觉得，像Kubernetes，Mesos和Swarm这样的项目正在领跑规模化运营新规则）

基于CD pipelines的配置管理跑Nolio设计的Chef cookbooks / Puppet模块和工作流程会怎么样？这是我们要在文章中更深层次了解的一些疑问。

配置管理和持续部署工具的演进

对于部署任何的应用，都有两件事至关重要：应用代码/运行应用的运行态和平台。

通过基于用户界面（UI）或基于特定语言（LAN）的持续部署（CD）工具和相关配置管理工具提供的底层基础架构解决了各种组件的工作流和编排。

基础设施代码基于一些DSL（领域专用语言），并且将为运行应用程序所需的各种堆栈/运行时编写脚本/手册。只不过相应的，在相当复杂的企业设置中，为给定应用程序设置运行时间所需的脚本/手册数量可能很多。

DevOps：我们支持到位了吗？

根据我们在配置管理项目中的经验，开始和开展统一工作的出发点并不一定能够解决所有问题。我们来看一些具体的例子。

1. 管理依赖关系：现在用于基础架构

配置框架采用DSL语法编写模块，因为它们经常被调用。对于一个相当复杂的企业来说，这些运行手册的数量级很容易跑到几百个，甚至更多。

现在，要组合应用程序，您可能要有多个规范 - 而且管理依赖项及其版本又会变成新的问题。

一些新的解决方案（像Berkshelf）在Chef中管理依赖项，但这意味着要学习和实施另一套工具……自然而然，开发就会有一个陡峭的学习曲线。这也导致一些公司创建了特殊的“DevOps”团队，这对于DevOps本身来说就很“反进化、反直觉”。

2. 基础设施即代码

编写和调试基础设施代码与应用的编程差异很大。论调用难度可能不是很具体公正，但编写基础设施的代码就挑战满满。例如，少了成熟工具、需要很细化的基础设施细粒度知识等…往往就是这些鸡毛蒜皮的小需求，让代码变得亚历山大。而且，诸如失败的依赖应用程序包转储的错误就很具有隐藏性，如果不了解，就像自驾游缺了个地图。

而且经过实践，我发现一个不太好的消息，从头开始设置应用比调试更加明智，尤其是需要快速解决问题的时候。可能这就是所谓重装（置）大法的魅力吧。

到毛线！

基础设施自动化工具的发展确实有助于基础设施实现自助，但并没有解决孤岛问题。且基础设施有一定专业门槛，这意味着至少有部分团队得专门处理基础设施。

问题以转变做事方式（基础架构自动化的DSL）的形式从一个团队转移到另一个团队。但是对于开发一方来说，基础设施仍然是一个难以透彻的地方，但现实逼迫着你不精不行。

在基本层面上，应用程序仍然要打包，因为它依赖这个形式。例如，JAR，Gem或Py包 - 由单独工具和打包格式创建。

大一统的力量：Docker (容器)

容器和Docker的成就之一是应用和基础设施需求的统一包装。无论是本地还是在生产集群上运行的应用程序，都能拥有相同的Docker映像。

使用Docker，应用终于实现自包含，也就是能以简单的声明方式打包应用程序代码以及基础架构依赖。再者从开发人员的角度来看，这个技术既不费力又讨巧。

这么看来，容器几乎是自带光环来到人间，它更加轻巧和分层，使得layers也能被缓存起来。一旦开发完成，它可以简单地将图像推送到注册表。从操作的角度来看，这是一个更简单的格式：不需要运行容器图像所需的长文档或cookbooks……而这所有，你只需要的是一个容器镜像和一些元数据，如环境变量等其他相关的东西。

使用Docker，大量的配置管理代码被Docker镜像和Dockerfiles取代，同时也简化了对应用程序依赖关系的管理，因为无需编写大量的应用配置代码，哪怕这几乎不会出现改变。

从可操作性的角度来看，新操作可以专注于构建一个可以运行容器和管理平台的“地基”。至于创建和维护平台，则可以将配置管理平台跟用于容器的新平台结合使用。这也对Mesos，Kubernetes，Swarm等容器造成一定影响，甚至以及Rancher，OpenShift等容器平台。

Nirvana最后要说什么？

上面说了容器那么厉害，那是不是采用容器之后我们就解决了软件交付的所有问题？那当然不是！但是，我们已经更接近应用的可移植性和自主持续的CD管道，这将真正实现DevOps的目标。

当然，这里也会有一些新挑战，例如怎么在一组大型虚拟机上编排容器？当一个容器短暂转移动到另一个机器时，一个服务怎么样去发现另一个服务？怎么通过容器移动来管理持久存储？

我是一条很美的分割线

想看更多内容，还请添加微信公众号（ID：MornNews，或搜索DevOps研究院）