吴飞群 分布式实验室 

每天都有成千上万的人在使用Yelp的SeatMe来完成餐厅预订服务。这篇博客将会深入地讲解Yelp是如何使用Docker来开发并部署SeatMe系统的。Docker是一个非常强大的生产环境助推器，它已经大大简化了我们的部署方式。首先，我要简单介绍一下Yelp的SeatMe系统的背景，以及它的开发部署方式。

餐厅会通过我们的网站或者iPad应用来接受并管理客户预定信息。我们会保证客户所有的终端信息实时同步，同时当客户在没有联网的情况下我们也支持离线更改。

我们的技术栈：

• 客户端的JavaScript，我们在单页应用中使用到了Backbone。

• Python是我们后端的语言，Django是我们的Web框架。

• 我们使用Celery和RabbitMQ来处理我们的异步任务。

• Postgres数据库，使用触发器的数据验证和更新通知，以支持我们的同步协议和长轮询引擎。

• 我们把整个平台都放到了AWS上，并使用Chef作为我们的主要工具来配置服务器，管理部署和组织我们的测试、灰度、线上环境。

一年前，我们使用Docker容器开启了一种新的方式来让我们的测试环境、灰度环境、生产环境更加地一致，同时让我们的部署流程更加简化。

在我们使用容器之前，部署一个Web应用的逻辑是被放在Chef的配置文件里。部署流程大概像这样：

• 设置目录权限。

• 安装Python的依赖组件和依赖包。

• 下载指定标签的Git分支。

• 保留最近的几个版本来确保我们可以快速回滚。

这些Chef的配置文件对于新工程师来说简直是噩梦，因为它们使用一种完全不同的语言（Ruby）的一个非常复杂的框架。

通过使用Docker，我们能够简化Chef管理的部署部分，现在的流程如下：

• 拉取一个指定的Docker镜像到服务器。

• 通过健康检查来停止服务器。

• 停止存在的容器。

• 给新的镜像打一个易读的标签。

• 启动这个镜像（以及所有它的文件系统的映射等等），并使用一个新的名字来命名这个容器（www）。

使用Docker的好处：

• 通过Docker来增强开发者对环境的控制。

• 消除服务器环境的不统一。

• 减少了Chef的配置工作量。

• 集中了部署镜像库而且永远可以对应到某个具体的Git提交。

• 我们持续集成了Docker镜像，所以每一次Code Review通过后总会生成一个可部署的镜像。

• 现在开发者可以修改系统级别的包，而不需要运维团队来做这件事了。

经过两个月的开发和测试，我们在2014年10月初期终于把Docker用到了生产环境，并且运行稳定。

Docker是一个相对比较新的技术，所以你使用过程中难免会遇到一些坑。我在这里总结下我们的经验。

• 务必认真测试你的文件系统。

  这里有一些对Docker可用的文件系统，AUFS被认为是上一代的文件系统，Device Mapper被认为是目前这一代的文件系统。我们发现尽管测试是在本地文件系统，但使用Device Mapper文件系统的时候可能会出现崩溃，同时整个系统也会挂。当然这很可能是内核和发行版的不同所造成的，我们发现AUFS在我们的生产环境中非常地稳定。务必充分地测试你的文件系统尤其是通过在测试环境中不断地重复部署的方式。

• 多次构建Docker镜像以及镜像的大小。

  由于Docker的分层文件系统，所以当你改变某些层的时候，就需要重新构建系统。而相对于你的宝贵时间来说，这样的重复等待工作简直令人郁闷。为了减少构建层以及重构时间，你可以将某些命令整合成单个命令。考虑一下缓存成功构建后的Docker镜像来减少构建的次数吧。

• 务必使用明确的命令来构建和启动容器或者编写Dockerfile。

  我们使用模板来做这件事情。一旦有一些参数要传给docker run，你想要这些参数文档化。当你使用新的Docker版本的时候，你不必去改变这个服务器上的配置文件或者shell的alias，仅仅是代码的改变。

• 镜像文件和容器实例不会自动地回收。

  这已经被谈论了很长时间了，我们发现当我们所有的服务器硬盘神秘变满地时候，我们部署过的每一个镜像依然保存在服务器上直到我们删除它。我们已经使用一些简单的管理脚本来减少磁盘的占用了，直到我们发现了像docker-custodian一样的工具才真正解决了这个问题。

• 考虑把你的镜像分层到多个Dockerfile来加速构建。

  我们前面讨论过镜像缓存，我们已经完成了一个多层Docker镜像策略，这个策略是让镜像之间可以互相继承。

  一些基础镜像，他们包含了一些系统包，构建的过程非常慢，但是这样的镜像也很少改变。

  生产环境中的Web镜像继承自这些基础镜像，同时也包含了一系列的编译好的Python包和某一时刻的源代码快照。这样会快速地构建除非遇到requirements.txt文件的变动，这个变动会触发virtualenv的重新构建。

  开发者的Web镜像继承自生产环境的镜像，并且增加了一些跑selenium测试（Xvcon、google-chrome）的工具和一些开发者的工具。然后开发者利用文件系统将他们的新的代码映射到容器当中，并且在生产环境Web镜像中覆盖快照。

• 遇到紧急情况，你依然可以进入容器内debug你的代码。

  最初当你在容器内跑你的代码的时候，它就像在你跟你的代码之间放了一个隔离层，并且这个隔离层阻止了大量的正常debugging技术。当它不被认为是最佳实践的生产环境系统的时候，当在测试环境（尤其是在开发环境）的时候，你很可能打开一个终端执行docker exec -ti

• 你需要一个日志管理的策略。

  这听起来是一个再普通不过的话题，但是日志管理对于Docker来说是非常棘手的问题。你可以用一些简单的技术去映射宿主机的文件系统到容器中简单地把日志保存在宿主机上，但是当你在这个宿主机上起更多的容器实例的时候这个方法很快就会失败。

  最后，经过大量的实验，我们已经取得巨大的成功，并将应用程序的日志通过UDP直接打到宿主机的syslog上。在Docker 1.7版本之前，做这一件事情需要一个技术来找到syslog宿主机的正确IP地址，后来我们通过传递环境变量解决了这个问题。

总的来说，容器化已经取得了巨大成功。比如说，当Shellshock漏洞被公布的时候，我们的事故响应仅仅是一次容器的构建和一次Chef的执行。尽管发展步履维艰，Docker已经是一个巨大的改变，我们非常乐意继续研究它。有了一个稳定的Web基础构件后，我们已经找到更新更有效率的方法来测试、部署和管理我们的基础构件，同时也找到了更快的开发迭代的方法。我们希望能在今后的文章中分享这些方法，敬请关注吧！