docker&rancher存储调研

一、介绍

       Docker技术的出现使云计算平台部署产品产生了革命性的变化。国内外已经有不少文章对Docker的生态环境进行介绍，包括网络，管理，构建，调度等都有很多资料。但是Docker想要在生产环境中大范围的运用，存储是一道不能规避的鸿沟。本文档结合东网云计算的基础架构和研究方向，描述了当前docker&rancher与ceph结合使用的现状，以供后续开发运维决策参考，关于镜像仓库的相关存储问题暂时没在本文讨论范围内。

二、现状

       目前docker对存储的需求主要体现在两点：

      1.对rootfs各个image的保存;

      2.data volume的需求。

       首先对rootfs进行介绍，Docker的特点决定了并不推荐采用root image的方式来存储应用的重要数据。因为docker中运行的应用都是无状态的，并且可以随时启动、迁移、销毁、弹性扩展，image只是提供了应用运行的必要环境。Docker为重要数据及持久化存储提供了date volume的功能。目前docker使用root image的方式是，当启动容器时，从镜像仓库中下载镜像到host本地文件系统上，然后再启动docker。Docker的graph driver框架目前支持AUFS、Btrfs、DeviceMapper、OverlayFS、ZFS。从目前实际情况来看，AUFS稳定性更好一些，也是docker rootfs主流使用的文件系统。

       在调研过程中发现，docker的storage driver为何支持的都是单机文件系统，不支持集群文件系统或者集群的块服务，实际业务和生产环境有没有对docker rootfs跑在集群存储的需求，这里也是仁者见仁智者见智的讨论。在我个人的理解上，反方观点可能会倾向docker生产环境简单化，比如将所有docker rootfs都放在ceph集群上，当集群出问题可能所有docker服务都出问题。以及docker rootfs不像qemu虚拟机镜像那么重量级，没必要保存在集群上，完全可以下载到本地，然后再运行。从docker社区上来看，之前有人尝试开发graph driver插件[i]，实现rootfs在ceph rbd上运行，但是由于ceph的lib库都是动态库，go语言及graph driver框架在当时不支持静态库的编译[ii]，所以此项开发成果没有得到社区采纳。考虑到一些后端存储类似ceph的lib库都是动态库，以及EMC等其他商业存储不会在graph driver的框架下开发开源插件，社区也做出了努力，支持了采用master/slave的架构开发，而不是把源码编译进graph driver中。 这里可能有一些从技术上来说rootfs image完全可以支持集群存储服务，比如腾讯在2015年就实现了ceph rbd存储rootfs image，并且结合ip漂移，将docker的rootfs跑在了ceph集群上的功能，可以实现更快的故障恢复[iii]。

       下面再谈一谈data volume，Docker数据保存在数据卷中的持久性和重要性，大家应该已经达成了共识。Docker提供了volume plugin框架，使开发者可以对data volume开发配套插件，使后端支持各种各样的存储技术[iv]。目前已有三款插件实现了对ceph rbd的支持[v]，yp engineering、AcalephStorage和Volplugin。对三个插件简单的调查使用发现,已有的插件无法满足生产环境的需求。Volplugin是master/slave架构，还有单独的命令行工具发送RESTful请求，还依赖etcd，显然不是轻量级的方案。AcalephStorage在github上只有代码，而没有文档，并且代码最近更新是1年前，项目已经没人维护了。Ypengineering在ceph hammer版上测试通过，它将rbd格式化为xfs供docker使用，显然不是一个好的方案，而且此插件经过测试暂时还支持jewel版rbd。Rancher使用Convoy作为后端存储插件。此插件支持glusterfs、Device Mapper、VFS、NFS、EBS，对卷的快照备份上支持亚马逊S3和NFS。从功能上来说，此插件及支持多个容器共享文件(glusterfs)，也支持作为类似U盘的块设备的使用方式，并且也考虑到对数据进行快照和备份，颇有满足生产环境的意味。从ceph的角度来看，glusterfs和EBS显然无关，Device Mapper和vfs由于在快照的实现使用linux自带的dm层的实现，所以krbd也无法支持，从使用方式和升级维护方面来考虑，个人认为还是librbd的方式作为卷存储更适合，但是docker的插件接口要的是格式化后的目录，而不是卷，所以nbd可能是一种变通方式。Jewel虽然支持NFS，但是它的NFS是与S3共享bucket，开发用意是帮助企业将传统应用平滑过渡到S3上来，况且从社区反馈和使用方式上来看，性能还存在着很大的问题。基于上述理由，目前对docker&rancher后端存储的插件开发显得尤为重要，理想的功能是Convoy既支持cephfs又支持rbd，而且都可以实现快照备份功能。最近已经有公司着手在做此方面的工作[vi]。

      补充一下在使用convoy和yp engineering中遇到的一些坑。convoy通过go线程调用mkfs.ext4格式化卷并映射到docker容器中，由于mkfs格式化时间长短不定，格式化时间超过convoy的线程超时，此时会终止mkfs，并直接把未格式化完成的卷挂载到docker里，当然结果是挂载失败。并且只要是挂载过的卷，convoy会记录在json配置文件中，下次直接挂载。yp engineering使用go-ceph库调用C库librados，go-ceph库在jewel版上调用某些函数时会崩溃。。这里有一些开发者准备剔除go-ceph库，而直接使用cli的方式操作rbd。从上述几点来看，想要在生产环境下舒服的使用ceph存储，还需要做很多工作.....

[i]  https://github.com/hustcat/docker-graph-driver

[ii] https://github.com/docker/docker/issues/8854

  https://github.com/docker/docker/pull/9146

  https://github.com/docker/docker/pull/14800/

[iii]http://www.infoq.com/cn/articles/how-tencent-game-use-docker?ttid=201200@wangxin_iphone_3.6.8

[iv] https://docs.docker.com/engine/extend/plugins/

[v] http://ceph.com/planet/getting-started-with-the-docker-rbd-volume-plugin/

  https://github.com/docker/docker/issues/10661

[vi]http://dockone.io/article/1257