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(翻译:梁晓勇 校对:郭蕾)

0 个评论

要回复文章请先登录注册