共计 1792 个字符，预计需要花费 5 分钟才能阅读完成。
| 导读 | 如今，Docker 和容器将要改变世界，早已不是什么秘密了。对于一些深度用户，这种改变已经发生了。不过你造吗？和很多其他改变世界的事物一样，这些事物在彻底改变世界之前总是缺少点什么。但现在什么都不缺了！ |
一言以蔽之……编排。
Docker 实在是太酷了——我指的是那些能改变游戏规则的技术。这些黑科技能给企业带来方方面面的巨大效益，随便列举几个：市场周期、稳定性、灵活性 ，还有 资源利用率。
不过与此同时，容器的规模化管理，一直是个棘手的难题。在以前，我们不得抓取 Docker Swarm，Kubernates，或者 Mesosphere DCOS 这类外部工具，把它们放置在容器之上，以此来管理大规模的容器。虽然说够用，但并不完美。
而不完美的原因是很复杂的。每一种外部工具都会给工作横生枝节，如果你想“安全”地把事情做完，这些枝节会带来很大的麻烦——搞得安全性只是一种“选项”似的。
总之，在我看来有三点主要的问题：
之前说过，现在不缺了，因为 Docker 1.12 来了，首先是 Swarm 模式！
解决第一个问题，Docker 1.12 使用了一种名为 Swarm Mode 的全新的工作模式。在这一模式下，Docker 引擎会自动连接到一起，成规模地组队工作。这支队伍被叫做 swarm，安全性方面不用担心——每个 swarm 都是默认安全的！绝不瞎说。
还有，swarm 的创建和管理也异常的简单。要配置一个全新的，受到 TLS 协议和安全密钥保护的 Swarm，只需要两条命令！而这些事情，放到以前，绝对能把你折腾死，白白浪费大量的时间、精力和金钱。相信我，我这么干过，而且绝对不想再干了。而 Swarm Mode 只需要两条傻瓜式命令就能做到这一切！
关于 Swarm 模式，另一个不得不提的事情就是引入 services。
在引入 services 之前，我们部署的都是独立容器。如果我们手头有一个 App 应用，包含了 5 个组件，那么部署和管理他们将是一项很沉重的工作。要想使之规模化，是很困难的，运行更新和升级的工作也十分枯燥，引入 services 后，这些问题都烟消云散了，有了 services，同样是带有 5 个组件的 App，我们可以把每个组件定义为一个 Docker Service，而且这些全都是声明式的。这也就意味着，我们可以告诉 Docker 说，“嘿，你要保证始终有 5 个容器在支持我的网页前端服务”，然后 Docker 就会哼哧哼哧地保证始终有 5 个容器在支持你的网页前端服务。就算偶尔崩溃了，修复成本也就一美元！
但这还不是 services 的全部。你是想得到一次需求高峰，还是预测一次需求高峰？要快速测量你的 service，只需要一个简单命令即可，升级也是件手到擒来的事。想要给你 service 使用中的图像换个版本？跟逛公园似的！一个简单的命令下去，你的 service 就升级到最新版本了，而同样是这道简单的命令，还能把升级变成 无缝升级（rolling update）。举个例子，拿一个带有 200 个容器的service，20 个容器一批，每次同时升级一批，然后在每一批的间隙等待 15 分钟。
说真的，这玩意儿太简单了，连我都能用！
我实在看不出来，如果这都不能改变游戏规则，那还有什么是可以的。它解决了大规模普及 Docker 的最大技术障碍！它很安全，可以规模化，而且很简单。这么好的东西，有谁不想要呢？这算不算是对现今行业环境的冲击？当然算是，不过且听我说明，我认为这次冲击是自后向前的，而不是自前向后的！
两者有什么区别呢？自后向前的冲击，是对这个行业的推动。它甩掉了行业的很多包袱（比如操作者的天赋差异，比如大规模生产的瓶颈），让一切变得 简单化 、 规模化，从而推动整个行业的正向发展，而且，这个行业也并非不期待出现 Docker 公司这样的生力军。毕竟，就像 Docker 想要发展出一种合作性的行业生态，行业自己也希望凭己之力，不断改变世界，创造价值。
所以在我看来，尽管冲击的力度很大，但这是一次对行业自后向前的积极冲击，而绝对不是从前往后的消极冲击。
