前言

關于Docker的文章鋪天蓋地，但精品文章往往翻譯居多。都說Docker天生適合持續(xù)集成/持續(xù)部署，但同樣，可落地、實際可操作性的文章也很少見。

[[141452]]

基于這些情況，雖然我們專欄定位為運維管理性文字，但本篇是個特例，實操性的案例講解——JAVA項目如何通過Docker實現持續(xù)部署（只需簡單四步），即：

• 開發(fā)同學通過git push上傳代碼，經Git和Jenkins配合，自動完成程序部署、發(fā)布，全程無需運維人員參與。

這是一種真正的容器級的實現，這個帶來的好處，不僅僅是效率的提升，更是一種變革：

• 開發(fā)人員***次真正為自己的代碼負責——終于可以跳過運維和測試部門，自主維護運行環(huán)境（首先是測試/開發(fā)環(huán)境）。

本文是cSphere Docker實戰(zhàn)視頻第二講的文字版，本文聯(lián)合作者@張春源同學（任職cSphere）即為視頻主講人，關于更多系列視頻，詳見https://csphere.cn/training。

福利：點擊“這里”即可手機欣賞本文對應的實戰(zhàn)視頻哦。

難者不會，會者不難。通過簡單的4個配置，即可優(yōu)雅地實現持續(xù)部署。本文依慣例放上目錄，請享用：

1. 持續(xù)部署的技術思路

2. 效果展示

3. 配置Git和Jenkins聯(lián)動

4. 配置Jenkins自動更新代碼

5. 效果圖文詳解

6. FAQ

好吧，我們正式開始。

1. 持續(xù)部署的技術思路

在本例中，假設我們JAVA項目的名稱為hello。簡要的技術思路如下。

本案例中假設代碼托管在git.oschina.com上，Jenkins和Docker Registry（類似于yum源）各運行在一個Docker容器中。JAVA項目自己也單獨運行在一個叫hello的容器中。

本文采取的持續(xù)部署方案，是從私有的Docker Registry拉取代碼，然后通過重建image來實現。這里Jenkins處于中心位置。就像長臂猿，在接收到Git的請求后，通過遠程調用服務器Shell腳本，完成幾乎所有功能。

另外，有些變通的方案，把代碼放在宿主機上，讓容器通過卷組映射來讀取。這種方法不建議的原因是，將代碼拆分出容器，這違背了Docker的集裝箱原則：

這也導致裝卸復雜度增加。從貨運工人角度考慮，整體才是最經濟的。這樣，也才能實現真正意義的容器級遷移。

或者說，容器時代，拋棄過去文件分發(fā)的思想，才是正途。本文***的問答環(huán)節(jié)對此有更多闡述。

容器即進程。我們采用上述方案做Docker持續(xù)部署的原因和意義，也在于此。容器的生命周期，應該遠遠短于虛擬機，容器出現問題，應該是立即殺掉，而不是試圖恢復。

#p#

2. 效果展示

本文***實現的效果，究竟有多驚艷呢？且看如下的演示。

2.1 程序代碼更新前的效果

我們以時間戳來簡潔、顯式的表述程序更新情況。

2.2 提交程序代碼更新

本例中，我們把首頁的時間戳從201506181750，修改為201506191410（見如下）。

2.3 上傳新代碼到Git

順序執(zhí)行如下操作，輸入正確的git賬號密碼。

然后呢？

然后什么都不用做了。端杯茶（如果不喜歡咖啡的話），靜靜地等待自動部署的發(fā)生， 旁觀一系列被自動觸發(fā)的過程，機器人似的運轉起來（請容稍候再加以描述）。

為什么需要3~5分鐘？只是因為本案例中的JAVA項目，需要從國外download Maven程序包，以供Jenkins調用和編譯JAVA。正式應用環(huán)境中，可以把Maven源放在國內或機房。如果僅僅需要對PHP項目做持續(xù)部署，那就更快捷了。

2.4 查看代碼更新后的效果

在靜靜地等待幾分鐘后，新的代碼確實已經自動部署完畢。

那么，這一切怎么實現的呢？很復雜么？不然。只要按照如下幾步，便可快速實現哦。

#p#

3. 配置Git和Jenkins聯(lián)動

這個過程主要分為如下三步。

3.1 Jenkins配置Git源

Jenkins中新建項目java-app，并配置從Git拉取程序代碼。具體如下：

3.2 Jenkins配置遠程構建

Jenkins中配置token，以供git遠程調用時使用。

3.3 Git開啟鉤子

怎么讓Git在接收到用戶更新的代碼后，把消息和任務傳遞給Jenkins呢？這借助于Git的hook功能，配置起來也非常簡單，如下。

4. 配置Jenkins自動更新代碼

Jenkins的主要工作是配置“遠程構建”。在接收到Git傳遞過來的消息后，觸發(fā)這個遠程構建（到目標服務器），按照預定義的任務列表，執(zhí)行一系列的工作，重建容器等。詳見如下：

#p#

我們把其中最關鍵的Shell腳本內容摘抄出來。這些Docker相關操作，在第1部分“技術思路”已經提及，不再贅述。

5. 效果圖文詳解

在2.3這個章節(jié)中，我們當時的操作如下，這個目的是向Git提交更新代碼。

當時并沒有細說后續(xù)發(fā)生的事情，既然上面已經說清楚了原理，那我們就可以接下來說說實際發(fā)生的事情啦。

5.1 上傳代碼到Git

這里貌似整個過程已經完成并順利退出。其實，后臺的工作才剛剛開始哦。

這時會觸發(fā)Git服務器向相應的Jenkins服務器發(fā)出一個操作請求，此工作太過迅速，也沒啥好說的，我們接下來看Jenkins都干啥子了。

5.2 Jenkins進行的精彩互動

如下這個自動運轉的過程，讓我們有些許成就感，值得端杯咖啡（如果不喜歡茶的話），靜靜觀賞。

1）Jenkins會自動”冒出來”一個構建任務。

2）我們點進來，看看具體操作日志。是的，正在接受來自Git的任務。

3）下載Maven相關的軟件包（就是這個過程慢）。

#p#

4）下載完成后，就開始利用maven BUILD 新的hello項目包。

5）然后重建Maven容器，構建新的Image并Push到Docker私有庫中。

6）***，重新把Docker容器拉起來。這樣，又新生了。呵呵

6. FAQ

問題1：采用這么相對復雜的辦法（而不是把更新代碼放在宿主機然后卷組映射），是因為項目基于JAVA么；是否PHP項目就可以采用更新代碼放在宿主機然后卷組映射這種方式？

回答1：將代碼拆分出容器，違背了集裝箱原則。導致裝卸復雜度增加。從貨運工人角度考慮，整體才是最經濟的。一切版本化。拋棄過去的文件分發(fā)。這是正途。至于文件大小，大的war包也就50M或100M，在現有網絡下不成問題，性能問題***優(yōu)化。另外建議關注docker 2 docker，p2p傳輸。

問題2：如果整體代碼超過500m或者1g以上，整體集裝箱是否就不太好了？如果容器與代碼分離，鏡像就100m左右（2層，base+服務），然后代碼的話，是放到共享存儲里，每個代碼有更新，比如svn的代碼，可以直接在共享存儲里進行svn update就可以控制版本

回答2：如果你的代碼500M，那只能說明業(yè)務開發(fā)該打板子了。

問題3：如果測試環(huán)境使用您提供的完整集裝箱服務還行，但在生產環(huán)境，集群里運行docker做應用，如果每個容器都是有完整的代碼，是否有點臃腫，不如每個集群節(jié)點里就運行基礎服務鏡像，通過卷組功能綁定共享存儲里的代碼，加上Crontab、Python和Shell腳本，這樣每次代碼更新就1次就行了。

回答3：環(huán)境一致性，在過去從來沒有解決好。10年前我們做paas時，和這個做法類似。不是說不好，時代變了，用腳本東拼西湊，終究難有好的系統(tǒng)。不能只考慮現在的方便，容器技術和vm如果類比，我覺得會讓自己下決定時很糾結。

補充3：腳本一般是典型的運維工程師思維，quick & dirty。一般很難做成一個產品或者系統(tǒng)。整體考慮和擴展性考慮都比較少。現在做docker的難點在于到底怎么看待它。到底是拿它做調度的基本單位，還是部署的基本單位？考慮清楚，再聊方案。

備注：上述問題的回答，主要由王利俊@cSphere和陳爾冬@華為完成。

關于作者

蕭田國，男，碩士畢業(yè)于北京科技大學，觸控科技運維負責人。擁有十多年運維及團隊管理經驗。先后就職于聯(lián)想集團、搜狐暢游、智明星通及世紀互聯(lián)等。曾經的云計算行業(yè)從業(yè)者，現在喜歡琢磨云計算及評測、云端數據庫，及新技術在運維中的應用。主張管理學科和運維體系的融合、人性化運維管理，打造高效、專業(yè)運維團隊。

張春源，目前任職cSphere。國內最早期的Docker實踐者，在生產環(huán)境擁有一年多的Docker容器管理經歷。深刻理解Docker對于開發(fā)、測試以及運維的價值。擅長利用Docker構建整個DevOps自動化平臺。熱愛專研Dockerfile這門藝術，并對CoreOS有深入研究。

歡迎關注“cSphere”微信公眾號，以***時間獲取本系列視頻的***內容，并獲得***手的Docker容器管理方案。

如何一起愉快地發(fā)展

高效運維系列微信群是國內高端運維圈子、運維行業(yè)垂直社交的典范。現有成員1000余名，其中運維總監(jiān)及以上級別成員300多名。

“高效運維”公眾號值得您的關注，作為高效運維系列微信群的唯一官方公眾號，每周發(fā)表多篇干貨滿滿的原創(chuàng)好文：來自于系列群的討論精華、運維講壇線上/線下活動精彩分享及部分群友原創(chuàng)。“高效運維”也是互聯(lián)網專欄《高效運維***實踐》及運維2.0官方公眾號。

提示：目前高效運維兩個微信主群僅有少量珍貴席位，***運維資深專家。如您愿意，可添加蕭田國個人微信號 xiaotianguo 為好友以做申請；也可加入我們聊聊群（技術討論為主，規(guī)矩少，氣氛熱烈）。

重要提示：除非事先獲得授權，請在本公眾號發(fā)布2天后，才能轉載本文。尊重知識，請必須全文轉載，并包括本行及如下二維碼。

題圖來自：blog.nicescale.com

如果您對“這里”彈出的實戰(zhàn)視頻有任何問題，歡迎通過 https://csphere.cn/training 進行互動討論。謝謝！