Docker使用的思考和理解有哪些，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

目前創(chuàng)新互聯(lián)已為上千多家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)絡(luò)空間、網(wǎng)站托管運(yùn)營(yíng)、企業(yè)網(wǎng)站設(shè)計(jì)、門(mén)源網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。

一、分享背景：

上次在群里分享完持續(xù)集成和發(fā)布后，群里也有很多同學(xué)在問(wèn)我docker應(yīng)用和發(fā)布部署的一些問(wèn)題，我們做了一些討論，再加上昨天看到的一個(gè)視頻，感覺(jué)我們其實(shí)對(duì)于Docker的應(yīng)用并沒(méi)有理解很清楚。

再加上之前有一段時(shí)間我也被這個(gè)問(wèn)題困擾過(guò)，有一些自己的思考和理解。所以中午的時(shí)候把之前自己的一些思考和記錄稍微整理了下，在這里跟大家分享，當(dāng)拋磚引玉，時(shí)間比較緊，可能有些地方說(shuō)的不一定準(zhǔn)確，內(nèi)容也不是太多，大家可以隨意拍磚討論。

首先聲明一下，本次分享屬于個(gè)人觀點(diǎn)，不代表任何組織和機(jī)構(gòu)。同時(shí)，我只是從Docker使用的角度談一下我的理解。所以，本次不是Docker技術(shù)、原理以及實(shí)現(xiàn)等相關(guān)細(xì)節(jié)的討論，像“希特勒Docker”視頻中提到的Kernel Panic、網(wǎng)絡(luò)問(wèn)題、隔離性這些Docker純技術(shù)層面上的問(wèn)題不在本次范圍討論中。 

本次分享應(yīng)該算是另外一個(gè)維度的解讀。下面開(kāi)始進(jìn)入正題：

首先，Docker的理念說(shuō)的直接一點(diǎn)就是向用戶直接交付APP，而不是物理或虛擬的機(jī)器資源，這樣可以大大提升系統(tǒng)集成、發(fā)布和部署的效率，而且可以Run Anywhere，所以這個(gè)理念一出，再加之Docker的正式發(fā)布，火熱程度已經(jīng)不能用火爆來(lái)形容了，我們好像見(jiàn)到了救世主，見(jiàn)到了又一顛覆性的技術(shù)誕生。

但是，經(jīng)過(guò)一些實(shí)踐和思考后，我經(jīng)常會(huì)反問(wèn)我自己、我的團(tuán)隊(duì)或者同行的幾個(gè)問(wèn)題是：

a、當(dāng)前我們遇到的問(wèn)題，不用Docker，在現(xiàn)有的基礎(chǔ)架構(gòu)和體系上是不是就一點(diǎn)辦法都沒(méi)有？

b、發(fā)布和部署效率低、人肉介入多，這些問(wèn)題是不是用了Docker就一定能解決了？

b、引入了Docker來(lái)解決這些問(wèn)題，帶來(lái)的對(duì)原有系統(tǒng)的改造所投入的成本有多大，是不是能真正能帶來(lái)效益的最大化？

大家也可以自己反問(wèn)一下自己，看看你的思考是什么？

隨著我們自己團(tuán)隊(duì)在做持續(xù)集成和發(fā)布系統(tǒng)的過(guò)程中，我們內(nèi)部也在思考、討論和碰撞，通過(guò)一個(gè)階段的思考和總結(jié)，我們有了自己的一些認(rèn)識(shí)。所以延續(xù)著上次分享的思路，我們先看看引入了Docker會(huì)是怎樣一個(gè)情況：

以上次我在群里分享的持續(xù)集成和發(fā)布系統(tǒng)為例，一次集成和發(fā)布的過(guò)程涉及眾多的環(huán)節(jié)和影響因素，比如應(yīng)用配置管理、多環(huán)境管理、版本分支和合并策略、打包策略、發(fā)布策略、發(fā)布粒度、服務(wù)注冊(cè)的上下線等等，如果是web服務(wù)，還要在Proxy或其它軟負(fù)載上面進(jìn)行流量切換，對(duì)于彈性擴(kuò)容和縮容，我們還要依賴容量評(píng)估系統(tǒng)（有的同學(xué)說(shuō)只看下系統(tǒng)負(fù)載就好了，其實(shí)這只是最簡(jiǎn)單的指標(biāo)，完全達(dá)不到評(píng)估的需求）。

其實(shí)，可以看到，運(yùn)維是一個(gè)非常非常重視體系化建設(shè)的工作或工種，把這些東西做到位，運(yùn)維就不會(huì)low。 

我們回來(lái)，這一套的流程和系統(tǒng)建設(shè)又依賴嚴(yán)格地標(biāo)準(zhǔn)化規(guī)范和標(biāo)準(zhǔn)化流程的制定，同時(shí)規(guī)范和流程的制定，又不能單單依賴運(yùn)維單方面的意愿，還要跟開(kāi)發(fā)、測(cè)試、SCM等等團(tuán)隊(duì)進(jìn)行協(xié)作共同制定，制定好了，大家還得能夠自覺(jué)的遵守，然后開(kāi)發(fā)對(duì)應(yīng)的系統(tǒng)和平臺(tái)，來(lái)自動(dòng)化上述的一切過(guò)程。

關(guān)于上次分享的內(nèi)容，這里不做贅述，具體細(xì)節(jié)，大家可以參考上次的分享內(nèi)容。

好了，我們回到Docker，上述持續(xù)集成和發(fā)布中的每一個(gè)環(huán)節(jié)，用剛才的問(wèn)題反問(wèn)自己，我們找?guī)讉€(gè)環(huán)節(jié)做幾個(gè)對(duì)比，比如：

a、應(yīng)用配置管理，我們現(xiàn)在是通過(guò)系統(tǒng)來(lái)管理一個(gè)個(gè)配置項(xiàng)，其它系統(tǒng)通過(guò)API來(lái)獲取配置。引入了Docker，對(duì)應(yīng)的就是通過(guò)DockerFile來(lái)做配置，反問(wèn)一下，DockerFile需要管理嗎？怎么管理？多環(huán)境情況下又怎么來(lái)處理？

b、打包構(gòu)建過(guò)程，現(xiàn)有方式是拉代碼取配置，然后生成war包。引入了Docker，對(duì)應(yīng)的就是生成鏡像，反問(wèn)一下，生成鏡像需要拉代碼并獲取配置嗎？

c、標(biāo)準(zhǔn)化和流程規(guī)范建設(shè)，這個(gè)貌似跟用不用Docker沒(méi)關(guān)系，不管用不用都要制定，只有源頭理順了，后面才能開(kāi)發(fā)才會(huì)順。

d、現(xiàn)有的代碼管理使用Git，每一次提交通過(guò)commit來(lái)識(shí)別，版本分支合并每個(gè)公司都有自己的管理策略。引入了Docker使用鏡像倉(cāng)庫(kù)，但是鏡像倉(cāng)庫(kù)是不是也需要來(lái)管理呢？這個(gè)管理平臺(tái)是不是也要定制開(kāi)發(fā)呢？版本分支策略根據(jù)各個(gè)公司的實(shí)際情況不同，也會(huì)不同，這也是個(gè)管理策略問(wèn)題，好像應(yīng)該不是Docker的管理范疇。

d、其它，就不一一對(duì)比了。

我想通過(guò)以上比對(duì)和反問(wèn)，我們可以得出這么個(gè)結(jié)論： 

基礎(chǔ)的工作，發(fā)布的環(huán)節(jié)和細(xì)節(jié)的梳理，標(biāo)準(zhǔn)化、發(fā)布流程規(guī)范、應(yīng)用配置管理、多環(huán)境管理、發(fā)布策略、服務(wù)上下線等等環(huán)節(jié)，不管用不用Docker，我們都要做，這個(gè)是基礎(chǔ)。

a、有些環(huán)節(jié)上，與用不用Docker沒(méi)有任何關(guān)系，在這些環(huán)節(jié)上Docker不會(huì)提升任何效率，也解決不了任何問(wèn)題，比如標(biāo)準(zhǔn)化、流程的約定、版本分支合并的策略等等，這個(gè)是技術(shù)管理體系內(nèi)的事情。

b、某些環(huán)節(jié)上，用或不用Docker的區(qū)別只是用不同的方式來(lái)實(shí)現(xiàn)，說(shuō)的實(shí)在一點(diǎn)就是最終都要用代碼或腳本一行行敲出來(lái)來(lái)實(shí)現(xiàn)。僅對(duì)發(fā)布而言，絕大多數(shù)的環(huán)節(jié)，不會(huì)有任何的省略，至于是否可以提升效率，還有待評(píng)估。

再來(lái)個(gè)案例對(duì)比：

我上次的分享中已經(jīng)給大家展示了通過(guò)發(fā)布系統(tǒng)的方式來(lái)完整的實(shí)現(xiàn)一次持續(xù)集成和發(fā)布過(guò)程。下面這個(gè)用Docker來(lái)做發(fā)布的案例，這個(gè)是QCon上某服務(wù)廠商的分享（注明：僅做對(duì)比使用），可以看到，對(duì)于多環(huán)境的判斷、端口的設(shè)定、啟動(dòng)的方式、配置的路徑等等，這些全部也都是用腳本一行行實(shí)現(xiàn)出來(lái)的。 

提這個(gè)案例，也只是想說(shuō)明，基礎(chǔ)的東西，不管用不用Docker，都是要做的，這個(gè)絕不是我們理解的那樣，用了Docker這些問(wèn)題就不存在了，況且用了Docker也不見(jiàn)得這個(gè)工作量真的會(huì)更小。

可能這個(gè)時(shí)候，大家要提到，發(fā)布可能是不會(huì)比之前有效率，但是擴(kuò)容部署可以，對(duì)，這個(gè)觀點(diǎn)我嚴(yán)重同意，但是會(huì)有一些前提條件的滿足，后面馬上會(huì)提到。

好了，上面舉了一個(gè)栗子，可能會(huì)有以偏概全的嫌疑，后面還有一個(gè)。但是先說(shuō)說(shuō)個(gè)人對(duì)Docker的理解：

寫(xiě)這個(gè)文章或做這次分享，絕不是要黑Docker或排斥Docker，而是期望我們能更合理、更理性的使用Docker，千萬(wàn)不要認(rèn)為Docker是銀彈，認(rèn)為Docker是解決一切效率問(wèn)題的手段，同時(shí)也不能極端的認(rèn)為，Docker有這么多的坑，而且也不能解決我的問(wèn)題，所以就堅(jiān)決排斥，這兩種觀點(diǎn)都是狹隘的、不夠開(kāi)放的心態(tài)，也是當(dāng)前普遍的對(duì)Docker膚淺的認(rèn)識(shí)。

好的，那我談一下對(duì)Docker使用的建議（只是我個(gè)人的理解，不見(jiàn)得正確和合理，歡迎拍磚和討論）：

最根本的，我們要汲取Docker的先進(jìn)理念，持續(xù)集成和發(fā)布&部署，Run Anywhere。

a、持續(xù)集成和發(fā)布&部署，如何能夠更好更快的向業(yè)務(wù)交付應(yīng)用，如何讓業(yè)務(wù)需求快速上線產(chǎn)生實(shí)際的價(jià)值，這個(gè)才是我們的目標(biāo)，一定不要跑偏了。Docker的出現(xiàn)實(shí)際就是為了要朝這個(gè)目標(biāo)發(fā)展的，所以理念和精髓理解了，至于怎么實(shí)現(xiàn)，是方式選擇問(wèn)題。千萬(wàn)不要為了Docker而Docker，不要為了技術(shù)炫酷而Docker。

b、Run Anywhere，Docker最關(guān)鍵的一點(diǎn)就是制定了應(yīng)用的標(biāo)準(zhǔn)化，通過(guò)Docker的封裝來(lái)屏蔽各種應(yīng)用上的個(gè)性化差異，比如DockerFile，其實(shí)就是為了統(tǒng)一和標(biāo)準(zhǔn)應(yīng)用的配置，比如Docker的啟停、銷毀、更新等，統(tǒng)一的接口標(biāo)準(zhǔn)，比如鏡像倉(cāng)庫(kù)，統(tǒng)一了鏡像的標(biāo)準(zhǔn)等等，所以標(biāo)準(zhǔn)化是Docker最核心價(jià)值。

所以你看，Docker是非常重視基礎(chǔ)的標(biāo)準(zhǔn)化和規(guī)范化的，但是這個(gè)精髓大家都理解了嗎？大家的日常工作都做到標(biāo)準(zhǔn)和規(guī)范了嗎？ 

所以我們要認(rèn)識(shí)到，Docker只是提供了這樣一套統(tǒng)一的應(yīng)用標(biāo)準(zhǔn)，至于怎么能夠用起來(lái)，是需要我們自己根據(jù)各自業(yè)務(wù)的現(xiàn)狀去定制、去開(kāi)發(fā)、去實(shí)現(xiàn)的，這個(gè)是要我們親自動(dòng)手去做的。

同時(shí)，基于這套標(biāo)準(zhǔn)去適配，是要付出改造的成本和代價(jià)的，比如上面提到的那些點(diǎn)，對(duì)于技術(shù)細(xì)節(jié)來(lái)說(shuō)還會(huì)有隔離性、網(wǎng)絡(luò)、IO等等一系列的技術(shù)改造和適配問(wèn)題，這個(gè)成本和代價(jià)才是Docker的火熱的Fans們與“希特勒”的抗拒者們產(chǎn)生矛盾的最根本的原因。（注意，這里想強(qiáng)調(diào)的是，我們做的每一件事情都是有成本和代價(jià)的，Docker一樣不例外。）

所以Docker的使用應(yīng)該或者一定是一個(gè)逐步演進(jìn)的過(guò)程，不是一蹴而就的。之所以這樣講：

a、還是因?yàn)榛A(chǔ)要打好，比如標(biāo)準(zhǔn)化、流程規(guī)范的制定，應(yīng)用配置管理、CMDB的建設(shè)等等，這些基礎(chǔ)的事情是永恒不變的，只有基礎(chǔ)做好了，我們才能更好的基于基礎(chǔ)去開(kāi)發(fā)和改造，對(duì)接到Docker上去，這些東西沒(méi)有，只是單純的用Docker，一切都是枉然。所以，一旦我們基于這些基礎(chǔ)工作，能夠很方便高效的生成鏡像了，那擴(kuò)容和部署的效率是不是自然也就提升了呢，Docker的威力是不是才發(fā)揮出來(lái)了呢。

b、從運(yùn)維的角度，Docker是基于APP的管理和運(yùn)維模式，它的唯一標(biāo)示是容器ID，而當(dāng)前絕大數(shù)系統(tǒng)的運(yùn)維是基于資源和IP的運(yùn)維模式，它的唯一標(biāo)示是IP，所以兩種模式基本是不相容的。而且圍繞IP的運(yùn)維模式，又衍生出了發(fā)布、部署、監(jiān)控、穩(wěn)定性、容量評(píng)估等等一系列的系統(tǒng)，所以如果要用Docker，就意味著這些系統(tǒng)都要做對(duì)應(yīng)的改造，這個(gè)成本和代價(jià)會(huì)非常的大，所以只能一步一步來(lái)。

c、同時(shí)基于容器的一整套生態(tài)系統(tǒng)也需要逐步的打磨和建設(shè)，比如安全、權(quán)限、存儲(chǔ)等等，這個(gè)生態(tài)目前來(lái)講也是在逐步的完善過(guò)程中。

不過(guò)，業(yè)界很多廠商也在考慮這個(gè)問(wèn)題，不斷的再完善Docker生態(tài)，我想這將是Docker會(huì)繼續(xù)蓬勃發(fā)展下去的最大驅(qū)動(dòng)力，我們也在持續(xù)的關(guān)注。比如Rancher，圖來(lái)自InfoQ網(wǎng)站。 

這里再插播一個(gè)我們的實(shí)際案例，我們?cè)谌ツ觌p11前，花了大約3周左右開(kāi)發(fā)過(guò)一個(gè)基于Docker的Web部署系統(tǒng)，整個(gè)理念就是用容器ID作為唯一標(biāo)示，而沒(méi)有用IP做標(biāo)示 

當(dāng)時(shí)的實(shí)際效果，可以做到分鐘級(jí)的部署和快速上線，主要是為了應(yīng)對(duì)大促峰值流量時(shí)的快速擴(kuò)容。雙11大促線上也跑了一部分Docker，但是因?yàn)槿萘砍渥悖?dāng)時(shí)大促期間并沒(méi)有進(jìn)行擴(kuò)容動(dòng)作。我們后來(lái)想推廣到線上日常使用，但是最終因?yàn)楦畜w系種種的不兼容或者改造成本大而沒(méi)有廣泛應(yīng)用起來(lái)。比如監(jiān)控、日常維護(hù)時(shí)命令輸出不一致、限流策略等等，當(dāng)然現(xiàn)在我們有專門(mén)的一個(gè)團(tuán)隊(duì)在做這方的建設(shè)，當(dāng)一系列基礎(chǔ)不斷完善起來(lái)后，這個(gè)系統(tǒng)我們依然會(huì)重新使用起來(lái)。

前段時(shí)間跟同行交流這個(gè)問(wèn)題，我們達(dá)成的一個(gè)一致觀點(diǎn)是，“一個(gè)新生事物或新技術(shù)的引入，應(yīng)該是從解決現(xiàn)有體系的痛點(diǎn)入手和出發(fā)，只有真正能幫研發(fā)和業(yè)務(wù)解決實(shí)際問(wèn)題和痛點(diǎn)了，這樣的技術(shù)才會(huì)有生命力”

最后以我看到的云計(jì)算的一篇文章中的一句話做結(jié)尾，跟大家共勉：

——”腳踏實(shí)地的解決問(wèn)題就是創(chuàng)新，我們失敗的原因往往是因?yàn)榧庇谇蟪伞?/p>

之前討論過(guò)的幾個(gè)典型問(wèn)題Q&A，我直接附上了：

Q1：現(xiàn)在業(yè)界也有很多成功的案例，特別是云服務(wù)廠商和BAT都有產(chǎn)品推出，他們?yōu)槭裁炊己艹晒?，也有成功案例?/strong>

還是要說(shuō)基礎(chǔ)建設(shè)的重要性，我們跟阿里的同學(xué)交流比較多，阿里的標(biāo)準(zhǔn)化、流程規(guī)范化之完善和嚴(yán)格，一直是我們的標(biāo)桿。我想每一個(gè)能夠做成這件事情的公司和團(tuán)隊(duì)，在前期一定是有大量的基礎(chǔ)建設(shè)工作，所以我們不要光看到表面上的強(qiáng)大和光鮮，這背后一定是有很穩(wěn)固的基礎(chǔ)在發(fā)揮作用的，類似于高樓大廈和摩天大樓的地基，腦補(bǔ)一下就理解了。

同時(shí)，每個(gè)公司的技術(shù)人員的實(shí)力和技術(shù)儲(chǔ)備不一樣，這一點(diǎn)在優(yōu)秀的互聯(lián)網(wǎng)公司那里是非常大的一個(gè)優(yōu)勢(shì)，所以可以很快速的研發(fā)出可應(yīng)用的產(chǎn)品。

還有很多戰(zhàn)略上的考慮，比如各大云服務(wù)廠商，不甘在這塊領(lǐng)域落后，必然會(huì)投入重兵進(jìn)行研發(fā)和布局。

Q2：有一些小的或初創(chuàng)公司也有很成功的案例，這個(gè)怎么解釋。

這個(gè)我的理解，規(guī)模不大或者初創(chuàng)的公司，沒(méi)有歷史包袱或者較小，從一開(kāi)始就可以基于Docker為基礎(chǔ)設(shè)施，圍繞著這個(gè)基礎(chǔ)，能夠建設(shè)出和實(shí)現(xiàn)出一些成功和優(yōu)秀的案例，也是非常正常的。但是對(duì)于稍大一點(diǎn)的公司，就是我文中提到的，必然會(huì)涉及到改造成本和代價(jià)，這個(gè)時(shí)候的ROI就要多方面綜合考慮，出發(fā)點(diǎn)不同，就會(huì)有不同的決策，但是肯定是會(huì)有一些取舍的。

Q3：Docker用在生產(chǎn)環(huán)境以機(jī)構(gòu)成熟了嗎？蘑菇街的測(cè)試環(huán)境是否都用的docker？

這個(gè)再提一下，還是那個(gè)問(wèn)題，把圍繞docker建設(shè)的基礎(chǔ)工作做好，上生產(chǎn)環(huán)境的條件就成熟了。但是穩(wěn)定性上還要看線上實(shí)際運(yùn)行情況，這個(gè)要用事實(shí)說(shuō)話。在大規(guī)模的生產(chǎn)環(huán)境上運(yùn)行，還要強(qiáng)大的技術(shù)儲(chǔ)備，關(guān)鍵時(shí)刻必須能hold住。我們的測(cè)試環(huán)境有部分docker，下一步會(huì)考慮通過(guò)docker部署，部署效率上是docker的優(yōu)勢(shì)。 

Q4：基于Docker遇到的最大的坑是什么？

我覺(jué)得從多個(gè)方面理解吧，如果從應(yīng)用方式上，對(duì)于docker應(yīng)用姿勢(shì)不對(duì)和思維模式上有問(wèn)題，這個(gè)就是最大的坑，這個(gè)是要從實(shí)際問(wèn)題出發(fā)好好總結(jié)和思考的，關(guān)鍵是看解決什么問(wèn)題。

技術(shù)上，我不在這里賣(mài)弄了，大家可以看一下我的另外一位同事郭嘉分享的內(nèi)容，在InfoQ上也有文章。

Q5：基于docke來(lái)進(jìn)行部署僅僅只為了部署環(huán)境一致。這個(gè)學(xué)習(xí)時(shí)間是否值得？還是說(shuō)docket有其他值得學(xué)習(xí)的地方，可以具體說(shuō)下嗎？

通過(guò)Docker來(lái)保證環(huán)境一致有它的優(yōu)勢(shì)，只要拉對(duì)應(yīng)的Image即可，他的理念和原理可以好好學(xué)習(xí)下。但是我還是想說(shuō)Docker只是一個(gè)手段，不是目的。

任何一個(gè)新技術(shù)都值得學(xué)習(xí)和研究，但是真正應(yīng)用的時(shí)候，最好是從問(wèn)題出發(fā)，我們的目標(biāo)和目的一定是解決問(wèn)題。

Q6：關(guān)于蘑菇街標(biāo)準(zhǔn)化、流程規(guī)范的具體內(nèi)容是否可以分享。

這個(gè)上次分享過(guò)一個(gè)提綱，但是具體內(nèi)容還要看各自的產(chǎn)品和業(yè)務(wù)的特點(diǎn)來(lái)定，我建議你可以做一下總結(jié)和思考，這個(gè)也必須是從實(shí)際出發(fā)，即使公布了全套的規(guī)范和細(xì)節(jié)，但是也不一定適用到每個(gè)生產(chǎn)環(huán)境上。遇到具體問(wèn)題我們可以討論，這里不展開(kāi)說(shuō)了。

關(guān)于Docker使用的思考和理解有哪些問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。