Docker现在越来越流行，但是真正在生产环境部署Docker还是个比较新的概念，还没有一个标准的流程。作者是ROR的程序员，作者结合平时的部署经验，联系Docker的特点，向大家分享了其在生产环境使用Docker部署应用程序的一个实践。

Docker是现在开发应用程序的不错选择；因为对于一个研发组来说，部署一个应用再也不用像以前那样繁琐的修改、设置配置文件了；因为对于Docker来说它“屏蔽”了应用程序的运行环境，不管你使用Mac、Linux还是Windows都能用相同的方式运行。

但是，当你使用Docker将应用部署到生产环境时，你会觉得Docker还是有些“弱”，至少从Ruby On Rails（ROR）的角度出发是这样的。当我查找与测试了很多不同的部署方法与Docker镜像后发现：确实没有一个确切而且标准的部署方案。在这篇文章中我会分享一种生产环境部署ROR应用的最佳实践。

标准

在实际操作之前，我们列举生产环境部署应用的标准：

1.易于使用：部署应用本身应该十分简单，不然部署新程序的过程会变得十分“恐怖”。

2.零服务中断：让我们面对它——零服务中断部署ROR应用程序已经成为当今的标准。

3.自动化部署：我更习惯把代码推送到代码仓库，然后使用Codeship这样的工具自动测试，测试通过后自动将代码部署到生产环境的服务器。我希望Docker能完成相同的工作。
## 操作就像之前我说过的，我希望部署过程越简单越好。如果你看过Docker:Part4这个视频，可能对以下命令有所熟悉，它启动了一个叫db的容器（跑postgres数据库），之后又启动了一个叫web的容器，最后将容器“web”跟容器“db”连接起来。

$ docker run -d --name db training/postgres
$ docker run -i -t --name web --link db:db -p 45000:80

当然如果你照着这么做来部署程序，当你敲了很多次这样的命令后，而且保证不遗漏的敲了很多次这种命令后，你会发现这是个“坑爹的”噩梦。这就是为什么会有Fig的原因。

FIG

如果你用Dockerfile来定义如何生成你的容器，那么Fig则可以帮你定义整个容器的运行框架。Fig将“添加数据卷（add volumes）”、“连接容器”（link container）与“映射端口”等操作都封装到一个YAML的描述文件中；如同前面提到的CodeTV中描述的那个操作在Fig中简化成如下形式：

web:
build: .
ports:
- "80:80"
links:
- db

db:
image: postgres
ports:
- "5432"

volumes:
- /etc/postgresql
- /var/log/postgresql
- /var/lib/postgresql

我在YAML中定义了两个容器：web与db；容器web生成自当前文件夹下的Dockerfile，向外暴露了80号端口，同时链接到了容器db。容器db生成自DockerHub的PostgreSQL镜像，向外暴露5432号端口。使用此YAML配置文件，fig可以用以下命令生成容器，然后依照配置文件的意图启动它们。

$ fig build
$ fig up -d

Fig会先启动被链接的容器db，这样容器web就不至于连不上数据库。-d参数表示以后台运行的方式启动容器，这样可以保证用户登出操作系统后，容器任然在运行。您可以登录Fig的官方网站获取更多的配置信息。

部署

现在我们可以很容易的启动一个Docker容器，但是怎么在生产环境下部署Docker容器呢？如果在生产环境下安装了Fig与Docker，我们所有要做的就是克隆之前的容器镜像，然后用相同的fig命令来启动容器。但是，现在的问题是如何更新线上运行的容器。

不幸的是，Fig可以非常优雅的启动一个容器，但是它并不擅长更新并重启服务。当然，你可以在代码仓库拉取程序的更新，然后重新运行以上的fig命令来达到这个目的；但是，在容器在更新代码，重新启动的过程中，就不能对外提供服务了。为了应对这种情况，我们使用原生的Docker命令，并引入Nginx做反向代理（注：软负载）来解决这个问题。

我们首先把容器监听的端口修改掉，因为Nginx需要监听80号端口。我们这么修改：

web:
build: .
ports:
- "8080:80"
links:
- db
...

通过修改Fig的配置文件，我们的web容器修改成监听8080号端口。而Nginx要配置成8080与8081端口的负载均衡；所以Nginx的配置如下：

upstream docker {
server 127.0.0.1:8080;
server 127.0.0.1:8081;
}

server {
listen 80;
location / {
proxy_pass http://docker;
}
}

重启Nginx后，Nginx就开始在8080与8081号端口之间做反向代理（软负载）；当其中任何一个端口失效后，Nginx将请求自动转发到另一个，直到失效后的端口恢复。这样，我们就能从Git中拉取更新，然后运行下面的命令将其启动：

$ docker run -d --name web1 --link codetvjournal_db_1:db -p 8081:80 codetvjournal_web:latest

当我们确定8081号端口的web1容器启动并服务正常后，我们就可以停止8080号端口的服务并开始为8080号端口服务进行更新了。我推荐使用原生的docker命令而不使用Fig来完成这个工作，因为这样可以避免干扰到正在运行的db容器（注：作者可能指的是之前写好的YAML，里面包含了启动db容器的配置）

我们可以用上述方法创建很多个web容器，只要保证它们占用的端口与容器名不同即可；同时使用Nginx在它们前端做负载即可实现不掉线的程序升级。

自动化

那么问题又来了，怎么将上述的更新流程自动化运行呢？有两个方式可以达到：

1.将容器更新、启停、切换等操作封装到一个单一的脚本中，这个脚本可以加入到传统的上线流程（注：新代码拉取，自动测试，自动部署的流程，作者称之为deployment pipeline）之后执行；

2.另一种方式是，使用类似Consul或者etcd等的发现服务来管理容器的更新，启停，与发现；这会更加“高大上”。

所以，使用Docker在生产环境中部署服务不像你想象中那么容易。我推荐大家试试上面所说的方法；同时分享你自己的实践经验给大家，这会帮助大家一同使用Docker。Docker还是个很年轻的产品，同时又是个非常热门的产品，它肯定会在未来不断的演化升级。