在Docker里运行Ceph

本文讲的是<b>在Docker里运行Ceph</b>，【编者的话】Ceph是开源社区深受欢迎的存储方案，具有稳定性高、性能好、可扩展性强等特点。原作者的这篇文章展示并探讨了如何将Ceph运行在Docker上，无疑为Docker生态系统的完善迈出了重要一步。存储问题是将Docker应用于生产环境中的备受关注的话题之一，这篇文章抛砖引玉，必将激发广大开源和Docker技术爱好者探究现有存储方案与Docker相整合的热情。

现在让我们具体看看如何将Ceph运行在Docker里！

将Ceph运行在Docker中是一个比较有争议的话题，不少人质疑这样操作的意义。虽然将检测模块、metadata服务器、以及RADOS gateway容器化都没有太大问题，但对于OSD（object storage daemon），事情会变得很棘手。Ceph的OSD专门针对物理机器进行优化，与底层硬件有很多关联。如果物理硬盘失效，OSD也无法运作，这给容器化的场景带来了问题。

坦白地讲，在过去某个时刻我也在想：

“我不知道自己为什么做这个，我只知道有人需要这个功能（当然，他们可能也不知道为什么想要）。我只是觉得想进行技术尝试，那就试试看！”

当然上述想法听起来并不乐观，但这确实是我当时真实的想法。我的观点随后有了一些变化，我来解释下为什么是值得的。希望这个解释也能改变你的看法（我的解释不仅仅是“Docker很酷，所以我们要把所有东西都跑在Docker里!”）。

不少开发者已经花了很多时间将他们的软件容器化。在这个过程中，他们也用过多种不同的工具来构建和管理他们的环境。如果我看到有人用Kubernetes来作为管理工具也一点都不会吃惊。有的人就喜欢将最新潮的技术应用到生产当中，否则他们会觉得工作很无聊。所以当他们看到自己最喜欢的开源存储方案也正在被容器化时，他们会因为这个顺应了“一切容器化”的方式而感到高兴。

与传统的<code>yum</code>或<code>apt-get</code>不同，容器使得软件的升级和回卷变得容易：我们可以通过<code>docker stop</code>或者<code>docker run</code>来发布新的daemons版本。我们甚至可以在一台物理机器上运行多个相互隔离的集群。这些都为开发过程提供了极大的便利。

由于监测模块不能在NAT过的网络中进行通信，我们必须使用 <code>--net=host</code>来将主机的网络层开放给容器：

你可以配置如下选项：

<code>MON_IP</code>是运行Docker的主机IP

<code>MON_NAME</code>是你监测模块的名称（默认为$（hostname））

<code>CEPH_PUBLIC_NETWORK</code>是运行Docker的主机的CIDR。它和<code>MON_IP</code>必须是同一个网络。

<code>CEPH_CLUSTER_NETWORK</code>是运行Docker的主机的备用网口的CIDR，为OSD的备份流量使用。

我们现在能实现允许每一个OSD进程运行在一个独立的容器里。按照微服务的理念，一个容器里不应该运行超过一个服务。而在我们这里，在同一个容器里运行多个OSD进程，打破了这一理念，当然这也会给系统的配置和维护带来额外的复杂度。

在这样的配置下，我们必须使用<code>--privileged=true</code>来使得容器中的进程可以访问<code>/dev</code>等其他内核功能。然后，我们在开放OSD的目录的基础上也支持其他配置，开放OSD的目录可以让operators来对设备做合适的准备工作。这样我们就可以简单地开放OSD目录，配置OSD（<code>ceph-osd mkfs</code>）的工作就会通过Entry Point来完成。我下面介绍的配置方法是最简单的，因为它只需要你指定一个block device，剩下的事情都会由Entry Point完成。

如果不想用<code>--privileged=true</code>可以采用我的第二个例子。

如果你不想使用<code>--privileged=true</code>，你也可以使用你喜欢的配置管理工具来手动配置OSD。

下面这个例子我假定你已经实现分区并配置好文件系统。运行下面的命令来生成你的OSD：

$ sudo docker exec &lt;mon-container-id&gt; ceph osd create.

然后运行你的容器：

可配置的选项如下：

<code>OSD_DEVICE i</code>是OSD设备，例如:<code>/dev/sdb</code>

<code>OSD_JOURNAL</code>使用来储存OSD journal的设备，例如：<code>/dev/sdz</code>

<code>HOSTNAME</code>是运行OSD的主机（默认为$（hostname）

<code>OSD_FORCE_ZAP</code>会强制将制定的设备内容zapping（默认为 0，设为1去开启）

<code>OSD_JOURNAL_SIZE</code>是OSD journal的大小（默认为 100）

这个组件的设置较为直观。唯一需要注意的地方是在Docker中我们可以访问Ceph管理员密钥。这个密钥会用来生成CephFS pools和文件系统。

如果你运行0.87以前的Ceph版本，你就不需要做此配置，然而我们最好运行最新的版本！

<code>MDS_NAME</code>是Metadata服务器的名字（默认为mds-$(hostname)）。

<code>CEPHFS_CREATE</code>会为Metadata服务器生成文件系统（默认为0，设为1 去开启）。

<code>CEPHFS_NAME</code>是Metadata文件系统的名字（默认为cephfs）。

<code>CEPHFS_DATA_POOL</code>是Metadata服务器data pool的名字（默认为cephfs_data）。

<code>CEPHFS_DATA_POOL_PG</code>是data pool的placement groups的数量 （默认为8）。

<code>CEPHFS_DATA_POOL</code>是Metadata服务器metadata pool的名字（默认为cephfs_metadata）。

<code>CEPHFS_METADATA_POOL_PG</code>是metadata pool的placement groups的数量（默认为 8）。

我们部署RADOS gateway时默认开启<code>civetweb</code>。当然，我们也可以通过指定地址和端口来使用不同的CGI前端： 

<code>RGW_REMOTE_CGI</code>指定是否使用嵌入的web服务器（默认为0，设为1去关闭）。

<code>RGW_REMOTE_CGI_HOST</code>指定运行CGI进程的远程主机。

<code>RGW_REMOTE_CGI_PORT</code>是运行CGI进行的远程主机端口。

<code>RGW_CIVETWEB_PORT</code>是civetweb的监听端口（默认为80）。

<code>RGW_NAME</code>是RADOS gateway实例的名字（默认为$(hostname)）。

在默认配置下，<code>ceph.conf</code>和所有的Ceph密钥都会在监测模块启动阶段生成。这个过程假定了你必须在将集群扩展到多节点的时候去把这些配置传送到所有节点上。这个操作并不灵活，我们希望去改善它。我马上要提出的一个方案就是利用Ansible来生成这些配置文件和密码，并将他们安装到所有机器上。

也不需要做什么，因为你可以直接将你的Docker镜像运送到Rocket里，然后运行。

========================================

译者介绍：

Julia Han：School of Information Sciences, University of Pittsburgh, USA，硕士，Docker爱好者。

原文发布时间为：2015-08-04

本文作者：juliahan

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：在Docker里运行Ceph