Docker —— Git 部署

123次阅读

共计 8292 个字符，预计需要花费 21 分钟才能阅读完成。

我一直听说 Docker 是个很棒的新事物，但是我一直提不起兴趣，直到我遇到一个切实的问题：如果通过 Docker 来部署 Scout， 这么做会轻松一些吗？

下面我将分三部分来阐述。

哇哦, 有效的模拟生产环境的方法

Docker —— Git 部署

真实生产环境中有 16 台服务器。如果我尝试用虚拟机去模拟的话，每个 VirtualBox 实例最好能有 512MB 内存。这样的内存需求是我笔记本内存的两倍大。此外VirtualBox 还有许多限制，比如使用单独的系统内核和文件系统。但是这些限制对于 Docker 都不算个事，Docker 的containers 是共享一个宿主机器的系统的，甚至可能是同一个程序和库。一台 Docker 宿主机器上运行数百个 containers 也不是什么问题。

老办法

我实在没办法在本地模拟一个完全真实的环境，但是我们只要看一下启动一台虚拟机使用的时间：

$time vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'squeeze64-ruby193'...
...
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.
...

real  1m32.052s

启动一个镜像超过了一分半钟。那我要简单修改下配置怎么办啊？那我要验证下可行性呢，那是不是又得重启？又是一分半钟了啊。

这分明就是个残酷的惩罚嘛。

使用 Docker

Docker 到底有多么轻量级? 当你在 Docker container 中运行个进程时，你甚至都可能忘记这个进程竟然不是直接运行在主机上的。在下面的例子中，我运行一个叫“rails”的镜像在 Docker container 中，那里是个 Rails App (Dockerfile):

root@precise64:~# docker run rails
2013-08-26 20:21:14,600 CRIT Supervisor running as root (no user in config file)
2013-08-26 20:21:14,603 WARN Included extra file "/srv/docker-rails/Supervisorfile" during parsing
2013-08-26 20:21:14,736 INFO RPC interface 'supervisor' initialized
2013-08-26 20:21:14,740 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2013-08-26 20:21:14,754 INFO supervisord started with pid 1
2013-08-26 20:21:15,783 INFO spawned: 'rails' with pid 10
2013-08-26 20:21:16,841 INFO success: rails entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

开始 container 和启动 supervisor (这是负责开始 Rails app 的)一个只用了 2 秒

简而言之，Docker 绝对胜任在你的开发电脑上虚拟出一个完整的生产环境，而且很快。既然这么简单，来，开动起来吧：我要彻底测试一下

构建镜像如此方便快捷 – 缓存万岁!

Docker —— Git 部署

Docker 的详细介绍：请点这里
Docker 的下载地址：请点这里

开源项目 Docker，Red Hat 新的虚拟化选择 http://www.linuxidc.com/Linux/2013-10/91051.htm

dockerlite: 轻量级 Linux 虚拟化 http://www.linuxidc.com/Linux/2013-07/87093.htm

Docker 的搭建 Gitlab CI 全过程详解 http://www.linuxidc.com/Linux/2013-12/93537.htm

Docker 和一个正常的虚拟机有何区别? http://www.linuxidc.com/Linux/2013-12/93740.htm

Docker 将改变所有事情 http://www.linuxidc.com/Linux/2013-12/93998.htm

老方法

如果你想把从空镜像到一个功能镜像的构建过程脚本化（例如：在 Ubuntu 上怎么安装一个 Rails stack），要是你不是经常干这事，那么正确获得所有的流，这绝对会是个痛苦的活儿。看看为 Ruby 安装依赖吧:

$time apt-get install -y -q ruby1.9.1 ruby1.9.1-dev rubygems1.9.1 irb1.9.1 build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g-dev
Reading package lists...
Building dependency tree...
The following extra packages will be installed:
....
Setting up libalgorithm-merge-perl (0.08-2) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place

real 1m22.470s

然后，你想装了 NodeJS 的依赖，但是忘了给 apt 添加源了：

$apt-get install -y nodejs
...
E: Unable to locate package nodejs

解决了源的问题后，你得确认你的脚本在新镜像中会不会有问题。那么你需要重装 Ruby，好吧，又要浪费 82 秒了。正是神烦。

使用 Docker

在 Docker 中，是把构建镜像的步骤放到 Dockerfile. Dockerfiles 是非常容易阅读的，因为你根本不需要学习 DSL – 这就是些你输入时记录下来的基本命令。第一次安装 Ruby 会有点麻烦，但是让我们看看，通过 Dockerfile 来构建余下的镜像会发生什么:

FROM ubuntu:12.04
RUN apt-get update

## MYSQL
RUN apt-get install -y -q mysql-client libmysqlclient-dev

## RUBY
RUN apt-get install -y -q ruby1.9.1 ruby1.9.1-dev rubygems1.9.1 irb1.9.1 build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g-dev

root@precise64:/# time docker build -t="dlite/appserver" .
Uploading context 92160 bytes
Step 1 : FROM ubuntu:12.04
 ---> 8dbd9e392a96
Step 2 : RUN apt-get update
 ---> Using cache
 ---> b55e9ee7b959
Step 3 : RUN apt-get install -y -q mysql-client libmysqlclient-dev
 ---> Using cache
 ---> dc92be6158b0
Step 4 : RUN apt-get install -y -q ruby1.9.1 ruby1.9.1-dev rubygems1.9.1 irb1.9.1 build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g-dev
 ---> Using cache
 ---> 7038022227c0
Successfully built 7038022227c0

real    0m0.848s

哇哦 – 太不可思议了，怎么可能不到一秒钟就安装好了啊？看到这些缓存的 keys(ex:dc92be6158b0)了吗? 其实根本没有重新逐条执行 Dockerfile 中命令, Docker 认为这些命令已经执行过了，就不再执行，只是从缓存区中得到文件系统上的变化，通过这些变化可以组合出完整的文件系统。Docker 之所以能可以这样神奇，关键在于 AuFS file system，这是一个联合文件系统（类似于记录变化，然后通过变化来组合出原貌）。

总而言之，Docker 可以轻松地反复构建镜像，而且之后的构建过程，你几乎无需等待。人无完人，我时常犯错，但是 Docker 却从不惩罚我的过失。

部署镜像, 别更新基础环境

老办法

像许多其他部署一样，Scout 也使用长期运行的虚拟机。我们通过 Puppet 来更新基础环境，但是, 这经常比我们想象得要痛苦：

如果我们要更新 stack, Puppet 将运行虚拟机然后更新。这将花费很长时间 - 即使只是一小部分的 stack 需要更新，但是 Puppet 仍然会检查全部。
部署过程中也可能有问题。如果我们正在安装 Memcached，突然网络中断了一小下，那么 apt-get install memcached 的指令可能就会无效了。
回滚主要变化，这也时常不是想象中那么顺利(像更新 Ruby 版本).

这些都是 Puppet’s 的毛病 – 像 Puppet 或者 Chef 这样的工具是非常重要，特别当你有着一些长时间运行的虚拟机，这些虚拟机可能随着时间的推移出现不一致的情况，那么这些工具就更重要了。

我一直听说 Docker 是个很棒的新事物，但是我一直提不起兴趣，直到我遇到一个切实的问题：如果通过 Docker 来部署 Scout， 这么做会轻松一些吗？

下面我将分三部分来阐述。

哇哦, 有效的模拟生产环境的方法

Docker —— Git 部署

真实生产环境中有 16 台服务器。如果我尝试用虚拟机去模拟的话，每个 VirtualBox 实例最好能有 512MB 内存。这样的内存需求是我笔记本内存的两倍大。此外VirtualBox 还有许多限制，比如使用单独的系统内核和文件系统。但是这些限制对于 Docker 都不算个事，Docker 的containers 是共享一个宿主机器的系统的，甚至可能是同一个程序和库。一台 Docker 宿主机器上运行数百个 containers 也不是什么问题。

老办法

我实在没办法在本地模拟一个完全真实的环境，但是我们只要看一下启动一台虚拟机使用的时间：

$time vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'squeeze64-ruby193'...
...
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.
...

real  1m32.052s

启动一个镜像超过了一分半钟。那我要简单修改下配置怎么办啊？那我要验证下可行性呢，那是不是又得重启？又是一分半钟了啊。

这分明就是个残酷的惩罚嘛。

使用 Docker

Docker 到底有多么轻量级? 当你在 Docker container 中运行个进程时，你甚至都可能忘记这个进程竟然不是直接运行在主机上的。在下面的例子中，我运行一个叫“rails”的镜像在 Docker container 中，那里是个 Rails App (Dockerfile):

root@precise64:~# docker run rails
2013-08-26 20:21:14,600 CRIT Supervisor running as root (no user in config file)
2013-08-26 20:21:14,603 WARN Included extra file "/srv/docker-rails/Supervisorfile" during parsing
2013-08-26 20:21:14,736 INFO RPC interface 'supervisor' initialized
2013-08-26 20:21:14,740 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2013-08-26 20:21:14,754 INFO supervisord started with pid 1
2013-08-26 20:21:15,783 INFO spawned: 'rails' with pid 10
2013-08-26 20:21:16,841 INFO success: rails entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

开始 container 和启动 supervisor (这是负责开始 Rails app 的)一个只用了 2 秒

简而言之，Docker 绝对胜任在你的开发电脑上虚拟出一个完整的生产环境，而且很快。既然这么简单，来，开动起来吧：我要彻底测试一下

构建镜像如此方便快捷 – 缓存万岁!

Docker —— Git 部署

Docker 的详细介绍：请点这里
Docker 的下载地址：请点这里

开源项目 Docker，Red Hat 新的虚拟化选择 http://www.linuxidc.com/Linux/2013-10/91051.htm

dockerlite: 轻量级 Linux 虚拟化 http://www.linuxidc.com/Linux/2013-07/87093.htm

Docker 的搭建 Gitlab CI 全过程详解 http://www.linuxidc.com/Linux/2013-12/93537.htm

Docker 和一个正常的虚拟机有何区别? http://www.linuxidc.com/Linux/2013-12/93740.htm

Docker 将改变所有事情 http://www.linuxidc.com/Linux/2013-12/93998.htm

使用 Docker

部署镜像 – 不用修改存在的虚拟机。你可以 100% 确保，本地运行什么，相应的生产环境就会运行什么。

但是镜像很大，对吗？不要整个 Docker- 记住 containers 不是运行在自己的操作系统上的，还有我们使用的是联合文件系统。当我们对于镜像做出改变时，我们只需要在上面添加新的层。

例如，我们安装 Memcached 在 app 服务器上。我们构建了一个新的镜像。我会标注 asdlite/appserver-memcached，dliteis 是我的 index.docker.io 用户名，这是基于 dite/appserver 镜像的。

root@precise64:/# time docker build -t="dlite/appserver-memcached" .
Uploading context 92160 bytes
Step 1 : FROM appserver
 ---> 8dbd9e392a96
Step 2 : RUN apt-get update
 ---> Using cache
 ---> b55e9ee7b959
Step 3 : RUN apt-get install -y -q memcached
 ---> Running in 2a2a689daee3
Reading package lists...
Building dependency tree...
...
Starting memcached: memcached.
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
 ---> 2a2a689daee3
Successfully built 2a2a689daee3

real    0m13.289s
user    0m0.132s
sys 0m0.376s

只要 13 秒就能安装好 Memcached，这是因为之前的 Dockerfile 被缓存了，我爱这种速度的感觉。

我会上传和提交这些:

root@precise64:/# time docker push dlite/appserver-memcached
The push refers to a repository [dlite/appserver-memcached] (len: 1)
Processing checksums
Sending image list
Pushing repository dlite/appserver-memcached (1 tags)
Pushing 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c
Image 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c already pushed, skipping
...
Pushing tags for rev [ad8f8a3809afcf0e2cff1af93a8c29275a847609b05b20f7b6d2a5cbd32ff0d8] on {https://registry-1.docker.io/v1/repositories/dlite/appserver-memcached/tags/latest}

real    0m28.710s

在生产环境中的机器上，我把镜像下载下来:

root@prod:/# time docker pull dlite/appserver-memcached
Pulling repository dlite/appserver-memcached
Pulling image ad8f8a3809afcf0e2cff1af93a8c29275a847609b05b20f7b6d2a5cbd32ff0d8 (latest) from dlite/appserver-memcached

real    0m15.749s

只用了 15 秒就获得了 dlite/appserver-memachedimage。注意那个镜像只有 10MB 大小，使用 app 服务器镜像作为基础镜像:

root@precise64:~# docker images
REPOSITORY            TAG                 ID                  CREATED             SIZE
appserver             latest              7038022227c0        3 days ago          78.66 MB (virtual 427.9 MB)
appserver-memcached   latest              77dc850dcccc        16 minutes ago      10.19 MB (virtual 438.1 MB)

我们没有必要将整个 Memcached 镜像都下载下来, 只要将 Memcached 镜像中的改变添加到 dlite/appserver 镜像中。

绝大多数时间，我们做出的改变会小得多。所以下载一个新镜像会更快。

这些会有很大的作用:

开始新的 Docker containers 是非常快的
上传 + 下载新的 Docker 镜像要轻量级的

并非要改变现在运行的虚拟机，我们只是开始新的 containers，停止旧的 containers.

Docker —— Git 部署

的确震惊! 这意味着我不需要担心一致性问题 – 我们不会修改运行的虚拟机，只是开始新的 containers。这意味着可以轻松回滚！Memcached 失败了？停止运行 dlite/appserver-memcached 的 container，开始一个新 container 运行 dlite/appserver 镜像。