我一直聽說Docker是個(gè)很棒的新事物，但是我一直提不起興趣，直到我遇到一個(gè)切實(shí)的問題： 如果通過Docker來部署 Scout ，這么做會(huì)輕松一些嗎？

下面我將分三部分來闡述。

哇哦, 有效的模擬生產(chǎn)環(huán)境的方法

真實(shí)生產(chǎn)環(huán)境中有16臺(tái)服務(wù)器。如果我嘗試用虛擬機(jī)去模擬的話，每個(gè)VirtualBox實(shí)例***能有512MB內(nèi)存。這樣的內(nèi)存需求是我筆記本內(nèi)存的兩倍大。此外VirtualBox還有許多限制，比如使用單獨(dú)的系統(tǒng)內(nèi)核和文件系統(tǒng)。但是這些限制對于Docker都不算個(gè)事，Docker的containers是共享一個(gè)宿主機(jī)器的系統(tǒng)的，甚至可能是同一個(gè)程序和庫。一臺(tái)Docker宿主機(jī)器上運(yùn)行數(shù)百個(gè)containers也不是什么問題。

老辦法

我實(shí)在沒辦法在本地模擬一個(gè)完全真實(shí)的環(huán)境，但是我們只要看一下啟動(dòng)一臺(tái)虛擬機(jī)使用的時(shí)間：

$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 

啟動(dòng)一個(gè)鏡像超過了一分半鐘。那我要簡單修改下配置怎么辦??？那我要驗(yàn)證下可行性呢，那是不是又得重啟？又是一分半鐘了啊。

這分明就是個(gè)殘酷的懲罰嘛。

使用Docker

Docker到底有多么輕量級(jí)? 當(dāng)你在Docker container中運(yùn)行個(gè)進(jìn)程時(shí)，你甚至都可能忘記這個(gè)進(jìn)程竟然不是直接運(yùn)行在主機(jī)上的。在下面的例子中，我運(yùn)行一個(gè)叫“rails”的鏡像在Docker container中，那里是個(gè)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和啟動(dòng)supervisor (這是負(fù)責(zé)開始Rails app的)一個(gè)只用了2秒

簡而言之，Docker絕對勝任在你的開發(fā)電腦上虛擬出一個(gè)完整的生產(chǎn)環(huán)境，而且很快。既然這么簡單，來，開動(dòng)起來吧：我要徹底測試一下

構(gòu)建鏡像如此方便快捷 - 緩存萬歲!

老方法

如果你想把從空鏡像到一個(gè)功能鏡像的構(gòu)建過程腳本化（例如：在Ubuntu上怎么安裝一個(gè)Rails stack），要是你不是經(jīng)常干這事，那么正確獲得所有的流，這絕對會(huì)是個(gè)痛苦的活兒。看看為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 

解決了源的問題后，你得確認(rèn)你的腳本在新鏡像中會(huì)不會(huì)有問題。那么你需要重裝Ruby，好吧，又要浪費(fèi)82秒了。正是神煩。

使用Docker

在Docker中，是把構(gòu)建鏡像的步驟放到Dockerfile. Dockerfiles是非常容易閱讀的，因?yàn)槟愀静恍枰獙W(xué)習(xí)DSL - 這就是些你輸入時(shí)記錄下來的基本命令。***次安裝Ruby會(huì)有點(diǎn)麻煩，但是讓我們看看，通過Dockerfile來構(gòu)建余下的鏡像會(huì)發(fā)生什么:

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 

#p#

部署鏡像, 別更新基礎(chǔ)環(huán)境

老辦法

像許多其他部署一樣，Scout也使用長期運(yùn)行的虛擬機(jī)。我們通過Puppet來更新基礎(chǔ)環(huán)境，但是, 這經(jīng)常比我們想象得要痛苦：

• 如果我們要更新stack, Puppet將運(yùn)行虛擬機(jī)然后更新。這將花費(fèi)很長時(shí)間-即使只是一小部分的stack需要更新，但是Puppet仍然會(huì)檢查全部。
• 部署過程中也可能有問題。如果我們正在安裝Memcached，突然網(wǎng)絡(luò)中斷了一小下，那么apt-get install memcached的指令可能就會(huì)無效了。
• 回滾主要變化，這也時(shí)常不是想象中那么順利(像更新Ruby版本).

這些都是Puppet's的毛病 - 像Puppet或者Chef這樣的工具是非常重要，特別當(dāng)你有著一些長時(shí)間運(yùn)行的虛擬機(jī)，這些虛擬機(jī)可能隨著時(shí)間的推移出現(xiàn)不一致的情況，那么這些工具就更重要了。

使用Docker

部署鏡像 - 不用修改存在的虛擬機(jī)。你可以100%確保，本地運(yùn)行什么，相應(yīng)的生產(chǎn)環(huán)境就會(huì)運(yùn)行什么。

但是鏡像很大，對嗎？不要整個(gè)Docker-記住containers不是運(yùn)行在自己的操作系統(tǒng)上的，還有我們使用的是聯(lián)合文件系統(tǒng)。當(dāng)我們對于鏡像做出改變時(shí)，我們只需要在上面添加新的層。

例如，我們安裝Memcached在app服務(wù)器上。我們構(gòu)建了一個(gè)新的鏡像。我會(huì)標(biāo)注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 

只要13秒就能安裝好Memcached，這是因?yàn)橹暗腄ockerfile被緩存了，我愛這種速度的感覺。

我會(huì)上傳和提交這些：

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 

在生產(chǎn)環(huán)境中的機(jī)器上，我把鏡像下載下來：

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。注意那個(gè)鏡像只有10MB大小，使用app服務(wù)器鏡像作為基礎(chǔ)鏡像：

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) 

我們沒有必要將整個(gè)Memcached鏡像都下載下來, 只要將Memcached鏡像中的改變添加到dlite/appserver鏡像中。

絕大多數(shù)時(shí)間，我們做出的改變會(huì)小得多。所以下載一個(gè)新鏡像會(huì)更快。

這些會(huì)有很大的作用：

• 開始新的Docker containers是非?？斓?/li>
• 上傳+下載新的Docker鏡像要輕量級(jí)的

并非要改變現(xiàn)在運(yùn)行的虛擬機(jī)，我們只是開始新的containers，停止舊的containers.

的確震驚! 這意味著我不需要擔(dān)心一致性問題 - 我們不會(huì)修改運(yùn)行的虛擬機(jī)，只是開始新的containers。這意味著可以輕松回滾！Memcached失敗了？停止運(yùn)行 dlite/appserver-memcached的container，開始一個(gè)新container運(yùn)行dlite/appserver鏡像。

不足之處

在短暫的containers上工作，這會(huì)導(dǎo)致一系列新問題- 分布式配置 / 協(xié)調(diào)和服務(wù)發(fā)現(xiàn):

• 當(dāng)一個(gè)新的app服務(wù)器containers開始后，我們改如何更新HAProxy配置?
• 當(dāng)一個(gè)新的數(shù)據(jù)庫container開始后，app服務(wù)器應(yīng)該如何與數(shù)據(jù)container來通信?
• 如何跨越Docker宿主機(jī)器通信?

即將發(fā)布的Flynn.io，那會(huì)使用etcd，將會(huì)有幫助。但是，在小規(guī)模部署的時(shí)候沒必要擔(dān)心這些。

總結(jié)一下: Docker來部署Git來開發(fā)

當(dāng)開發(fā)應(yīng)用的時(shí)候，開發(fā)者可以利用Git的性能和靈活性。Git鼓勵(lì)嘗試，不會(huì)因?yàn)槟愠鲥e(cuò)而懲罰你：在一個(gè)分支開始試驗(yàn)，如果失敗了，只要git rebase或者git reset回復(fù)一下。開始一個(gè)分支非常簡單，上傳也很快速。 

Docker鼓勵(lì)對于操作的試驗(yàn)。Containers的啟動(dòng)非?？焖佟?構(gòu)建鏡像簡簡單單，使用另一個(gè)鏡像作為基礎(chǔ)鏡像也非常容易。部署整個(gè)鏡像非?？焖?。***，回滾輕輕松松。

快速+靈活= 部署即將成為令人愉快的事。

原文鏈接：http://www.oschina.net/translate/docker-git-for-deployment

譯文鏈接：http://www.oschina.net/translate/docker-git-for-deployment