国内Docker服务和产品初探


【编者的话】最近抽空写了个玩具项目,一是怕老是不写代码容易手生,二是打算看看拿来试试已知的几个Docker创业公司的产品,本文就专门谈谈自己使用后的感受。

各家产品感受

我知道的Docker创业团队一共五个:DaoCloud、cSphere、Alauda、TenxCloud、DataMan,除了最后一个数人重点在Mesos+Docker,没找到在线试用的门路,其它几个都初步试了一下,下面分别说明。


说明:Docker相关产品变化很快,我只能说自己试用时的情况,在文章发出后读者看到的功能可能会有所不同

DaoCloud

  • 似乎不能直接用 hub.docker.com 上的镜像制作服务
  • 集成只能依赖源码中或者线上编写的 docker-compose.yml ,对线上操作有些不便
  • 有些时候访问比较慢
  • 在有限的几次操作中,发现构建速度比alauda快
  • 一开始没找到提bug/issue的地方,后来找到后觉得界面融合的很好
  • 只能部署在自己注册的宿主机上,好处是可以保持控制力,缺点是缺省没有跨主机的部署方案
  • 集成测试仅仅是一个容器内玩点脚本,如果想要做微服务的集成似乎不可行


cSphere

  • 系列培训做的很不错,但是每一次时间有些长,对学习者的要求比较高,建议切割成几部分
  • 提供了一个完整的产品可以用于自己搭建,用户容易有掌控感
  • 安装很简单,交付的产品上手很容易(同类产品没有找到安装私有云环境的方法)
  • 不知道如何进行跨单机的容器协作
  • 有些小问题需要处理(比如web界面上hostname同名时的选择问题),但没有源码无法提patch
  • 以机器/容器视角进行管控,显得抽象不足,期望是结合compose以镜像/服务视角进行管理


Alauda

  • 不知道LB用的是什么方案?是否能跨机操作
  • 构建时选择国内和国际两种情况比较赞,有些镜像是在国内构建比较快
  • 提供存储卷服务,便于应用服务编排,但是不知道如何跨机
  • 构建服务,设定环境变量值的时候需要设置一个较长的字符串(secret seed),结果显示不太好看
  • 缺省的服务数量有上限,最多 4 个服务,2 个 cpu
  • 工单系统看上去有点low,如果不能做漂亮,不如学csphere直接搭一个开源论坛进行互动


TenxCloud

  • 字体比灵雀云好看些,比较舒心
  • 与DaoCloud类似,也不能直接用 hub.docker.com 上的镜像制作服务
  • 获取github上的项目列表时有数量限制,已经修复
  • 不能获取源码仓库的分支内容,已经修复
  • 构建系统支持国际/国内节点的区分
  • 构建系统可以选择程序类型,感觉这个功能会成为鸡肋
  • 对IAAS厂商仅支持AWS,期待支持 qingcloud、ucloud、aliyun
  • 服务编排的UI界面看似很好,但其实用处不大


对Docker服务的整体探讨

从知道Docker这个产品开始,我就一直期望Docker能够为软件/互联网企业带来一些有价值的东西。现有的场景下,Docker既是一个软件,又是一个技术生态,围绕这一技术,各家公司都在努力解决Docker集群的管理问题,希望为软件和互联网企业带来价值,而具体做法各有异同。

下面进行一些综合性质的讨论,为了方便,我们把基于docker技术来管理镜像、构建过程和各种服务编排的平台称为Docker云平台。

产品形态

目前主要有两种产品交付方式——
  • 开发 Docker 云平台,以image交付产品,支持用户自建Docker管理集群,公司提供培训和软件咨询服务
  • 在线提供 Docker 云平台,以SaaS形式交付服务,底层可以使用IaaS服务,通过用户账号接入其它 IaaS 平台


前一种可以给予用户更多的掌控,但从长远考虑,如果由客户自己运维Docker云平台,势必需要一个专业的运维团队,这会给企业带来很大的运作成本,所以前一种方式仅仅有利于客户培养,未来应该以后一种方式为主。

后一种方式的主要代价是企业不好控制自己的数据安全,后来了解到的一种办法是使用所谓的 hosted private cloud ,这样企业仍然需要做一些基础运维工作,但是主要局限于软件环境,可以看做是安全和成本的一种平衡。

网络解决方案

Docker由于其轻量级的特点,很容易就可以在一个宿主机上运行多个容器,这使得我们可以用低廉的成本在单机上进行分布式集成测试
,但这是研发和测试的需求,线上的着眼点必然要支持跨宿主机,以支持包括弹性扩容之类的运维能力。

目前已知的网络方案尚无公认的最佳实践,我看到的方式大都还是以 bridge+NAT 为主,这块期待突破,也希望了解各家Docker团队对Swarm的支持。

服务编排

服务编排是Docker类应用从玩具到真正系统的一个分水岭,但是各家支持不尽相同。
  • 不支持——仅支持Docker的单个容器视角,这样会让用户把Docker当做简化的虚拟机来使用,特别是功能菜单也类似IaaS系统的信息结构时。
  • 简单的支持——借助 Docker Compose ,在同一个宿主机上使用 docker-compose.yml 文件做服务编排,未来也可以借助swarm+compose组合跨越宿主机。
  • 较高级的功能支持——将compose中的各种要素进行拆解,用户使用web表单提交需要的编排方式,这个做法简化了用户编写 yaml 文件的工作,但是需要对compose的信息结构进行消化,使之适应web表单的展现方式。


服务编排的结构对线上和开发测试可能有所差异,所以有一种做法是对不同的环境编写不同的 yaml 文件,但我对这个做法持保留态度,因为这会让各种环境的一致性受到破坏。

目前比较好的做法可能是分析 yaml 文件中的服务依赖,然后利用 external_links 建立对外部资源的依赖,而在不同的环境下,自然有不同的外部资源来提供。

存储解决方案

docker本身应该是无状态服务,所以状态的管理非常重要,通常做法是在宿主机上提供挂载卷,由docker云平台提供存储迁移和备份服务,这应该是docker云平台的一个重要功能。

跨越地理节点

这里指的是跨机房协作,通常仅与线上运维相关,而与开发和测试关系不大。

这块工作对Docker云平台有所要求,若要协作不同机房的docker容器,势必需要一个建立在公共域的管控中心,那么安全策略和模型、网络管理方式都会与同网段宿主机群的时候大为不同。

同网段宿主机群是可以互相网络可达的,所以一般是这样:
Host A <--(控制)--- Controller Node
Host B <--(控制)---
Host C <--(控制)---

跨机房的时候,控制中心通常不能直连宿主机群,所以需要变通:
Host A ---(agent上报,查询并执行命令) --> Controller Node
Host B ---(agent上报,查询并执行命令) -->
Host C ---(agent上报,查询并执行命令) -->

当然,如果对自己的控制链路有信心,我其实更倾向于免agent的方案,即将sshd看做缺省就有的agent,只是在每个机房留一个broker即可,好处是减少对宿主机的干预和维护成本。
Host A <--(管控)-- Broker --(查询并执行命令) --> Controller Node
Host B <--(管控)---
Host C <--(管控)---

实践中的这块情况了解有限,目前仅知道 Mesos 是模式一,因此不能跨机房,而k8s是模式二,可以很容易的跨越机房和IaaS服务商。

3 个评论

写的很赞,分析的深入且到位。网络这块,不知道flannel会否成为标准? 还有,关于编排,k8s用于生产环境是否为时过早? 我个人也倾向无agent管理
flannel确实很赞,不过这个设计实际上动了网络架构,有些问题涉及到通盘考虑,不敢妄下结论
k8s已经1.0了,可以用在生产。不管用不用在生产,可以先研究下,感受下其强大

要回复文章请先登录注册