共計 2608 個字符，預計需要花費 7 分鐘才能閱讀完成。
這篇文章主要介紹“Docker 持續部署的技術是什么”，在日常操作中，相信很多人在 Docker 持續部署的技術是什么問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Docker 持續部署的技術是什么”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！
1. 持續部署的技術思路
在本例中，假設我們 JAVA 項目的名稱為 hello。簡要的技術思路如下。
本案例中假設代碼托管在 git.oschina.com 上，Jenkins 和 Docker Registry（類似于 yum 源）各運行在一個 Docker 容器中。JAVA 項目自己也單獨運行在一個叫 hello 的容器中。
本文采取的持續部署方案，是從私有的 Docker Reistry 拉取代碼。有些變通的方案，把代碼放在宿主機上，讓容器通過卷組映射來讀取。這種方法不建議的原因是，將代碼拆分出容器，這違背了 Docker 的集裝箱原則：
這也導致裝卸復雜度增加。從貨運工人角度考慮，整體才是最經濟的。這樣，也才能實現真正意義的容器級遷移。
或者說，容器時代，拋棄過去文件分發的思想，才是正途。本文最后的問答環節對此有更多闡述。
容器即進程。我們采用上述方案做 Docker 持續部署的原因和意義，也在于此。容器的生命周期，應該遠遠短于虛擬機，容器出現問題，應該是立即殺掉，而不是試圖恢復。
2. 效果展示
本文最后實現的效果，究竟有多驚艷呢？且看如下的演示。
2.1 程序代碼更新前的效果
我們以時間戳來簡潔、顯式的表述程序更新情況。
2.2 提交程序代碼更新
本例中，我們把首頁的時間戳從 201506181750，修改為 201506191410（見如下）。
2.3 上傳新代碼到 Git
順序執行如下操作，輸入正確的 git 賬號密碼。
然后呢？
然后什么都不用做了。端杯茶（如果不喜歡咖啡的話），靜靜地等待自動部署的發生，旁觀一系列被自動觸發的過程，機器人似的運轉起來（請容稍候再加以描述）。
為什么需要 3~5 分鐘？只是因為本案例中的 JAVA 項目，需要從國外 download Maven 程序包，以供 Jenkins 調用和編譯 JAVA。正式應用環境中，可以把 Maven 源放在國內或機房。如果僅僅需要對 PHP 項目做持續部署，那就更快捷了。
2.4 查看代碼更新后的效果
在靜靜地等待幾分鐘后，新的代碼確實已經自動部署完畢。
那么，這一切怎么實現的呢？很復雜么？不然。只要按照如下幾步，便可快速實現哦。
3. 配置 Git 和 Jenkins 聯動
這個過程也是難者不會，會者不難。主要分為如下三步。
3.1 Jenkins 配置 Git 源
Jenkins 中新建項目 java-app，并配置從 Git 拉取程序代碼。具體如下：
3.2 Jenkins 配置遠程構建
Jenkins 中配置 token，以供 git 遠程調用時使用。
3.3 Git 開啟鉤子
怎么讓 Git 在接收到用戶更新的代碼后，把消息和任務傳遞給 Jenkins 呢？這借助于 Git 的 hook 功能，配置起來也非常簡單，如下。
4. 配置 Jenkins 自動更新代碼
Jekins 在接收到 Git 傳遞過來的消息后，再觸發一個遠程構建（到目標服務器），按照預定義的任務列表，執行一系列的工作，重建容器等。詳見如下：
我們把其中最關鍵的 Shell 腳本內容摘抄出來。
5. 效果圖文詳解
在 2.3 這個章節中，我們當時的操作如下，這個目的是向 Git 提交更新代碼。
當時并沒有細說后續發生的事情，既然上面已經說清楚了原理，那我們就可以接下來說說實際發生的事情啦。
5.1 上傳代碼到 Git
這里貌似整個過程已經完成并順利退出。其實，后臺的工作才剛剛開始哦。
這時會觸發 Git 服務器向相應的 Jenkins 服務器發出一個操作請求，此工作太過迅速，也沒啥好說的，我們接下來看 Jenkins 都干啥子了。
5.2 Jenkins 進行的精彩互動
1）Jenkins 會自動冒出來一個構建任務。
2）我們點進來，看看具體操作日志。是的，正在接受來自 Git 的任務。
3）下載 Maven 相關的軟件包（就是這個過程慢）。
4）下載完成后，就開始利用 maven BUILD 新的 hello 項目包。
5）然后重建 Maven 容器，構建新的 Image 并 Push 到 Docker 私有庫中。
6）最后，重新把 Docker 容器拉起來。這樣，又新生了。呵呵
6. FAQ
問題 1：采用這么相對復雜的辦法（而不是把更新代碼放在宿主機然后卷組映射），是因為項目基于 JAVA 么；是否 PHP 項目就可以采用更新代碼放在宿主機然后卷組映射這種方式？
回答 1：將代碼拆分出容器，違背了集裝箱原則。導致裝卸復雜度增加。從貨運工人角度考慮，整體才是最經濟的。一切版本化。拋棄過去的文件分發。這是正途。至于文件大小，大的 war 包也就 50M 或 100M，在現有網絡下不成問題，性能問題最好優化。另外建議關注 docker 2 docker，p2p 傳輸。
問題 2：如果整體代碼超過 500m 或者 1g 以上，整體集裝箱是否就不太好了？如果容器與代碼分離，鏡像就 100m 左右（2 層，base+ 服務），然后代碼的話，是放到共享存儲里，每個代碼有更新，比如 svn 的代碼，可以直接在共享存儲里進行 svn update 就可以控制版本
回答 2：如果你的代碼 500M，那只能說明業務開發該打板子了。
問題 3：如果測試環境使用您提供的完整集裝箱服務還行，但在生產環境，集群里運行 docker 做應用，如果每個容器都是有完整的代碼，是否有點臃腫，不如每個集群節點里就運行基礎服務鏡像，通過卷組功能綁定共享存儲里的代碼，加上 Crontab、Python 和 Shell 腳本，這樣每次代碼更新就 1 次就行了。
回答 3：環境一致性，在過去從來沒有解決好。10 年前我們做 paas 時，和這個做法類似。不是說不好，時代變了，用腳本東拼西湊，終究難有好的系統。不能只考慮現在的方便，容器技術和 vm 如果類比，我覺得會讓自己下決定時很糾結。
補充 3：腳本一般是典型的運維工程師思維，quick dirty。一般很難做成一個產品或者系統。整體考慮和擴展性考慮都比較少。現在做 docker 的難點在于到底怎么看待它。到底是拿它做調度的基本單位，還是部署的基本單位考慮清楚，再聊方案。
到此，關于“Docker 持續部署的技術是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！
