溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“Docker持續部署的技術是什么”，在日常操作中，相信很多人在Docker持續部署的技術是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Docker持續部署的技術是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
在本例中，假設我們JAVA項目的名稱為hello。簡要的技術思路如下。
本案例中假設代碼托管在git.oschina.com上，Jenkins和Docker Registry（類似于yum源）各運行在一個Docker容器中。JAVA項目自己也單獨運行在一個叫hello的容器中。
本文采取的持續部署方案，是從私有的Docker Reistry拉取代碼。有些變通的方案，把代碼放在宿主機上，讓容器通過卷組映射來讀取。這種方法不建議的原因是，將代碼拆分出容器，這違背了Docker的集裝箱原則：
這也導致裝卸復雜度增加。從貨運工人角度考慮，整體才是最經濟的。這樣，也才能實現真正意義的容器級遷移。
或者說，容器時代，拋棄過去文件分發的思想，才是正途。本文最后的問答環節對此有更多闡述。
容器即進程。我們采用上述方案做Docker持續部署的原因和意義，也在于此。容器的生命周期，應該遠遠短于虛擬機，容器出現問題，應該是立即殺掉，而不是試圖恢復。
本文最后實現的效果，究竟有多驚艷呢？且看如下的演示。
我們以時間戳來簡潔、顯式的表述程序更新情況。
本例中，我們把首頁的時間戳從201506181750，修改為201506191410（見如下）。
順序執行如下操作，輸入正確的git賬號密碼。
然后呢？
然后什么都不用做了。端杯茶（如果不喜歡咖啡的話），靜靜地等待自動部署的發生， 旁觀一系列被自動觸發的過程，機器人似的運轉起來（請容稍候再加以描述）。
為什么需要3~5分鐘？只是因為本案例中的JAVA項目，需要從國外download Maven程序包，以供Jenkins調用和編譯JAVA。正式應用環境中，可以把Maven源放在國內或機房。如果僅僅需要對PHP項目做持續部署，那就更快捷了。
在靜靜地等待幾分鐘后，新的代碼確實已經自動部署完畢。
那么，這一切怎么實現的呢？很復雜么？不然。只要按照如下幾步，便可快速實現哦。
這個過程也是難者不會，會者不難。主要分為如下三步。
Jenkins中新建項目java-app，并配置從Git拉取程序代碼。具體如下：
Jenkins中配置token，以供git遠程調用時使用。
怎么讓Git在接收到用戶更新的代碼后，把消息和任務傳遞給Jenkins呢？這借助于Git的hook功能，配置起來也非常簡單，如下。
Jekins在接收到Git傳遞過來的消息后，再觸發一個遠程構建（到目標服務器），按照預定義的任務列表，執行一系列的工作，重建容器等。詳見如下：
我們把其中最關鍵的Shell腳本內容摘抄出來。
在2.3這個章節中，我們當時的操作如下，這個目的是向Git提交更新代碼。
當時并沒有細說后續發生的事情，既然上面已經說清楚了原理，那我們就可以接下來說說實際發生的事情啦。
這里貌似整個過程已經完成并順利退出。其實，后臺的工作才剛剛開始哦。
這時會觸發Git服務器向相應的Jenkins服務器發出一個操作請求，此工作太過迅速，也沒啥好說的，我們接下來看Jenkins都干啥子了。
1）Jenkins會自動冒出來一個構建任務。
2）我們點進來，看看具體操作日志。是的，正在接受來自Git的任務。
3）下載Maven相關的軟件包（就是這個過程慢）。
4）下載完成后，就開始利用maven BUILD 新的hello項目包。
5）然后重建Maven容器，構建新的Image并Push到Docker私有庫中。
6）最后，重新把Docker容器拉起來。這樣，又新生了。呵呵
問題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持續部署的技術是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
