Docker 的步伐：DevOps 与 OS 化

如果说依旧以软件构建、CI / CD 等来介绍 Docker 带来的 DevOps 价值，那未免有些老生常谈。如果关注 Docker 最新动态，你不会错过 Docker 原生集成编排的爆炸性新闻。当时 DockerCon 2016 发布此消息之后，坊间关于编排之争、容器生态分裂等传言与猜测甚嚣尘上。而在我看来，编排只是一种形式， Docker 所期望的 DevOps 程度远不止如此，目前的动作实际上也不止于此。

原生集成编排

Docker 推出 Swarmkit，原生集成编排能力的新闻，我相信对其他以容器编排为目标的分布式平台（比如 Kubernetes，Mesos＋Marathon 等）而言，是一个不太友好的消息。一个工具，一个厂商，凭借在容器生态中拥有大量的用户群体，釜底抽薪，拦截了北向生态。乍一看，的确如此，但如果从 DevOps 的角度重新看待这个问题，也许大家会有不一样的收获。

DevOps 是一种新的文化理念，在其驱使之下，践行 DevOps 带来价值的大与小，世人一般很难衡量，往往只是与现有固化流程作简单对比。PaaS 领域，人们习惯于将 DevOps 联系进来，而且从效果来看，PaaS 的存在的确大大简化了传统运维人员对于应用发布后的管理，因此类似于 Kubernetes 等平台也确确实实受到传统运维人员的追捧，释放运维似乎看到曙光。

然而，回到 DevOps，这一词的存在，受益者可绝不止是 “ 运维人员 ” 。对于开发人员而言，同样存在价值。或许有人言：那岂不是意味着开发人员会承担更多的活，去涉及运维的脏活、苦活、累活呢？如果是传统的 IT 架构，缺乏足够的工具辅佐，恐怕是如此，或者 DevOps 寸步难行。

而如今，在 Docker 的世界中，很多事情似乎变的足够简单。在解决了网络、存储、安全等问题之后，Docker 的 Swarmkit 帮助 Docker 大大降低了用户使用容器，践行 DevOps 的门槛。至今为止，大部分企业内部的软件交付，往往会涉及三个部门：开发、测试、运维，三者缺一不可。Docker 的思路比想象中的要简单很多，力求在工具层面做到最简约，仅仅通过 Docker 一款工具就可以完成开发、测试、运维等绝大部分工作。如果仅仅在开发者占用的仅有资源中，Docker 即可以提供完备的 “ End-to-End ” 的工具链，那工程师完全可以轻松胜任 DevOps 角色。开发工程师，在开发过程中融入运维的理念，借助 Docker 工具的威力，走通软件生命周期的全流程。Docker 带来的开发部署等环节的环境一致性、编排功能的完备性，势必大大降低团队内部的沟通成本和资源开销。我想企业内部在做IT决策时，如此明显的价值导向不可能视而不见。

DevOps 自始至终都没有局限在 PaaS 的运行时，相比运维庞大的 PaaS 平台来解放应用运维的能力，是否会存在本末倒置，一切都还在未可知，至少 Docker 这种轻量级，最便利的一体化方式给 DevOps 提供了一种新的思路。

开发驱动监控

Docker 以轻巧的方式，实现了用户对于编排的需求。表象似乎很光鲜，但是我们不妨对目前普遍的编排进一步的思考。是否会发现，类似于 Kubernetes 与 Swarmkit 的编排着重于应用的运行时管理，如果仅限于运行时，仅限于应用运维，缺乏开发端源头的输入，开发与运维的鸿沟依然赫然在目，一分不少，丝毫无改观。

传统的 PaaS 平台，比如 Cloud Foundry，OpenShift，可以基本做到管理应用的运行。然而，应用的生命周期往往比这更复杂，随后的监控、协调、调度、故障恢复等都是需要克服的难题。而这些在传统企业内部，毫无疑问都是运维的差事，出了问题还毫无避免的追溯开发人员。如果此时，在拥有传统 PaaS 的背景下，一款软件的生命周期中，可以更多的受 DevOps 文化影响，那可以大大减少很多成本。举一个简单的例子，在传统 PaaS 以及容器编排平台中，对于应用的监控往往很难做到放之四海皆准。对于一些应用而言，平台通用的监控不是粒度太大，犹如隔靴搔痒，就是提供的细粒度监控并不针对用户的痛点，显得南辕北辙。运维人员在设计监控的时候，根本无法通过通用的方式完成应用的 “ 个性化 ” 需求，因此，权衡诞生，取舍难免。

如果关注最新的 Docker 1.12，细心的人可能会发现：

Dockerfile 开始支持新命令 HEALTHCHECK，完成用户指定的应用健康检查

Docker 的此举，看似不经意，实则平地见惊雷，一举弥合了开发与运维的鸿沟，至少在应用监控领域。Docker 大大释放了运维人员的压力，但是企业切入 Docker 的第一步还是 Docker 化，也就是 Dockerfile，这一环节自然是开发者的范畴。另外，对于应用的个性化监控，我想没人比应用的开发者更清楚，如果由应用开发者来承担，来完成这部分的定义，完全是件皆大欢喜的事。从此，开发环节即完成应用自定义监控的定义, 通过 Docker 提供的统一的架构完成监控，运维环节的监控将不再那么捉襟见肘。

可以说，Docker 1.12 开始，它为应用监控提供了新的契机，弥合开发与运维的鸿沟，打通了两者的任督二脉，这往往是传统的 PaaS 平台，容器编排平台无法企及的。

Kubernetes 、Mesos 等平台诞生之后，回顾过去的一到两年，仿佛整个生态的潜意识都有着一个潜意识：容器生态分为两层，容器引擎的 Docker 作为管理工具，作为底层，单纯服务于容器；编排平台的 Kubernetes 或者 Mesos，作为上层，满足应用编排的各种需求。笔者也一度认为 Docker 势必将往上层走，卧榻之侧，岂容他人鼾睡。然而，Docker 的举动却令人大吃一惊，采取的策略则是：Docker 迈向 OS 化。

自从 libnetwork 诞生，Docker 似乎就传递着一种信息：无心借力第三方工具，借助内核借力打力。

Docker 风靡至今，面对传统的资源管理方式，至今仍有未解之谜。如果说，Docker 暂且借助内核的 VxLan 能力，缓解或解决了 Docker 容器世界的网络难题，那么企业内部架构中仍有问题存在，比如存储，比如负载均衡等。问题固然要解决，不过反观近年来企业应用的发展史，在选择底层软硬基础设施时，往往较信任更为基础的操作系统（Operating System，OS），在与上层云平台的磨合过程中，多多少少存在水土不服。因此，Docker 管理能力迈向 OS 化，也不难理解。容器未来的方向很有可能打破传统 IaaS 与 PaaS 的界限，回到广义云 OS 层面的变革中。

全局存储

对于应用而言，数据的重要性不言而喻。计算与存储分离，一直是 Docker 最希望的数据管理方式，而对于存储的统一化管理，Docker 一直没有给出令人信服的解决方案，反而是生态中类似于 ClusterHQ，HedVig 等公司一致在该领域深耕。不过，这也不能苛责 Docker，这毕竟不是 Docker 的强项与主营业务。

Docker 不可能封闭容器生态的存储市场，这方面的努力，我们从 Docker 抽象存储概念即可看出（ Docker 诞生，只存在容器和镜像这两个一级概念，而随着时间的发展，Docker 另外抽象出存储卷（ Volume ）以及网络，作为一级概念，并行管理 ）。

经历了过去 3 年多单机化的存储卷，如今 Docker 1.12 推出全局的存储卷，原生支持集群环境中的数据卷共享。在加上 DockerCon 2016 上，Docker 官方演示借助 NFS，集群环境中管理分布式数据。容器生态有理由推测，Docker 在存储领域并非视而不见，而是非常有可能借助操作系统 OS 的能力，切入存储生态。

IPVS 负载均衡

如今，大多数企业级的应用，不再是仅拥有单个实例。多实例的现状常常可以避免很多问题，比如单点问题，负载的均衡问题等。而 Docker 的世界中，容器的扩展一直以来不是一个新话题。对于扩展出来的应用容器，服务的注册以及发现由谁来完成，一直没有一个定论。而 Kubernetes 等平台则是为此专门引入一个平台路由组件完成这部分工作。由于 Docker 的网络模式与平台路由组件在协作时，或多或少会存在水土不服，性能等方面的损耗，因此很难达到 ” 1+1>2 ” 的效果。

新版本的 Docker 1.12，编排应用时，可以直接使用 Linux IPVS 完成服务的注册以及负载均衡。或许，这一举措直接带来的好处将是：

• 借助内核能力，无需额外配置、部署及管理
• 大幅提高负载均衡的性能
• 原生支持多种传输协议的负载均衡能力（ TCP，SCTP, UDP 等 ）

大道至简，如果诸如 Linux 内核等底层技术栈，本身可以提供负载均衡的管理能力，运维人员没有理由再去额外安装一个负载均衡模块，昂贵的配置、管理、运营成本是团队决策者不得不考虑的点。另外，比起 Nginx / HAProxy , IPVS 还在多个层面存在优势：比如 UDP 的支持，多样的负载均衡策略，以及健康检查等。

全新的领域，用“探索”来形容现在的 Docker，我认为最合适不过。着眼全球的软件交付，Docker 对于 DevOps 理念的贡献，可谓不可小觑。而面对云计算领域的基础设施以及平台架构，Docker 的思路也许会更倾向于 OS 化，逐渐走向 Cloud OS 。然而，Docker 作为目前全球最炙手可热的创业公司，百般眼光以及多样的揣测，都会聚集于这条不乏趣味的鲸鱼身上。未来如何，我们拭目以待。