云计算容器服务该何去何从

容器技术最近很火，各家项目纷纷提出自己的支持方案，比如 OpenStack、CF、Mesos，以及一堆本身就基于容器的平台方案，更是跟容器技术脱不开关系。

这也直接导致了暧昧已久的 IaaS 和 PaaS 开始正面的跨界冲突。

在 IaaS 看来，做 PaaS 无非就是提供几个应用模板嘛，原来虚机不好做，现在用 Docker，瞬间给你把服务整起来。更别提还有最近出来搅局的 hyper，虚机要跟容器比性能。

而在 PaaS 看来，你 IaaS 就该老老实实地做底层物理资源给抽象出虚拟资源的事情。原来都是虚机的时候，感觉好复杂，我们搞软件的人确实不懂。现在有了一堆基于 Docker 的容器平台，往上就都是我做软件的人可以做的事情了，所以以后其实可以不再强调 IaaS 了。

这些讨论直接导致现在的云计算技术发展到了一个很关键的节骨眼上，将决定未来至少十年内云计算产业的形态。

当前状况

姑且放下这些争论，我们来看一下 IaaS 领域的 Top 开源项目 OpenStack 现在是怎么对待容器的。

目前有三种方案：

Nova-Docker：把容器作为虚机管起来。基本上其它组件都不需要动。唯一的问题就是容器毕竟不是虚机，比如需要提供一些额外的参数支持啦，需要引入组的概念啦，需要性能的优化啦。

Heat Docker Driver：用 Heat 来管容器。Heat 大家都知道，是个十分灵活且强大的解释引擎，理论上 Docker 需要的支持它都能有。唯一的问题是 Heat 毕竟是个解释引擎，它本质上还是要基于其它服务提供的 API。由于不是个运维引擎，导致运行时的管理没法保障，比如自动的资源调度啊，网络功能啊，等等。如果这些都做了，那就等于在更高一层上重复发明轮子了。

Magnum：玩容器的人看问题基本上都是从应用层往上开始考虑。一帮人跑去 Nova 项目谈，应该怎么支持基于容器的 DevOps 啊，应用模板啊，Nova 组一帮做系统的人就傻了，这事我们咋能干，这分明是 PaaS 该做的事情。但架不住大家都觉得 Docker 很火啊，我们肯定还是要玩点花样的，于是一个新的项目诞生了。但玩应用的人毕竟不懂系统，于是调研了下，现在能管理 Docker 的开源方案还真有几个，比如 Swarm 和 Kubernetes。太好了，那么，怎么把 Swarm 和 Kubernetes 这样的 PaaS 平台给集成到 OpenStack 这样的 IaaS 平台上呢?这个听起来好像也不懂唉，有人又想起 Heat 来了，一拍脑袋，可以先拿 Heat 来装一套啊。每次需要的时候就调个 Heat 命令，动态的装一套。所有问题看起来都解决了，皆大欢喜啊，真是皆大欢喜!

思考云计算

某位名人说过，之所以能看得远，是因为站在了前人的肩膀上。

让我们抛开系统和应用之争，姑且也胆大地站在前人的肩膀上来重新发明轮子。

还是要忍不住重复，信息技术的领域离不开分层和抽象。在不同的时代和位置进行分层和抽象，诞生了小型机，诞生了处理器，诞生了编程语言，诞生了 Web 服务，诞生了云计算……

抛开 IaaS，抛开 PaaS，云计算到底要提供啥?这个问题毫无疑问，是便捷服务。 于是，用户需要操作系统，可以直接给你一个;用户需要一个运行环境，可以直接给你一个;用户需要一套软件，也可以直接给你一个;用户需要一套方案，这个目前还没法直接给你一个，属于外包公司的业务。：)

那么，对于云平台的设计者来说，就是要提供这些不同层次的服务给用户，这才有了所谓的 IaaS 和 PaaS。所以，要记住，各种 XaaS 是呈献给用户的服务层次的不同，根本不是设计层次和技术方案的不同。

就好比你买了一个手机，可以玩游戏，也可以打电话。游戏和电话是手机提供给你的不同服务形态而已，并非说游戏是一种特殊的手机，电话是另外一种特殊的手机。

OK，那么，下面的问题就是讨论为了满足用户的这些需求，在设计上该如何分层。前人的智慧是毫无疑问的，总结出了计算、存储、网络这三个根本的基础业务。其中计算又是最核心和最直接的。

我们来看直接面向用户的计算业务。数据中心里面放着的都是物理机器，物理机器上可以装操作系统，操作系统上可以装各种软件，可以运行虚拟机，可以运行容器。无论物理机、虚拟机、容器，都是属于计算资源。统统都应该用云方案给实现供应出来。

如果说 IDC 是让用户可以拿物理机作为计算资源载体，那么现在的云计算是更进一步，让用户可以直接忽略计算资源的实际载体，无论是操作系统还是应用，直接提供给你即可，无需关心具体的载体。

总之一句话，云计算就是要方便提供计算资源!

问题与方向

Magnum 目前被认为 OpenStack 里面最有活力的容器项目，但是很可惜，一开始的路子就是偏的。

Magnum 的定位是提供一套 OpenStack API，底下可以兼容/依赖多种第三方的容器管理平台。OpenStack 本来就是要做一套资源管理平台，现在是用别人的，意味着这跟 OpenStack 其实关系不大。但是如果抛开 OpenStack，上面封装的一套 OpenStack API 又没有了意义。第三方的管理平台都有自己现成的 API。

真正的 Container as a Service，其实应该是在 OpenStack 中实现一套容器平台，而不是在 OpenStack 中安装了别人的一套平台，然后进行了 API 的封装。

或许有人会猜测，之所以不做底下的实现，可能跟 Nova-Docker 有关。

如果我们只谈技术，其实很容易在 Nova 中实现真正的 Container as a Service。在 Nova 看来，都是计算节点，但计算节点可以带上各自的类型，比如有的计算节点是物理机、有的是虚拟机、有的是容器甚至容器组。不同的类型意味着底层不同的驱动。用一套抽象的资源调度的框架(参考 Mesos 的二层调度机制)，带上不同的底层 framework，问题很容易得到解决。

但偏偏是现在已经有了 Nova-Docker，已经有了 Magnum，不知道要经过多少波折才可能走到这个方向上来。或许在 OpenStack 的大环境下，是一件太困难的事情了。

或许，这就是开源的魅力，分分合合，曲折中前行。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友