本文讲的是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（二）：存储问题
