Docker的步伐:DevOps与OS化

Posted CSDN

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Docker的步伐:DevOps与OS化相关的知识,希望对你有一定的参考价值。

过去十年云计算的发展,在 IT 领域为共享经济提供了新的机遇;而过去五年移动互联网的兴起,更是在诸多方面给 IT 架构提出了新的挑战。新的挑战,新的机遇,同时也意味着新的活力。一时间, Docker 、微服务、 DevOps 以及精益研发等新词汇,在较短的时间内,即充斥着整个 IT 行业。基础设施领域,巨头的垄断,以及技术壁垒的存在,往往会限制入局者,也让后来者望而却步。面对业务需求的不断演进,软件提供商的应对能力如何,在机遇面前同样接受考验。


往往是时代的领航者,首先嗅探到历史变革前的酝酿。我们大致看到:对的时机,新的思想总显得有些俏皮,同时还不失冒进。思想背后,我们也总能发现:有些公司进行着那些惊为天人的尝试,他们激进,他们开拓,他们从0到1。其中,Docker 这家公司的发展,我认为不得不浓墨重笔。


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


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


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

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

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


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


  • 推进 DevOps 进程

  • 管理能力迈向 OS 化


Docker 推进 DevOps


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


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


作者介绍:孙宏亮, DaoCloud 技术合伙人,主要负责 DaoCloud 企业级容器云平台的研发。对系统 Docker 化与微服务架构有丰富的经验,目前已出版《 Docker 源码分析》一书。本文由DaoCloud授权转载。




想了解更多关于Docker的内容,请扫描Docker 知识库二维码:


以上是关于Docker的步伐:DevOps与OS化的主要内容,如果未能解决你的问题,请参考以下文章

什么是微服务?如何实现DevOps?

Docker简介与安装

Docke连载:第三章:Docker的使用

devops持续集成开发——jenkins流水线发布一个docker harbor仓库版的后端maven项目

devops持续集成开发——jenkins流水线发布一个docker harbor仓库版的后端maven项目

Azure Devops上模版化K8s部署