容器是如何让“一切都是代码”成为现实的
现代应用的发展在很大程度上要归功于DevOps运动的蓬勃兴起以及该运动所产生的各种自动化工具。和以往只单纯编写代码不同，开发人员如今需要考虑需要采用哪些工具，以及如何将这些工具组合起来，以便将最初的设想转变成活生生的应用。
而容器便是这种新工作流程中最重要的新工具之一。像Docker这样的新技术可以让我们捕捉到关键的服务，并将它们从底层基础设施中抽象出来。利用这种方法，我们可以重新思考如何部署应用，如何更好地发挥云基础设施的作用。
满汉全席
亚马逊近日在伦敦举办了一场用户大会，一位AWS用户描述了他的团队处理应用更新的过程，他们不再只是简单地推送一段修改后的代码，而是将“完整的基础设施”的构建过程输出给自己的客户。
一旦基础设施部署并测试完毕后便可在DNS上做切换，使其成为一个活的系统。而在其他方面，这种方法还可在运营新系统的头几天中将旧的虚拟基础设施作成备份，然后再根据需要删除之。
这样一种输送完整的基础设施的想法最初看起来似乎很荒唐，但是当你要考虑云部署的经济性时，这种方法显然要比推送更新更节约成本。它意味着你正在部署的是一个已经就绪的状态，不仅更新的服务器和服务可能已经运行了一段时间，而且连操作系统或软件都已自动更新了。
这种办法无须投资硬件。对开发、测试和生产都使用同样的云平台，需要做的只是为每种环境分配不同的虚拟网络，再加上适当的访问控制即可。你甚至可以在开发中使用生产数据，在需要清理数据时简单地克隆存储即可。
包罗万象的容器
将应用集装在Docker中，会更便于从基础设施中抽象出关键的应用元素。用这种方式处理软件，也能让DevOps充分发挥作用，更易于随着不断变化的需求对服务加以扩展。在容器中包装一个Node.js/Seneca微服务启用，便可在同一台主机或新的虚机上快速部署新的实例。
这种方法产生了一种有趣的DevOps模式：即等幂容器(idempotent container)。这种方法不是把一个应用或服务当成构建的终点，而是构建一个包含了应用、服务以及所有相关联要素的容器。任何时候只要一作出改变，就可构建一个新的容器;测试和部署容器时将其视为一个整体，而不是其中的任何单独元素。这种方法非常有意义，因为它能免除掉一般开发流程的某些弊病。在传统的开发模式中，我们很容易走捷径，只测试变化部分，而不去考虑整体。
一个容器一旦构建并部署完毕，就不会发生变化，除非又有新的容器在部署。由于一个容器就是一个沙盒，因此要想与其中的内容进行交互就得通过 API或者容器自带的UI。这使得容器成了微服务的一个理想的抽象，该服务的API是唯一的接触点。最好是将API定义为各DevOps团队之间的一份合同，如此一来，在小型服务器实例如CoreOS或微软新的Nano Server上运行的容器就会成为一种标准的基础设施构建模块。
跟着工作流走
所以，当我们看到Jenkins构建带有对Docker支持的管道工具时就不会吃惊了。Jenkins已经成了很多构建流程的标准构建工具，其定制化模块架构使其易于对特定的工作流进行调谐，易于和源代码控制工具以及开发和测试平台进行集成。
作为Cloudbees的CTO和Jenkins项目的创始人，Kohsuke Kawaguchi在一次会议上说，给Jenkins增加对Docker的支持非常合理：“这样会促进业界对Jenkins的需求，将Docker视为一种可执行的打包格式。你可以编译并打包成一个二进制对象，然后运行，不再需要的时候直接处理掉就行。”
从Kawaguchi的说法中我们显然可以看出，Docker和其他的容器格式很符合Jenkins的Cloudbees版本，“你可将其用于测试，或用于生产。测试通不过的话(+微信关注网络世界)，就重构一个容器。可将代码编译成一个模块，就像Ruby一样，然后放进容器中，发送给 Puppet用于部署。”
此种做法作为整体DevOps战略的组成部分是有道理的，其中的一切，从基础设施往下都是代码。正如Kawaguchi所言，一切都是代码，“而Git和Jenkins就是砸代码钉子的锤子。”
虽然Docker的文件格式对于容器圈来说几乎已成了通用格式，但我们最好还是要观察一下Linux基金会所赞助的一个通用、开放的容器格式的进展。这一倡议把很多容器开发人员和厂商(包括微软等)聚拢到了一起。一旦一种通用格式获得业界的广泛支持，我们便能向多个云厂商(公有云 [注] 和私有云 [注] )提供容器了。
通用容器格式不可能解决管理不同云基础设施定义而遇到的所有问题。但它肯定会让各厂商之间，如Azure和AWS之间，或者 OpenStack和谷歌云之间转移服务变得更加容易。同样地，利用Puppet或Chef所描述的基础设施，或者Git库所管理的基础设施，我们就可能开发出一个转换层，为应用生成通用的虚机和网络描述，为各个云厂商提供适当的编排功能。