如今,Docker 和容器将要改变世界,早已不是什么秘密了。对于一些深度用户,这种改变已经发生了。不过你造吗?和很多其他改变世界的事物一样,这些事物在彻底改变世界之前总是缺少点什么。但现在什么都不缺了!
![Docker1.12](https://i-blog.csdnimg.cn/blog_migrate/389ac5596898b1ca32d92eaa35883c1f.png)
一言以蔽之……编排。
Docker 实在是太酷了——我指的是那些能改变游戏规则的技术。这些黑科技能给企业带来方方面面的巨大效益,随便列举几个:市场周期、稳定性、灵活性,还有资源利用率。
不过与此同时,容器的规模化管理,一直是个棘手的难题。在以前,我们不得抓取 Docker Swarm,Kubernates,或者 Mesosphere DCOS 这类外部工具,把它们放置在容器之上,以此来管理大规模的容器。虽然说够用,但并不完美。
而不完美的原因是很复杂的。每一种外部工具都会给工作横生枝节,如果你想“安全”地把事情做完,这些枝节会带来很大的麻烦——搞得安全性只是一种“选项”似的。
总之,在我看来有三点主要的问题:
1、部署和管理规模化的基础设施(如 Docker 引擎)
2、部署和管理规模化的应用(如容器)
3、安全地完成上述两件事
之前说过,现在不缺了,因为 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 想要发展出一种合作性的行业生态,行业自己也希望凭己之力,不断改变世界,创造价值。
所以在我看来,尽管冲击的力度很大,但这是一次对行业自后向前的积极冲击,而绝对不是从前往后的消极冲击。
本文转载地址:https://www.linuxprobe.com/docker-game.html