Docker Workflow（二）：存储问题

本文讲的是Docker Workflow（二）：存储问题，【编者的话】作者继续讲述他们的Docker迁移之旅。这次他们的对手是Drupal及其文件存储，且看GlusterFS和Docker是如何配合轻松解决这个原本很棘手的问题。解决了这个问题，我们在开发环境与生产环境一致的目标上又前进了一大步。
本文讲的是Docker Workflow（二）：存储问题，【编者的话】作者继续讲述他们的Docker迁移之旅。这次他们的对手是Drupal及其文件存储，且看GlusterFS和Docker是如何配合轻松解决这个原本很棘手的问题。解决了这个问题，我们在开发环境与生产环境一致的目标上又前进了一大步。

几天前，我讲述了我们在IIIEPE如何开始在生产环境中使用Docker（译注：已翻译）。它确实改变了我们开发与部署Web应用的方式。在本系列文章中，我将继续讲述我们的经验、碰到的问题及我们是如何解决的。

上一篇文章没提及太多能帮你理解为什么我们要这么做的背景，如果你还在阅读，请听我慢慢道来。

IIIEPE是一家政府研究院，我们热爱开源。我们使用Drupal和Node.js开发了很多的项目，同时我们有自己的数据中心。在写本文的时候，我们共有25个Web应用，但每天只有8-10个会收到提交。上一版的工作流制定于2005年，我们在一个与生产机完全不同的环境上进行开发（听起来很熟悉？），因此我们通常是在一个测试环境里运行应用来检测问题。可笑的是，测试环境用的VM与生产机VM也完全不同。

在开始规划迁移和制定新工作流时，我们建立了一个愿望清单，其中包括了：100%的网站复制，以便将服务器维护期间的宕机时间减到最小，即便是流量很小的HTML网站也要运行至少2个实例在不同VM上。拥有一个弹性云是愿望清单里的另一项，因为我们会时不时碰到流量高峰。

由于很多网站是使用Drupal制作的，在测试迁移时，这给我们提出了许多挑战，其中最大的是存储问题。

我们没有类似AWS S3的存储方案，也没有经费购买Amazon的空间，因此我们测试了LibreS3。一旦解决了DNS问题，LibreS3是个非常不错的兼容S3 API的克隆体。

不过Drupal有时会带来大麻烦。Drupal无法与S3顺利对接，所以就算是我们想用S3，也需要花费数月时间来优化Drupal，而我们没有时间和耐心去做这件事。

在迁移所有东西到生产环境前，我们使用DigitalOcean测试了Deis这样的PasS方案和Panamax这样的编排软件。Deis配置不难，使用也非常简单。Deis以及其它我们测试过的编排方案最大的问题是存储问题，实际上，是类Heroku的暂生文件系统。当时Panamax对我们来说还不完善，因为它没有支持多主机环境的代理。
GlusterFS 在使用GlusterFS之前，我们用的是NFS，但几年前在配置的时候我们犯了个错误，只配置了一台NFS VM。后来我们又犯了个错误，没有将主机操作系统升级到下一个主版本，以至于在我们想这么做时已经太迟了。我们听闻了不少GlusterFS的赞誉，因此在需要重新安装NFS时，我们决定先试试GlusterFS。

让人意外的是，GlusterFS非常容易配置。我们建立了2台GlusterFS VM，它们互为备份，在一台发生宕机时，另一台立即透明地开始提供文件服务。如果未来需要扩展存储方案，只要创建拥有更大空间的新副本并关闭旧VM即可。

配置好GlusterFS，存储层就搞定了，我们只需要将每个Web节点连接上，这相当简单。然后，我们只需要将Docker引入这些节点。
数据卷 Drupal会在sites/default/files目录下写入各种文件。问题是，这些文件是在Web应用里面的。Drupal的主页面文件是/var/www/index.php，而其它文件在/var/www/sites/default/files里，如你所见，没有任何关注点分离（separation of concerns），文件和代码通过这种方式混杂在几个目录中。就连Drupal自带的.gitignore都包括了这个目录，以免将这些文件提交上去。

将sites/default/files移出/var/www也不可行，因为Drupal会给你制造障碍，如果你这么做了，准备花时间来面对这些问题吧。

因此我们不得不使用共享。

我说过每个应用都有一个Dockerfile，而且这个Dockerfile使用了一个基础镜像。在开发一个应用时，我们会共享应用目录让代码出现在/var/www里，而当Jenkins构建镜像时，它会将相同的应用目录复制到/var/www中。从容器的角度来看，不论是共享还是复制，代码是相同的；从开发人员角度来看，环境是与生产机一致的。

要解决/var/sites/default/files的问题，我们就只要将它共享给宿主，因此我们在Dockerfile中增加了一行：

VOLUME ["/var/www/sites/default/files"]

同时，确保项目中不包含files目录。Docker会创建这个目录并将其映射到我们指定的地方。由于Maestro-NG可以很容易完成这件事（我会在下一篇文章讲述），剩下的就非常简单了。
GlusterFS + Docker 为了让事情更简单，并进一步规范我们的工作流程，GlusterFS卷拥有如下结构：

/storage/files/subdomain.domain.com

/storage/logs/subdomain.domain.com

然后，每个容器这样映射files目录：

container -  host  

/var/www/sites/default/files -  /storage/files/subdomain.domain.com

每个Web节点会对这个目录进行读写，正因为每个应用有一个单独的目录进行文件读写，备份将更简单。所有这些都把Drupal蒙骗了，因为它认为它读写的是/var/www/sites/default/files，但实际上它读写的是/storage/files/subdomain.domain.com。就是这样！

Docker 1 比 Drupal 0。
开发人员 开发这些网站时，我们并不需要下载files目录，因为我们将它们视为内容存储在服务器上，不过在启动容器时，我们还是需要重建这个结构。我会在另外的文章中说一下我们是如何处理数据库的。我们的实现方式是在项目根目录包含一个files目录，并将其添加到.gitignore文件中，以免将其提交。

使用docker-compose（或fig）看起来是这样的：

volumes:  

- application:/var/www

- files:/var/www/sites/default/files

这样，我们的应用映射到/var/www，同时Drupal有地方可以愉快地写入文件了。

感谢您的阅读，有什么想法或问题请留言。下一篇文章我将讲述我们如何配置Maestro-NG，以及如何让Jenkins处理繁重的工作。在最后一篇文章中，我将讨论我们使用的服务发现方案，以及我们碰到的负载均衡器的问题。

原文链接：A production ready #Docker workflow. Part 2: The Storage Problem（翻译：梁晓勇 校对：郭蕾）
原文发布时间为：2015-03-30  本文作者：sean 本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。 原文标题：Docker Workflow（二）：存储问题
Docker 与 K8S学习笔记（十一）—— 容器的存储 Docker为容器提供了两种存储数据的方式： Storage Driver即存储驱动 Data Volume即数据卷 本节我们分别讨论下它们的应用。 一、Storage Driver 前面讲过容器是由一个可写的容器层加若干个只读的镜像层组成，这样的设计带来如下效果： 新数据直接写在容器层中； 修改现