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还是个很年轻的产品,同时又是个非常热门的产品,它肯定会在未来不断的演化升级。

点赞(149)

评论列表共有 0 条评论

立即
投稿
返回
顶部