【编者的话】作者继续讲述他们的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之前,我们用的是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卷拥有如下结构:
/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 (翻译: 梁晓勇 校对:郭蕾)