這篇文章主要介紹“Docker持續(xù)部署的技術(shù)是什么”，在日常操作中，相信很多人在Docker持續(xù)部署的技術(shù)是什么問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Docker持續(xù)部署的技術(shù)是什么”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

成都網(wǎng)絡(luò)公司-成都網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)10余年經(jīng)驗(yàn)成就非凡，專業(yè)從事成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)，成都網(wǎng)頁(yè)設(shè)計(jì)，成都網(wǎng)頁(yè)制作，軟文推廣，廣告投放等。10余年來(lái)已成功提供全面的成都網(wǎng)站建設(shè)方案，打造行業(yè)特色的成都網(wǎng)站建設(shè)案例，建站熱線：13518219792，我們期待您的來(lái)電！

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

在本例中，假設(shè)我們JAVA項(xiàng)目的名稱為hello。簡(jiǎn)要的技術(shù)思路如下。

本案例中假設(shè)代碼托管在git.oschina.com上，Jenkins和Docker Registry（類似于yum源）各運(yùn)行在一個(gè)Docker容器中。JAVA項(xiàng)目自己也單獨(dú)運(yùn)行在一個(gè)叫hello的容器中。

本文采取的持續(xù)部署方案，是從私有的Docker Reistry拉取代碼。有些變通的方案，把代碼放在宿主機(jī)上，讓容器通過(guò)卷組映射來(lái)讀取。這種方法不建議的原因是，將代碼拆分出容器，這違背了Docker的集裝箱原則：

這也導(dǎo)致裝卸復(fù)雜度增加。從貨運(yùn)工人角度考慮，整體才是最經(jīng)濟(jì)的。這樣，也才能實(shí)現(xiàn)真正意義的容器級(jí)遷移。

或者說(shuō)，容器時(shí)代，拋棄過(guò)去文件分發(fā)的思想，才是正途。本文最后的問(wèn)答環(huán)節(jié)對(duì)此有更多闡述。

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

2. 效果展示

本文最后實(shí)現(xiàn)的效果，究竟有多驚艷呢？且看如下的演示。

2.1 程序代碼更新前的效果

我們以時(shí)間戳來(lái)簡(jiǎn)潔、顯式的表述程序更新情況。

2.2 提交程序代碼更新

本例中，我們把首頁(yè)的時(shí)間戳從201506181750，修改為201506191410（見(jiàn)如下）。

2.3 上傳新代碼到Git

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

然后呢？

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

為什么需要3~5分鐘？只是因?yàn)楸景咐械腏AVA項(xiàng)目，需要從國(guó)外download Maven程序包，以供Jenkins調(diào)用和編譯JAVA。正式應(yīng)用環(huán)境中，可以把Maven源放在國(guó)內(nèi)或機(jī)房。如果僅僅需要對(duì)PHP項(xiàng)目做持續(xù)部署，那就更快捷了。

2.4 查看代碼更新后的效果

在靜靜地等待幾分鐘后，新的代碼確實(shí)已經(jīng)自動(dòng)部署完畢。

那么，這一切怎么實(shí)現(xiàn)的呢？很復(fù)雜么？不然。只要按照如下幾步，便可快速實(shí)現(xiàn)哦。

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

這個(gè)過(guò)程也是難者不會(huì)，會(huì)者不難。主要分為如下三步。

3.1 Jenkins配置Git源

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

3.2 Jenkins配置遠(yuǎn)程構(gòu)建

Jenkins中配置token，以供git遠(yuǎn)程調(diào)用時(shí)使用。

3.3 Git開(kāi)啟鉤子

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

4. 配置Jenkins自動(dòng)更新代碼

Jekins在接收到Git傳遞過(guò)來(lái)的消息后，再觸發(fā)一個(gè)遠(yuǎn)程構(gòu)建（到目標(biāo)服務(wù)器），按照預(yù)定義的任務(wù)列表，執(zhí)行一系列的工作，重建容器等。詳見(jiàn)如下：

我們把其中最關(guān)鍵的Shell腳本內(nèi)容摘抄出來(lái)。

5. 效果圖文詳解

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

當(dāng)時(shí)并沒(méi)有細(xì)說(shuō)后續(xù)發(fā)生的事情，既然上面已經(jīng)說(shuō)清楚了原理，那我們就可以接下來(lái)說(shuō)說(shuō)實(shí)際發(fā)生的事情啦。

5.1 上傳代碼到Git

這里貌似整個(gè)過(guò)程已經(jīng)完成并順利退出。其實(shí)，后臺(tái)的工作才剛剛開(kāi)始哦。

這時(shí)會(huì)觸發(fā)Git服務(wù)器向相應(yīng)的Jenkins服務(wù)器發(fā)出一個(gè)操作請(qǐng)求，此工作太過(guò)迅速，也沒(méi)啥好說(shuō)的，我們接下來(lái)看Jenkins都干啥子了。

5.2 Jenkins進(jìn)行的精彩互動(dòng)

1）Jenkins會(huì)自動(dòng)冒出來(lái)一個(gè)構(gòu)建任務(wù)。

2）我們點(diǎn)進(jìn)來(lái)，看看具體操作日志。是的，正在接受來(lái)自Git的任務(wù)。

3）下載Maven相關(guān)的軟件包（就是這個(gè)過(guò)程慢）。

4）下載完成后，就開(kāi)始利用maven BUILD 新的hello項(xiàng)目包。

5）然后重建Maven容器，構(gòu)建新的Image并Push到Docker私有庫(kù)中。

6）最后，重新把Docker容器拉起來(lái)。這樣，又新生了。呵呵

6. FAQ

問(wèn)題1：采用這么相對(duì)復(fù)雜的辦法（而不是把更新代碼放在宿主機(jī)然后卷組映射），是因?yàn)轫?xiàng)目基于JAVA么；是否PHP項(xiàng)目就可以采用更新代碼放在宿主機(jī)然后卷組映射這種方式？

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

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

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

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

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

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

到此，關(guān)于“Docker持續(xù)部署的技術(shù)是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！

本文標(biāo)題：Docker持續(xù)部署的技術(shù)是什么
本文URL：http://jinyejixie.com/article12/joghdc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營(yíng)銷推廣、微信小程序、微信公眾號(hào)、響應(yīng)式網(wǎng)站、品牌網(wǎng)站建設(shè)、用戶體驗(yàn)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)