线上分享|回顾 DockerCon 2016,编排成主题

本文内容整理自 6 月 28 日晚 8 点在 DaoCloud 技术交流群里由孙宏亮带来的主题为《回顾 DockerCon 2016,编排成主题》的线上分享。

嘉宾介绍:

allen

孙宏亮,毕业于浙江大学,现为 DaoCloud 技术合伙人,在 DaoCloud 主要负责企业级容器云平台的研发工作。数年来一直从事云计算领域,是国内第一批研究和实践 Docker 的工程师,在国内起到重要的 Docker 技术布道作用。目前,拥有个人著作《Docker 源码分析》,同时是 Docker Swarm 项目的全球 Maintainer,并对 Docker 等其他项目有着大量的代码贡献。

线上分享内容:

回顾DockerCon 900500

DockerCon 的主题一向是 Docker 生态的航向灯,此次分享我会带领大家回顾自己在 DockerCon 上的所见所闻。DockerCon,作为全球容器领域影响最大的技术盛会,今日在美国西雅图最豪华的华盛顿州会议中心隆重开幕。不论是开源社区贡献者,还是引领容器潮流的企业界决策者、执行者,全球范围内总共超过 4000 名参会者,在西雅图这片从不缺乏 IT 灵魂的土地上进行着思想的碰撞,共同交流探讨 Docker 技术未来发展的方向,以及 Docker 在工业界切实落地的可行方案。

本次线上分享将围绕三个层面展开:

  • Docker 的生产环境使用现状
  • 自身集成编排,生态走向如何
  • 微服务联姻 Docker,起飞 DockerCon

Docker 的生产环境使用现状

CEO 提纲挈领地介绍了 Docker 公司一直以来的目标——Docker 的大众化:

fenxiang-1

  • 易用性:开发,测试,调试、运维等
  • 移植性:跨平台,多语言,跨系统
  • 社区路线:加大全球参与,扩大 Docker 传播

Docker 公司通过开源的方式在运作着几乎所有的项目,随着社区的活跃,市场的火热,Docker 社区的很多技术都得到了强劲的发展。在走向生产界的一年中,Docker 运营社区,经营公司,在众多领域都有明显的增长指标,这里有令人激动不已的一组数据为证:

1. 全球已有 460,000 个应用的 Docker 化,两年增长 3000%

2. 仅 DockerHub 一方,即有 41 亿次的镜像下载,近半年增长 26 亿次

3. 基于 docker 的孵化项目,同时异军突起,增长迅猛

在生产环境的应用方面,Ben Golub 从 4 个角度介绍了这一点:

fenxiang-2

  • 生产环境中使用 Docker 的比例,已经达到 60%,未来一年还将大幅提高,另外 ClusterHQ 的数据表明,其中有超过 70% 属于有超过 500 员工的大公司
  • Docker 的使用横跨了众多社会要塞领域,比如电子商务、媒介、医疗、金融服务、政府、科技公司等
  • Docker 保障了多个方面的转型,企业开发流程的转型(DevOps),基础架构的进化(Cloud), 应用现代化的变化(Modern App)
  • 更为细化的 Docker 在企业内部的领域切入,我们发现持续集成/交付,以及微服务架构应用集群,是 Docker 最为广泛的应用场景

fenxiang-3

自身集成编排,生态走向如何

全球已经有如此庞大的用户群体,Docker 似乎默认了在容器标准这块领域的大捷。编排如何,自然是由 Solomon Hykes 为所有观众介绍。Solomon 坦言:Docker 容器的集群管理,分布式应用在容器集群上的编排管理,一直是 Docker 想为用户解决的最大痛点之一。如今,在 Docker 1.12.0 发布之后,Swarmkit 完全有能力独自完成这点。

Swarmkit,立足 Swarm 的集群管理能力,原生以插件的形式集成进入 Docker Engine,从而使得 Docker Engine 自身有能力管理庞大的 Docker 集群,一举从根本上解决了 “Docker 只能单机” 这一困扰了业界多达三年的难题。谈及 Swarmkit,Solomon 激动万分,如数家珍的介绍了其中的 4 项超级功能:

fenxiang-4

1. Swarm Mode(集群模式)

单机的 Docker Engine 已经成为历史,新的 Docker Engine 拥有了一个崭新的角色——Swarm Node,Swarmkit 为 Engine 带来的新角色,包含的特性有:

  • 以极强的扩展性联合众多 Docker Engine 形成集群
  • 集群内部的多个 Docker Engine 完全有能力实现自组织
  • 无需额外的类似于 ETCD/Consul 的外部存储
  • 集群环境通过 Raft 一致性协议,避免单点故障问题
  • 可以在基础设施之间灵活部署

2. 强加密的节点认证

集群能力的体现,带来的是强大的 Docker Engine 的资源整合,如此一来,Docker Engine 集群的安全状态显得尤为重要。而 Swarmkit 带来的特性包括:

  • 默认使用极高的安全认证(政治级)
  • 实现 node 之间点对点的 TLS 认证
  • 实现内嵌的的极高认证机制
  • 在任何时刻保证节点间的认证

3. Docker Service API

当 Swarmkit 实现编排的同时,也为 Docker Engine 增加了新的 API 功能,面向服务的 API 提供的特性主要包括:

  • 应用系统预期状态的满足
  • 应用系统的自动扩展
  • 应用系统的 rolling update
  • 高级强大的调度功能
  • 以应用为中心的健康检查
  • 节点失效时的应用重新调度

4. 内置路由机制:

当集群规模壮大,应用集群规模骤变,负载均衡的需求迫在眉睫,Swarmkit 的结合,使得 Docker Engine 自身支持路由功能,而与原生 ovelay 网络的结合,效果愈加显著。

  • Swarm 集群机制的 overlay 网络支持
  • 容器原生的负载均衡
  • 基于 DNS 的服务发现机制
  • 无需额外的集群设置
  • 可以兼容用户现有的负载均衡服务
  • 通过 IPVS 与内核强强联合,实现可靠的负载均衡

IPVS 是在 Linux 内核中构建的传输层 4 层网络上的负载均衡,也被称为 4 层转发(Layer-4 Switching)。IPVS 在宿主机上可以像一个负载均衡器一样,在多个实际 Server 的前端做 TCP/UDP 等方面的转发,从而使得多个实际 Server 对外暴露一个单独的虚拟 Server。IPVS 目前已经被融合进入 Linux Virtual Server(LVS),值得一提的是 LVS 的作者正是阿里云前 CTO 章文嵩博士。

随后,整个会场 4000 多位与会者见证了 Docker 工程师 Andrea Luzzardi 的现场 Demo。docker swarm init 以及 docker swarm join 即轻松构建一个分布式的 Docker Engine,另外关于 node 的管理,服务的管理,应用容器的编排 rolling update 等,都在谈笑风生中逐步完成。掌声不断的同时,大家似乎都默认了 Docker Engine 的无限强大,编排市场 Docker 的未来似乎也是一片大好。

Docker 1.12.0 可以认为是一个分水岭,过往的 Docker Engine 面向单机,往后原生的 Docker Native 即支持集群,与分布式应用系统编排,彻底在工具链 Docker Engine 这一层釜底抽薪,未来的生态之争之争更加趋近白热化。

微服务联姻 Docker,起飞 DockerCon

说完 Docker 的编排,其实在于这一次的 DockerCon 上,还有一个方向格外的受欢迎,那就是——微服务和 Docker 的结合。

微服务的场次永远不缺热度。其中最受欢迎的自然是被称为全球十大软件大师之一的 Chris Richardson,老爷子此次给大家带来的话题是《Microservice+Events+Docker=A Perfect Trio》

首先 Chris 提纲挈领地介绍了一个成功的软件开发包含哪些内容:

fenxiang-5

首先对于软件而言,最需要的自然需要一个比较合理,较为领先的软件架构。其次,在软件架构之下需要软件流程,组织结构的完美支撑。在软件流程方面,开发模式应该尽可能的敏捷,同时在“迭代”和“交付”方面更应该达到极致。而在组织结构方面呢,团队内部应该分为多个不同的小团队,团队之间应该尽可能的拥有自治权,这样在效果和运作方面,才能达到比较好的结果。

如果有了以上比较良好的土壤,在这样的基础上栽培微服务架构就如鱼得水了。Chris 简单介绍了传统单体应用的弊端之后,从三个角度为大家介绍了践行系统架构功能解耦的黄金法则“扩展立方(Scale-Cube)”

fenxiang-6

细说这三个维度就比较有意思:

Y 轴指的是架构的功能解耦,也就是说讲系统架构中的逻辑,按照不同的功能不同的角色进行分离,最终的结果是一个系统由多个不同功能的模块完成。

X 轴指的是实例的水平扩展能力,也就是说功能解藕之后,已经存在多个软件模块,此时每个模块应该有能力灵活,快捷的水平扩展,而不影响系统的工作。

Z 轴指的是数据的分片分区管理。通过 Y 轴和 X 轴完成两步之后,我们会发现系统的数据不易管理,原有系统的数据可能也需要切分,切分之后如何保证数据的一致性等要求,就变得尤为重要。

如果实现微服务的时候,践行以上三点的话,那我们完全可以微服务化的结果是可以接受的。

而回到数据的管理,也就是 Z 轴,传统的分享数据库就显得不那么有效了。ACID,两阶段提交,都会带来不小的耦合与麻烦。针对这种现状,Chris 希望通过事件机制来帮助大家达到数据的最终一致性。

fenxiang-7

介绍了事件机制之后,Chris 随机深入给听众分享了事件溯源机制(event-sourcing).

事件溯源机制最根本的特点在于:个动作产生之后,不会直接去修改数据的最终状态,而是将对象经历的所有事件以严格精准的时间顺序存在于数据库中;由专门的数据处理模块来完成数据的计算存储等。而这一切都是异步完成的,所以并不在完全满足强一致性,而且讲究最终一致性。这样可以有利于数据的解耦。

fenxiang-8

另外 Chris 认为,Docker 和微服务是属于最佳组合,他也罗列了微服务特别注重的优点:

fenxiang-9

分享就到这里,总结一下主要的三点内容:

1. Docker 的生产环境使用现状

2. 自身集成编排,Docker 生态有巨变

3. 微服务联姻 Docker,亮相 DockerCon

提问环节:

Q1:在生产环境中,使用 consul 和 etcd 作为 swarm 的数据存储各有什么特点,如何选?

A1:如果作为 Swarm 的数据存储,这两个都是没有问题的。然而现状是几乎目前所有的 Docker 官方 Demo,都是基于 consul,而非 etcd。这一点选择方面,Swarm 都是沿用了 etcd/consul 的一部分功能。另外,docker 1.12 开始就不再需要 K/V store 了,这一点相信大家肯定会喜欢。

Q2:最近 Docker 的火热程度也让传统的企业跃跃欲试,纷纷想要拥抱 Docker,但是受限于传统企业的开发模式,如何让 Docker 平稳落地,都有哪些突破口?

A2:这一点我希望大家充分理解 Docker 的价值,Docker 在于模式的革命。Ops 会非常喜欢,但是入口是 Dev,也就是 Docker 化,最终较平衡的状态是 DevOps。从 Docker 化出发,Docker 解决的是企业内容 “End to End” 的传统软件流程。因此,企业内部理念理应逐渐迎接 Docker 的这部分思想。

另外,我个人比较反感,单一纯粹的从 Docker 容器运行时,谈论 Docker 的价值。也就是目前圈子内 K8S,Mesos,Docker 的对比,但从运行时是肯定无法落地的。企业内部需要的不是这个,但是个人认为,未来 5 年这一点是非常重要的。

Q3:Docker 官方商店成立的意图是什么呢?

A3:Docker 官方做 Docker Store,我认为是一种类似于 Apple Store 的商业模式,这种模式是一个三方面共赢的结果,其中 Docker 作为 Host 一方,提供成品高价值(商业化)镜像产品提供者一方,最后一方自然是作为消费者的产品购买者。商业化的一种尝试,很有价值,这是我的观点。

Q4: Engine 自身集成了 SwarmKit 编排功能之后,独立的 Swarm 项目是否还会继续开发?

A4:当然会继续维护。从社区对两者的定义,我们可以看出两者存在一些差异。Swarm 是一个 Docker 原生的集群系统,而 Swarmkit 更多的关注分布式系统在 Docker 环境中的编排。Swarmkit 的发展,也是在 Swarm 的思想上孵化而出,以一种更为简捷的方式融入 Docker Engine,更抽象出一些编排领域的概念,服务分布式系统。两者目前完成可以并存,属于给用户多提供了一种选择,暂时不存在外界所猜想的互相竞争。

Q5:Swarmkit 与 Mesos 和 K8s 相比各有特色。在已经存在 Mesos 和 K8s 的情况下,Docker 团队对 Swarmkit 的未来都有哪些规划或目标?

A5:恕我冒昧,提问者所谓的对比是否自足于运行时的编排。对此我采访 Docker 的 Maintainer,他的回复是:Docker 集成的 Swarmkit 编排也是有方向性的。Docker 编排的实体集中于服务(service)与任务(task),而这些概念还是在夯实容器层的概念。

Docker 希望自己可以提供一个 “End-to-End” 的工具链角色。工程师自身能够异常便捷的完成 DevOps 角色:首先在 Desktop 上完成开发,接着通过 Docker 完成测试集成,随后通过 Docker 构建镜像,最后通过 Swarmkit 的功能来完成编排部署。工具的角度将 “DevOps” 理念发挥到极致,会是企业级用户最乐于看到的。

而 K8S,Mesos 更多的自足于最终的运行时,另外属于重量级的系统,在企业内部流程和运维部署上,两者均存在明显弊端。而这些是 Docker 希望避免的。

Q6:想把经常变化的配置文件容器化为 imgA。imgB 为逻辑服务,container 在启动时,B mount 镜像 A 的容器的数据层。现在通过脚本实现了,不知道有没有更优雅的实现或后续官方支持?

A6:作为服务于国内企业 DaoCloud 公司的一员,我深知目前国内 Docker 化的程度达到了什么样的阶段。Docker 化是万物之初,其中日志,配置,状态都是需要特别注意的点。关于配置,尤其易变的状态,我非常不建议通过镜像的形式才存储,因为配置也是状态的一种形态,往往和外部环境息息相关,进入容器就变固化了,不易于容器的灵活性。另外这部分更多应该和部署流程相关,docker 的世界,建议放入 Compose 文件中。

Q7:Docker 社区以后会不会和 windows 开展合作,会是何种模式?是否还能保持现在的各种性能优势?

A7:现在已经有很友好的合作了。这样的合作已经持续接近两年。先前,微软的 Azure 上支持 Docker,其实属于 Azure 上的 Linux 机器支持 Docker。而现在 Window 平台也原生支持 Docker,这磨平了应用与底层两大操作系统阵营之间的 Gap。从性能的角度来看,这和 Docker 不是很有关系,如果 Docker 运行在物理机上,性能肯定好,如果在虚拟机上,肯定会差于前者。

Q8:能否讲一下目前 Docker 在企业化进程中存在哪些不足,以及这次会议上有没有讲到将来如何来弥补?

A8:Docker 是一个崭新的理念,带来的价值足够的大。另外,从企业内部软件流程来看,也能展现出惊人的生命力。不足的地方,在于企业在技术革新的时候,欠缺些许内在和外在可靠的推动力,当然,这其中,国内外,都有一系列的前沿技术公司在为企业提供服务,比如 DaoCloud。将来的弥补,在于 Docker 的产品化,服务化,这部分 Docker 是没有做的,这也是 DaoCloud 等公司服务用户的方向。

(直播过程中所有提问的问题,我们将后续一一为大家解答,请大家时刻关注 DaoCloud 博客)

Leave a Reply

Your email address will not be published. Required fields are marked *