前言

這幾年，準(zhǔn)確說應(yīng)該是前幾年，容器的浪潮席卷了整個(gè)互聯(lián)網(wǎng)，Docker作為容器的領(lǐng)導(dǎo)者可謂風(fēng)光無限。一時(shí)間幾乎所有的互聯(lián)網(wǎng)IT公司都要上Docker，招聘職位也多了各種“容器工程師”，各種公眾號(hào)紛紛發(fā)表文章“微服務(wù)為什么一定要上Docker”云云。整個(gè)互聯(lián)網(wǎng)行業(yè)對(duì)Docker的追捧有如大躍進(jìn)一般的熱情。當(dāng)然，這其中也有個(gè)別不一樣的聲音，不過這聲音太過微弱，完全淹沒在這浪潮之中。

這一兩年隨著K8S的崛起，Docker的影響慢慢弱化，K8S漸漸主宰了容器帝國。現(xiàn)在看來，Docker只不過是那卒子，K8S才是那將軍。

雖然這幾年耳濡目染了Docker的各種傳教，但作為一個(gè)運(yùn)維人員，大部分時(shí)候?qū)ocker實(shí)在是喜愛不起來，總結(jié)一句話：Docker在標(biāo)準(zhǔn)交付、環(huán)境一致性和資源隔離等方面所帶來的優(yōu)勢，完全被它所帶來的復(fù)雜性等問題所抵消了。

一些前提聲明

1、環(huán)境

在開始討論之前，我覺得要先明確一下環(huán)境的具體含義。在一個(gè)軟件從開發(fā)到上線的過程中主要包括三個(gè)環(huán)境：

• 編譯環(huán)境：將代碼編譯成可運(yùn)行的應(yīng)用程序的環(huán)境，不在我們的討論范圍之內(nèi)。
• 運(yùn)行環(huán)境：讓應(yīng)用程序運(yùn)行起來的環(huán)境。對(duì)于java應(yīng)用來說，包括jdk版本、各種jar包等等；對(duì)于python應(yīng)用來說，包括python版本、各種模塊等等。
• 業(yè)務(wù)環(huán)境：讓業(yè)務(wù)邏輯正常提供服務(wù)的環(huán)境，這通常是別的應(yīng)用來提供的，比如依賴的數(shù)據(jù)庫、緩存、rpc服務(wù)等等。

在網(wǎng)上所有關(guān)于Docker的討論中，所涉及的環(huán)境都是運(yùn)行環(huán)境。而在后面的篇幅里會(huì)看到，業(yè)務(wù)環(huán)境的問題才是應(yīng)用部署和運(yùn)維要解決的主要問題。

2、Docker的比較對(duì)象

還有一個(gè)需要澄清的地方，目前看到的幾乎所有文章都將Docker與虛擬機(jī)作比較，因此得出了Docker要更輕量、更快速的結(jié)論。但是，站在運(yùn)維的角度來看，無論原來的應(yīng)用是部署在虛擬機(jī)還是物理機(jī)上，使用Docker以后，都是在原有的基礎(chǔ)上在操作系統(tǒng)與應(yīng)用程序之間加了一層Docker的封裝。由此可以得出：從系統(tǒng)復(fù)雜性的角度來說，Docker（以及里面跑的應(yīng)用程序）對(duì)應(yīng)的是原來的應(yīng)用程序（進(jìn)程）,它無疑增加了系統(tǒng)的復(fù)雜性。

運(yùn)維與Docker的目標(biāo)

運(yùn)維簡單說就是管理應(yīng)用的交付和運(yùn)行維護(hù)。運(yùn)維會(huì)有各種規(guī)范來盡量保證環(huán)境和配置的一致性。這些規(guī)范規(guī)定了服務(wù)器如何選型、安裝什么操作系統(tǒng)、如何命名、如何安裝應(yīng)用、安裝什么版本的數(shù)據(jù)庫、要監(jiān)控哪些東西、如何監(jiān)控、如何告警等。保證環(huán)境一致性是運(yùn)維人員的一項(xiàng)非常重要的工作內(nèi)容。

Docker的設(shè)計(jì)目的是為了讓應(yīng)用程序能一次構(gòu)建到處運(yùn)行，實(shí)現(xiàn)原理簡單說就是提供了一個(gè)類似于虛擬機(jī)的封裝，但要輕量很多，應(yīng)用運(yùn)行在這個(gè)“虛擬機(jī)”里。在這一點(diǎn)上Docker與Java虛擬機(jī)類似。

不難發(fā)現(xiàn)，Docker的設(shè)計(jì)出發(fā)點(diǎn)是默認(rèn)運(yùn)行環(huán)境是不一致或者難以做到一致的，而且為了達(dá)到適配不同環(huán)境的通用性，必定會(huì)在某些方面有所犧牲。因此，在這個(gè)前提下設(shè)計(jì)出來的產(chǎn)品對(duì)于特定的場景肯定不會(huì)是最佳選擇。

對(duì)于專業(yè)運(yùn)維人員來說，在大多數(shù)場景中，完全能通過其他更簡單更有效的方法來解決運(yùn)行環(huán)境的一致性問題。

docker的優(yōu)點(diǎn)

先來簡單看一下目前業(yè)界普遍所認(rèn)為的docker的優(yōu)點(diǎn)：

1、環(huán)境一致性

準(zhǔn)確來說，這里的環(huán)境指的是運(yùn)行環(huán)境，即應(yīng)用所依賴的運(yùn)行環(huán)境全部打包在Docker鏡像里了，無論拷貝到哪里都能馬上運(yùn)行起來。

2、標(biāo)準(zhǔn)交付

如果想要測試開源軟件或者搭建開發(fā)環(huán)境，傳統(tǒng)做法是下載源碼、編譯、配置、啟動(dòng)，對(duì)于比較安裝部署比較復(fù)雜的軟件，該過程可能會(huì)非常痛苦。而Docker能將整套系統(tǒng)打包到一個(gè)鏡像里，我們只需下載鏡像并運(yùn)行即可。

3、資源隔離

Docker能限制每個(gè)容器的資源使用，確保容器不會(huì)搶占主機(jī)的資源。同樣該特點(diǎn)有點(diǎn)像JAVA虛擬機(jī)，但Docker能夠限制除內(nèi)存外的CPU、磁盤IO等資源。

Docker的優(yōu)點(diǎn)真的有優(yōu)勢嗎？

可以看出來，這些優(yōu)點(diǎn)都是確實(shí)存在的。但是，這些優(yōu)點(diǎn)所適用的場景范圍非常有限，來具體分析一下：

1、Docker真的能解決環(huán)境的問題嗎？

Docker鼓勵(lì)“一個(gè)容器一個(gè)進(jìn)程(one process per container)”，這也是業(yè)界的普遍做法。這種情況下Docker解決的只是應(yīng)用（進(jìn)程）的運(yùn)行環(huán)境問題。而現(xiàn)在的系統(tǒng)，特別是微服務(wù)架構(gòu)，都是由多個(gè)應(yīng)用相互調(diào)用來提供服務(wù)，作為業(yè)務(wù)環(huán)境的服務(wù)依賴問題才是環(huán)境的核心問題。有過一線運(yùn)維經(jīng)驗(yàn)的運(yùn)維人員都知道，90%以上的各種環(huán)境問題都是業(yè)務(wù)環(huán)境的問題，而這個(gè)是Docker解決不了的。

2、生產(chǎn)環(huán)境交付無優(yōu)勢

同樣是基于“一個(gè)容器一個(gè)進(jìn)程”的原則，交付到生產(chǎn)環(huán)境時(shí)，傳統(tǒng)方式完全可以做到標(biāo)準(zhǔn)交付，容器鏡像的交付方式并無優(yōu)勢。而由于鏡像文件比原來的應(yīng)用要大很多，甚至?xí)黾咏桓稌r(shí)間。

3、資源隔離優(yōu)勢不明顯

一是Docker的隔離性不好，二是資源過度使用的問題有其他的方式來監(jiān)控和預(yù)防。

docker帶來的問題

1、復(fù)雜性

為了隔離現(xiàn)有業(yè)務(wù)網(wǎng)絡(luò)，Docker虛擬出一個(gè)新的網(wǎng)絡(luò)，增加了網(wǎng)絡(luò)復(fù)雜性。表現(xiàn)在：

• 增加了一個(gè)新的網(wǎng)段
• 啟用了原本不需要的iptables服務(wù)用于轉(zhuǎn)發(fā)流量，該特性同時(shí)會(huì)降低網(wǎng)絡(luò)性能

復(fù)雜性增加了，安全性勢必會(huì)降低。

2. 性能損耗

前面提到過，從運(yùn)維角度來看，Docker對(duì)應(yīng)的是傳統(tǒng)方式的應(yīng)用程序（進(jìn)程），因此，它必然會(huì)在CPU、網(wǎng)絡(luò)IO及磁盤IO方面帶來性能損耗。

3、成本增加

同樣將Docker與傳統(tǒng)方式應(yīng)用進(jìn)程對(duì)比來看，網(wǎng)上所說的Docker能節(jié)省成本簡直是無稽之談。Docker只會(huì)增加內(nèi)存和磁盤空間使用的成本而不會(huì)減少。

Docker受追捧的原因

那么，為何Docker如此受互聯(lián)網(wǎng)IT行業(yè)從業(yè)人員的追捧呢？我覺得有以下原因：

• 降低了開發(fā)人員搭建開發(fā)測試環(huán)境和試用新軟件的難度，提高了開發(fā)效率，因此開發(fā)人員在行業(yè)內(nèi)對(duì)其廣泛傳播。
• 云計(jì)算廠商和培訓(xùn)機(jī)構(gòu)等對(duì)Docker等新技術(shù)（背后的商機(jī)）的推波助瀾。
• K8S的支持。有作為互聯(lián)網(wǎng)巨頭的谷歌公司的K8S支持，眾信徒唯恐跟不上腳步。
• 國內(nèi)IT行業(yè)技術(shù)跟風(fēng)嚴(yán)重，想做一件事的理由僅僅是因?yàn)閯e人做了。而在這個(gè)過程中，一些公司的老板起到了不可忽視的作用。
• 沒有反對(duì)意見或者反對(duì)意見很少，運(yùn)維人員相對(duì)于開發(fā)人員來說數(shù)量上相差太多，人微言輕，意見得不到重視。

總結(jié)

最后，總結(jié)一下，對(duì)于開發(fā)人員來說，搭建開發(fā)環(huán)境或試驗(yàn)新軟件，Docker能夠發(fā)揮明顯的優(yōu)勢，提高開發(fā)效率；但是對(duì)于運(yùn)維人員來說，Docker所帶來的復(fù)雜性超過了其優(yōu)勢，在大多數(shù)場景下，完全有更好的方案來解決Docker所要解決的問題。所以，Docker并不是運(yùn)維的瑞士軍刀，充其量只是一把指甲刀。