Docker 的步伐:DevOps 与 OS 化

2016-08-09 09:28:00
孙宏亮
转贴:
36kr
11994

目前为止,历史给了 Docker 三年多的时间。这三年中,Docker 自始至终将 " Build , Ship , Run "当作公司的宗旨,也就是帮助用户完成任意应用的构建、发布与运行。

Docker 的步伐:DevOps 与 OS 化

通过总结 Docker 的三年,我们不难发现 Docker 的步伐:

  • 第一年,专注软件构建,对接构建下游,营造镜像生态

  • 第二年,服务容器管理,发布调度平台,打造交付流程

  • 第三年,整合企业资源,完善平台功能,着手应用编排

如今,在这第四年过半之际,再去解读 Docker,我们会发现,Docker 的发展似乎除了重视应用的 " Build , Ship , Run " 之外,另外还在两个领域的努力有点“欲盖弥彰”:

  • 推进 DevOps 进程

  • 管理能力迈向 OS 化

Docker 推进 DevOps

DevOps 在 IT 领域是一种强调开发团队、运维团队以及其他团队之间增强协作与沟通,以达到软件产品快速成熟以及安全可控的文化。从 Docker 的宗旨来看,DevOps 的理念似乎非常匹配,Docker 完全有能力来加速、保障软件的生命周期。而从这几年的行业发展来看,Docker 作为一款工具,的确在帮助企业践行 DevOps 理念,同时也借助这款工具的打磨,通过可视价值在更大的群体中推广 DevOps 。

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 平台,容器编排平台无法企及的。

Docker 迈向 OS 化

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 作为目前全球最炙手可热的创业公司,百般眼光以及多样的揣测,都会聚集于这条不乏趣味的鲸鱼身上。未来如何,我们拭目以待。

发表评论
零 减 肆 =
评论通过审核后显示。
文章分类
联系方式
联系人: 王春生
Email: chunsheng@cnezsoft.com