容器编排之战(二)连载

Swarm与CoreOS

Docker 公司发布 Swarm 项目

Docker 公司在 2014 年发布 Swarm 项目. 一个有意思的事实:虽然通过"容器"这个概念完成了对经典 PaaS 项目的"降维打击",但是 Docker 项目和 Docker 公司,兜兜转转了一年多,却还是回到了 PaaS 项目原本深耕多年的那个战场:如何让开发者把应用部署在我的项目上。

Docker 项目从发布之初就全面发力,从技术、社区、商业、市场全方位争取到的开发者群体,实际上是为此后吸引整个生态到自家"PaaS"上的一个铺垫。只不过这时,"PaaS"的定义已经全然不是 Cloud Foundry 描述的那个样子,而是变成了一套以 Docker 容器为技术核心,以 Docker 镜像为打包标准的、全新的"容器化"思路。

这正是 Docker 项目从一开始悉心运作"容器化"理念和经营整个 Docker 生态的主要目的。

Docker 公司在 Docker 项目已经取得巨大成功后,执意要重新走回 PaaS 之路的原因:

虽然 Docker 项目备受追捧,但用户们最终要部署的,还是他们的网站、服务、数据库,甚至是云计算业务。只有那些能够为用户提供平台层能力的工具,才会真正成为开发者们关心和愿意付费的产品。而 Docker 项目这样一个只能用来创建和启停容器的小工具,最终只能充当这些平台项目的"幕后英雄"。

Docker 公司的老朋友和老对手 CoreOS:

CoreOS 是一个基础设施领域创业公司。 核心产品是一个定制化的操作系统,用户可以按照分布式集群的方式,管理所有安装了这个操作系统的节点。从而,用户在集群里部署和管理应用就像使用单机一样方便了。

Docker 项目发布后,CoreOS 公司很快就认识到可以把"容器"的概念无缝集成到自己的这套方案中,从而为用户提供更高层次的 PaaS 能力。所以,CoreOS 很早就成了 Docker 项目的贡献者,并在短时间内成为了 Docker 项目中第二重要的力量。

2014 年底,CoreOS 公司与 Docker 公司停止合作,并推出自己研制的 Rocket(后来叫 rkt)容器。

原因是 Docker 公司对 Docker 项目定位的不满足。Docker 公司的解决方法是让 Docker 项目提供更多的平台层能力,即向 PaaS 项目进化。这与 CoreOS 公司的核心产品和战略发生了严重冲突。

Docker 公司在 2014 年就已经定好了平台化的发展方向,并且绝对不会跟 CoreOS 在平台层面开展任何合作。这样看来,Docker 公司在 2014 年 12 月的 DockerCon 上发布 Swarm 的举动,也就一点都不突然了。

CoreOS 项目:

依托于一系列开源项目(比如 Container Linux 操作系统、Fleet 作业调度工具、systemd 进程管理和 rkt 容器),一层层搭建起来的平台产品

Swarm 项目:

以一个完整的整体来对外提供集群管理功能。Swarm 的最大亮点是它完全使用 Docker 项目原本的容器管理 API 来完成集群管理,比如:

单机 Docker 项目:

# docker run " 我的容器

多机 Docker 项目:

# docker run -H " 我的 Swarm 集群 API 地址 " " 我的容器 "

在部署了 Swarm 的多机环境下,用户只需使用原先的 Docker 指令创建一个容器,这个请求就会被 Swarm 拦截下来处理,然后通过具体的调度算法找到一个合适的 Docker Daemon 运行起来。

这个操作方式简洁明了,对于已经了解过 Docker 命令行的开发者们也很容易掌握。所以,这样一个"原生"的 Docker 容器集群管理项目一经发布,就受到了已有 Docker 用户群的热捧。相比之下,CoreOS 的解决方案就显得非常另类,更不用说用户还要去接受完全让人摸不着头脑、新造的容器项目 rkt 了。

Swarm 项目只是 Docker 公司重新定义"PaaS"的关键一环。2014 年到 2015 年这段时间里,Docker 项目的迅速走红催生出了一个非常繁荣的"Docker 生态"。在这个生态里,围绕着 Docker 在各个层次进行集成和创新的项目层出不穷。

cncf

Fig 项目

被docker收购后改名为 Compose

Fig 项目基本上只是靠两个人全职开发和维护的,可它却是当时 GitHub 上热度堪比 Docker 项目的明星。

Fig 项目受欢迎的原因:

是它在开发者面前第一次提出"容器编排"(Container Orchestration)的概念。

"编排"(Orchestration)在云计算行业里不算是新词汇,主要是指用户如何通过某些工具或者配置来完成一组虚拟机以及关联资源的定义、配置、创建、删除等工作,然后由云计算平台按照这些指定的逻辑来完成的过程。

容器时代,"编排"就是对 Docker 容器的一系列定义、配置和创建动作的管理。而 Fig 的工作实际上非常简单:假如现在用户需要部署的是应用容器 A、数据库容器 B、负载均衡容器 C,那么 Fig 就允许用户把 A、B、C 三个容器定义在一个配置文件中,并且可以指定它们之间的关联关系,比如容器 A 需要访问数据库容器 B。

接下来,只需执行一条非常简单的指令:# fig up

Fig 就会把这些容器的定义和配置交给 Docker API 按照访问逻辑依次创建,一系列容器就都启动了;而容器 A 与 B 之间的关联关系,也会交给 Docker 的 Link 功能通过写入 hosts 文件的方式进行配置。更重要的是,你还可以在 Fig 的配置文件里定义各种容器的副本个数等编排参数,再加上 Swarm 的集群管理能力,一个活脱脱的 PaaS 呼之欲出。

它成了 Docker 公司到目前为止第二大受欢迎的项目,一直到今天也依然被很多人使用。

当时的这个容器生态里,还有很多开源项目或公司。比如:

专门负责处理容器网络的 SocketPlane 项目(后来被 Docker 公司收购)

专门负责处理容器存储的 Flocker 项目(后来被 EMC 公司收购)

专门给 Docker 集群做图形化管理界面和对外提供云服务的 Tutum 项目(后来被 Docker 公司收购)等等。

Mesosphere与Mesos

老牌集群管理项目 Mesos 和它背后的创业公司 Mesosphere:

Mesos 社区独特的竞争力:

超大规模集群的管理经验

Mesos 早已通过了万台节点的验证,2014 年之后又被广泛使用在 eBay 等大型互联网公司的生产环境中。

Mesos 是 Berkeley 主导的大数据套件之一,是大数据火热时最受欢迎的资源管理项目,也是跟 Yarn 项目杀得难舍难分的实力派选手。

大数据所关注的计算密集型离线业务,其实并不像常规的 Web 服务那样适合用容器进行托管和扩容,也没有对应用打包的强烈需求,所以 Hadoop、Spark 等项目到现在也没在容器技术上投下更大的赌注;

但对于 Mesos 来说,天生的两层调度机制让它非常容易从大数据领域抽身,转而去支持受众更加广泛的 PaaS 业务。

在这种思路指导下,Mesosphere 公司发布了一个名为 Marathon 的项目,这个项目很快就成为 Docker Swarm 的一个有力竞争对手。

通过 Marathon 实现了诸如应用托管和负载均衡的 PaaS 功能之后,Mesos+Marathon 的组合实际上进化成了一个高度成熟的 PaaS 项目,同时还能很好地支持大数据业务。

Mesosphere 公司提出"DC/OS"(数据中心操作系统)的口号和产品:

旨在使用户能够像管理一台机器那样管理一个万级别的物理机集群,并且使用 Docker 容器在这个集群里自由地部署应用。这对很多大型企业来说具有着非同寻常的吸引力。

这时的容器技术生态, CoreOS 的 rkt 容器完全打不开局面,Fleet 集群管理项目更是少有人问津,CoreOS 完全被 Docker 公司压制了。

RedHat 也是因为对 Docker 公司平台化战略不满而愤愤退出。但此时,它竟只剩下 OpenShift 这个跟 Cloud Foundry 同时代的经典 PaaS 一张牌可以打,跟 Docker Swarm 和转型后的 Mesos 完全不在同一个"竞技水平"之上。

已标记关键词 清除标记