Docker使用的思考和理解有哪些

Docker使用的思考和理解有哪些，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

一、分享背景：

上次在群里分享完持續集成和發布后，群里也有很多同學在問我docker應用和發布部署的一些問題，我們做了一些討論，再加上昨天看到的一個視頻，感覺我們其實對于Docker的應用并沒有理解很清楚。

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

首先聲明一下，本次分享屬于個人觀點，不代表任何組織和機構。同時，我只是從Docker使用的角度談一下我的理解。所以，本次不是Docker技術、原理以及實現等相關細節的討論，像“希特勒Docker”視頻中提到的Kernel Panic、網絡問題、隔離性這些Docker純技術層面上的問題不在本次范圍討論中。 

本次分享應該算是另外一個維度的解讀。下面開始進入正題：

首先，Docker的理念說的直接一點就是向用戶直接交付APP，而不是物理或虛擬的機器資源，這樣可以大大提升系統集成、發布和部署的效率，而且可以Run Anywhere，所以這個理念一出，再加之Docker的正式發布，火熱程度已經不能用火爆來形容了，我們好像見到了救世主，見到了又一顛覆性的技術誕生。

但是，經過一些實踐和思考后，我經常會反問我自己、我的團隊或者同行的幾個問題是：

a、當前我們遇到的問題，不用Docker，在現有的基礎架構和體系上是不是就一點辦法都沒有？

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

b、引入了Docker來解決這些問題，帶來的對原有系統的改造所投入的成本有多大，是不是能真正能帶來效益的最大化？

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

隨著我們自己團隊在做持續集成和發布系統的過程中，我們內部也在思考、討論和碰撞，通過一個階段的思考和總結，我們有了自己的一些認識。所以延續著上次分享的思路，我們先看看引入了Docker會是怎樣一個情況：

以上次我在群里分享的持續集成和發布系統為例，一次集成和發布的過程涉及眾多的環節和影響因素，比如應用配置管理、多環境管理、版本分支和合并策略、打包策略、發布策略、發布粒度、服務注冊的上下線等等，如果是web服務，還要在Proxy或其它軟負載上面進行流量切換，對于彈性擴容和縮容，我們還要依賴容量評估系統（有的同學說只看下系統負載就好了，其實這只是最簡單的指標，完全達不到評估的需求）。

其實，可以看到，運維是一個非常非常重視體系化建設的工作或工種，把這些東西做到位，運維就不會low。 

我們回來，這一套的流程和系統建設又依賴嚴格地標準化規范和標準化流程的制定，同時規范和流程的制定，又不能單單依賴運維單方面的意愿，還要跟開發、測試、SCM等等團隊進行協作共同制定，制定好了，大家還得能夠自覺的遵守，然后開發對應的系統和平臺，來自動化上述的一切過程。

關于上次分享的內容，這里不做贅述，具體細節，大家可以參考上次的分享內容。

好了，我們回到Docker，上述持續集成和發布中的每一個環節，用剛才的問題反問自己，我們找幾個環節做幾個對比，比如：

a、應用配置管理，我們現在是通過系統來管理一個個配置項，其它系統通過API來獲取配置。引入了Docker，對應的就是通過DockerFile來做配置，反問一下，DockerFile需要管理嗎？怎么管理？多環境情況下又怎么來處理？

b、打包構建過程，現有方式是拉代碼取配置，然后生成war包。引入了Docker，對應的就是生成鏡像，反問一下，生成鏡像需要拉代碼并獲取配置嗎？

c、標準化和流程規范建設，這個貌似跟用不用Docker沒關系，不管用不用都要制定，只有源頭理順了，后面才能開發才會順。

d、現有的代碼管理使用Git，每一次提交通過commit來識別，版本分支合并每個公司都有自己的管理策略。引入了Docker使用鏡像倉庫，但是鏡像倉庫是不是也需要來管理呢？這個管理平臺是不是也要定制開發呢？版本分支策略根據各個公司的實際情況不同，也會不同，這也是個管理策略問題，好像應該不是Docker的管理范疇。

d、其它，就不一一對比了。

我想通過以上比對和反問，我們可以得出這么個結論： 

基礎的工作，發布的環節和細節的梳理，標準化、發布流程規范、應用配置管理、多環境管理、發布策略、服務上下線等等環節，不管用不用Docker，我們都要做，這個是基礎。

a、有些環節上，與用不用Docker沒有任何關系，在這些環節上Docker不會提升任何效率，也解決不了任何問題，比如標準化、流程的約定、版本分支合并的策略等等，這個是技術管理體系內的事情。

b、某些環節上，用或不用Docker的區別只是用不同的方式來實現，說的實在一點就是最終都要用代碼或腳本一行行敲出來來實現。僅對發布而言，絕大多數的環節，不會有任何的省略，至于是否可以提升效率，還有待評估。

再來個案例對比：

我上次的分享中已經給大家展示了通過發布系統的方式來完整的實現一次持續集成和發布過程。下面這個用Docker來做發布的案例，這個是QCon上某服務廠商的分享（注明：僅做對比使用），可以看到，對于多環境的判斷、端口的設定、啟動的方式、配置的路徑等等，這些全部也都是用腳本一行行實現出來的。 

提這個案例，也只是想說明，基礎的東西，不管用不用Docker，都是要做的，這個絕不是我們理解的那樣，用了Docker這些問題就不存在了，況且用了Docker也不見得這個工作量真的會更小。

可能這個時候，大家要提到，發布可能是不會比之前有效率，但是擴容部署可以，對，這個觀點我嚴重同意，但是會有一些前提條件的滿足，后面馬上會提到。

好了，上面舉了一個栗子，可能會有以偏概全的嫌疑，后面還有一個。但是先說說個人對Docker的理解：

寫這個文章或做這次分享，絕不是要黑Docker或排斥Docker，而是期望我們能更合理、更理性的使用Docker，千萬不要認為Docker是銀彈，認為Docker是解決一切效率問題的手段，同時也不能極端的認為，Docker有這么多的坑，而且也不能解決我的問題，所以就堅決排斥，這兩種觀點都是狹隘的、不夠開放的心態，也是當前普遍的對Docker膚淺的認識。

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

最根本的，我們要汲取Docker的先進理念，持續集成和發布&部署，Run Anywhere。

a、持續集成和發布&部署，如何能夠更好更快的向業務交付應用，如何讓業務需求快速上線產生實際的價值，這個才是我們的目標，一定不要跑偏了。Docker的出現實際就是為了要朝這個目標發展的，所以理念和精髓理解了，至于怎么實現，是方式選擇問題。千萬不要為了Docker而Docker，不要為了技術炫酷而Docker。

b、Run Anywhere，Docker最關鍵的一點就是制定了應用的標準化，通過Docker的封裝來屏蔽各種應用上的個性化差異，比如DockerFile，其實就是為了統一和標準應用的配置，比如Docker的啟停、銷毀、更新等，統一的接口標準，比如鏡像倉庫，統一了鏡像的標準等等，所以標準化是Docker最核心價值。

所以你看，Docker是非常重視基礎的標準化和規范化的，但是這個精髓大家都理解了嗎？大家的日常工作都做到標準和規范了嗎？ 

所以我們要認識到，Docker只是提供了這樣一套統一的應用標準，至于怎么能夠用起來，是需要我們自己根據各自業務的現狀去定制、去開發、去實現的，這個是要我們親自動手去做的。

同時，基于這套標準去適配，是要付出改造的成本和代價的，比如上面提到的那些點，對于技術細節來說還會有隔離性、網絡、IO等等一系列的技術改造和適配問題，這個成本和代價才是Docker的火熱的Fans們與“希特勒”的抗拒者們產生矛盾的最根本的原因。（注意，這里想強調的是，我們做的每一件事情都是有成本和代價的，Docker一樣不例外。）

所以Docker的使用應該或者一定是一個逐步演進的過程，不是一蹴而就的。之所以這樣講：

a、還是因為基礎要打好，比如標準化、流程規范的制定，應用配置管理、CMDB的建設等等，這些基礎的事情是永恒不變的，只有基礎做好了，我們才能更好的基于基礎去開發和改造，對接到Docker上去，這些東西沒有，只是單純的用Docker，一切都是枉然。所以，一旦我們基于這些基礎工作，能夠很方便高效的生成鏡像了，那擴容和部署的效率是不是自然也就提升了呢，Docker的威力是不是才發揮出來了呢。

b、從運維的角度，Docker是基于APP的管理和運維模式，它的唯一標示是容器ID，而當前絕大數系統的運維是基于資源和IP的運維模式，它的唯一標示是IP，所以兩種模式基本是不相容的。而且圍繞IP的運維模式，又衍生出了發布、部署、監控、穩定性、容量評估等等一系列的系統，所以如果要用Docker，就意味著這些系統都要做對應的改造，這個成本和代價會非常的大，所以只能一步一步來。

c、同時基于容器的一整套生態系統也需要逐步的打磨和建設，比如安全、權限、存儲等等，這個生態目前來講也是在逐步的完善過程中。

不過，業界很多廠商也在考慮這個問題，不斷的再完善Docker生態，我想這將是Docker會繼續蓬勃發展下去的最大驅動力，我們也在持續的關注。比如Rancher，圖來自InfoQ網站。 

這里再插播一個我們的實際案例，我們曾在去年雙11前，花了大約3周左右開發過一個基于Docker的Web部署系統，整個理念就是用容器ID作為唯一標示，而沒有用IP做標示 

當時的實際效果，可以做到分鐘級的部署和快速上線，主要是為了應對大促峰值流量時的快速擴容。雙11大促線上也跑了一部分Docker，但是因為容量充足，當時大促期間并沒有進行擴容動作。我們后來想推廣到線上日常使用，但是最終因為跟原有體系種種的不兼容或者改造成本大而沒有廣泛應用起來。比如監控、日常維護時命令輸出不一致、限流策略等等，當然現在我們有專門的一個團隊在做這方的建設，當一系列基礎不斷完善起來后，這個系統我們依然會重新使用起來。

前段時間跟同行交流這個問題，我們達成的一個一致觀點是，“一個新生事物或新技術的引入，應該是從解決現有體系的痛點入手和出發，只有真正能幫研發和業務解決實際問題和痛點了，這樣的技術才會有生命力”

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

——”腳踏實地的解決問題就是創新，我們失敗的原因往往是因為急于求成。

之前討論過的幾個典型問題Q&A，我直接附上了：

Q1：現在業界也有很多成功的案例，特別是云服務廠商和BAT都有產品推出，他們為什么都很成功，也有成功案例。

還是要說基礎建設的重要性，我們跟阿里的同學交流比較多，阿里的標準化、流程規范化之完善和嚴格，一直是我們的標桿。我想每一個能夠做成這件事情的公司和團隊，在前期一定是有大量的基礎建設工作，所以我們不要光看到表面上的強大和光鮮，這背后一定是有很穩固的基礎在發揮作用的，類似于高樓大廈和摩天大樓的地基，腦補一下就理解了。

同時，每個公司的技術人員的實力和技術儲備不一樣，這一點在優秀的互聯網公司那里是非常大的一個優勢，所以可以很快速的研發出可應用的產品。

還有很多戰略上的考慮，比如各大云服務廠商，不甘在這塊領域落后，必然會投入重兵進行研發和布局。

Q2：有一些小的或初創公司也有很成功的案例，這個怎么解釋。

這個我的理解，規模不大或者初創的公司，沒有歷史包袱或者較小，從一開始就可以基于Docker為基礎設施，圍繞著這個基礎，能夠建設出和實現出一些成功和優秀的案例，也是非常正常的。但是對于稍大一點的公司，就是我文中提到的，必然會涉及到改造成本和代價，這個時候的ROI就要多方面綜合考慮，出發點不同，就會有不同的決策，但是肯定是會有一些取舍的。

Q3：Docker用在生產環境以機構成熟了嗎？蘑菇街的測試環境是否都用的docker？

這個再提一下，還是那個問題，把圍繞docker建設的基礎工作做好，上生產環境的條件就成熟了。但是穩定性上還要看線上實際運行情況，這個要用事實說話。在大規模的生產環境上運行，還要強大的技術儲備，關鍵時刻必須能hold住。我們的測試環境有部分docker，下一步會考慮通過docker部署，部署效率上是docker的優勢。 

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

我覺得從多個方面理解吧，如果從應用方式上，對于docker應用姿勢不對和思維模式上有問題，這個就是最大的坑，這個是要從實際問題出發好好總結和思考的，關鍵是看解決什么問題。

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

Q5：基于docke來進行部署僅僅只為了部署環境一致。這個學習時間是否值得？還是說docket有其他值得學習的地方，可以具體說下嗎？

通過Docker來保證環境一致有它的優勢，只要拉對應的Image即可，他的理念和原理可以好好學習下。但是我還是想說Docker只是一個手段，不是目的。

任何一個新技術都值得學習和研究，但是真正應用的時候，最好是從問題出發，我們的目標和目的一定是解決問題。

Q6：關于蘑菇街標準化、流程規范的具體內容是否可以分享。

這個上次分享過一個提綱，但是具體內容還要看各自的產品和業務的特點來定，我建議你可以做一下總結和思考，這個也必須是從實際出發，即使公布了全套的規范和細節，但是也不一定適用到每個生產環境上。遇到具體問題我們可以討論，這里不展開說了。

關于Docker使用的思考和理解有哪些問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。