在生產環境使用Docker部署應用

導讀	Docker現在越來越流行，但是真正在生產環境部署Docker還是個比較新的概念，還沒有一個標準的流程。作者是ROR的程式設計師，作者結合平時的部署經驗，聯絡Docker的特點，向大家分享了其在生產環境使用Docker部署應用程式的一個實踐。

Docker是現在開發應用程式的不錯選擇；因為對於一個研發組來說，部署一個應用再也不用像以前那樣繁瑣的修改、設定配置檔案了；因為對於Docker來說它“遮蔽”了應用程式的執行環境，不管你使用Mac、 還是Windows都能用相同的方式執行。

但是，當你使用Docker將應用部署到生產環境時，你會覺得Docker還是有些“弱”，至少從Ruby On Rails（ROR）的角度出發是這樣的。當我查詢與測試了很多不同的部署方法與Docker映象後發現：確實沒有一個確切而且標準的部署方案。在這篇文章中我會分享一種生產環境部署ROR應用的最佳實踐。

在實際操作之前，我們列舉生產環境部署應用的標準：

1. 易於使用：部署應用本身應該十分簡單，不然部署新程式的過程會變得十分“恐怖”。
2. 零服務中斷：讓我們面對它——零服務中斷部署ROR應用程式已經成為當今的標準。
3. 自動化部署：我更習慣把程式碼推送到程式碼倉庫，然後使用Codeship這樣的工具自動測試，測試透過後自動將程式碼部署到生產環境的伺服器。我希望Docker能完成相同的工作。

   ## 操作就像之前我說過的，我希望部署過程越簡單越好。如果你看過 這個影片，可能對以下 有所熟悉，它啟動了一個叫db的容器（跑postgres資料庫），之後又啟動了一個叫web的容器，最後將容器“web”跟容器“db”連線起來。

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

當然如果你照著這麼做來部署程式，當你敲了很多次這樣的 後，而且保證不遺漏的敲了很多次這種命令後，你會發現這是個“坑爹的”噩夢。這就是為什麼會有 的原因。

如果你用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 
}
}

重啟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還是個很年輕的產品，同時又是個非常熱門的產品，它肯定會在未來不斷的演化升級。

原文來自：