Docker：一場(chǎng)令人追悔莫及的豪賭

【編者的話】：
Docker縱然有其優(yōu)勢(shì)，但其背后亦存在大量設(shè)計(jì)不合理之處。這篇文章旨在闡述Docker的種種弊端，并指出相關(guān)依據(jù)。

每當(dāng)我對(duì)Docker提出批判時(shí)，都會(huì)收到很多憤懣的回復(fù)。我曾于6個(gè)月前撰寫一篇文章，即《為什么有人會(huì)選擇Docker而非大型二進(jìn)制文件？》，并終于在Hacker News上眾多憤慨的批評(píng)聲中看到了一些明智的評(píng)論。因而，今天的這篇文章主要是進(jìn)一步闡述Docker的設(shè)計(jì)缺陷并回應(yīng)未來可能將會(huì)面臨的批判。

相比HFT Guy的經(jīng)歷而言，我想我已經(jīng)足夠幸運(yùn)了。HFT Guy曾滿腔怒火地表示，由于在金融公司的產(chǎn)品生產(chǎn)階段使用了Docker而導(dǎo)致失敗，想來其必然為此付出了不小代價(jià)。原文引用如下：

我收到了一份十分無禮的郵件，發(fā)件人明顯是業(yè)余社區(qū)中的一員。這位仁兄在郵件中憤怒地表示：“白癡才會(huì)在Ubuntu上運(yùn)行Docker?！痹撪]件中還隨附了一份軟件程序包列表以及在Ubuntu上運(yùn)行Docker所需的高級(jí)系統(tǒng)調(diào)整方案。另外，這封郵件還特地表示：“任何人都可以通過谷歌在5秒內(nèi)找到列表中的相關(guān)內(nèi)容。”

人們傾向于在網(wǎng)上發(fā)泄其憤怒——盡管我不知為何，但事實(shí)的確如此。并且，當(dāng)開發(fā)人員發(fā)現(xiàn)有人抨擊其所深愛的技術(shù)時(shí)，往往會(huì)奮起反擊，進(jìn)而引發(fā)一場(chǎng)口水戰(zhàn)。然而，這種不良情緒蒙蔽了他們了雙眼，以至于其無法辨識(shí)相關(guān)方案有關(guān)現(xiàn)實(shí)使用方面的長(zhǎng)遠(yuǎn)意義。

Docker承諾其能夠提供可移植性、安全性以及資源管理與編排能力。因此，理智的人們自然希望了解：“Docker是否真的是獲取可移植性、安全性以及資源管理與編排能力的最佳方式？”

在此之前，我想先回應(yīng)我所收到的部分回復(fù)。盡管大部分回復(fù)中所持有的觀點(diǎn)根本不值得討論，但有一個(gè)論點(diǎn)引起了我的注意——我將在文末對(duì)其詳加闡述。

有評(píng)論如下：

由于使用Docker所涉及的資源較少，并且與是否需要對(duì)相關(guān)資源進(jìn)行處理以及使用方現(xiàn)有的處理能力無關(guān)。

是的。但參考對(duì)象又是什么呢？是讓開發(fā)人員編寫腳本以實(shí)現(xiàn)標(biāo)準(zhǔn)化構(gòu)建、部署、編排以及資源使用嗎？上述評(píng)論似乎想要表達(dá)的是“我并不是說開發(fā)人員應(yīng)該選擇這類操作，因?yàn)榻Y(jié)果已經(jīng)客觀存在; 我的意思是希望其能夠?qū)崿F(xiàn)標(biāo)準(zhǔn)化?！?/span>

開發(fā)人員與管理人員偏愛Docker的原因無外乎其所提供的功能自定義空間有限、相對(duì)不那么混亂、更長(zhǎng)久且更加標(biāo)準(zhǔn)化——或者起碼存在實(shí)現(xiàn)這類效果的機(jī)會(huì)。然而事實(shí)上，Docker迄今為止帶來的只是一團(tuán)令人難以置信的亂麻（更多詳細(xì)信息請(qǐng)參考：《生產(chǎn)階段的Docker：一段失敗的歷史》）。盡管如此，仍然有很多人愿意相信目前Docker所存在的問題不久即可得以解決，并且屆時(shí)Docker就能夠?yàn)槿萜骰瘓?chǎng)景提供穩(wěn)定且一致的標(biāo)準(zhǔn)。這無疑是一場(chǎng)關(guān)于Docker的豪賭！幾乎所有參與這場(chǎng)“賭博”的公司都為此付出了慘重的代價(jià)，但仍然有公司繼續(xù)為此投注，以期有朝一日能夠由此獲取豐厚的回報(bào)。

在過去的兩年時(shí)間里，我曾合作過的每家公司不是在使用Docker，就是在擬定有關(guān)使用Docker的計(jì)劃。實(shí)際上，這些公司都為獲取標(biāo)準(zhǔn)化解決方案付出了高昂的代價(jià)。

更可怕的是，我還沒有聽到任何一位技術(shù)管理者明確對(duì)這種“賭博”現(xiàn)狀作出陳述。大多數(shù)支持Docker的群體仍在不斷強(qiáng)調(diào)其帶來的可移植性、安全性或者編排與配置能力。沒錯(cuò)，Docker確實(shí)能夠?yàn)槲覀兲峁┛梢浦残浴踩曰蛘呔幣排c配置能力，但其代價(jià)也相當(dāng)可觀。在大多數(shù)情況下，編寫特定腳本反而難度更低。

在我個(gè)人認(rèn)為最出色的Docker論述文章當(dāng)中，作者強(qiáng)調(diào)了使用Docker所帶來的利弊權(quán)衡：

最好將Docker視為一種高級(jí)優(yōu)化方案。沒錯(cuò)，它很酷且功能相當(dāng)強(qiáng)大，但其同時(shí)也會(huì)增加系統(tǒng)復(fù)雜性，且只有專業(yè)的系統(tǒng)管理員才能夠理解如何在生產(chǎn)中安全使用Docker并將其部署在關(guān)鍵性任務(wù)系統(tǒng)之內(nèi)。
就目前來看，您需要掌握更多系統(tǒng)專業(yè)知識(shí)才能使用Docker。事實(shí)上，幾乎所有Docker相關(guān)文章都只展示過分簡(jiǎn)單的用例，而忽略了在多主機(jī)生產(chǎn)系統(tǒng)上使用Docker所帶來的復(fù)雜性挑戰(zhàn)。這無疑給人們留下了Docker的實(shí)際生產(chǎn)應(yīng)用非常簡(jiǎn)單易行這一極為錯(cuò)誤的印象。

在計(jì)算機(jī)編程領(lǐng)域，流傳著這樣一句至理名言：

“不成熟的優(yōu)化是萬惡之源”。

然而，今年以來我們的大部分客戶都堅(jiān)持

“我們必須從起步階段就全部實(shí)現(xiàn)Docker化。”

因此不同于傳統(tǒng)最初最佳實(shí)踐要求的建立一套工作系統(tǒng)、將其投入生產(chǎn)、最后考量Docker能否帶來比較優(yōu)勢(shì)的作法，客戶們開始盲目推動(dòng)Docker的標(biāo)準(zhǔn)化開發(fā)與部署。

可能很多朋友都遇到過以下場(chǎng)景：

我：“我們不需要在項(xiàng)目早期使用Docker?！?/span>

對(duì)方：“這款應(yīng)用需要Nginx、PostGres以及Redis和一大堆環(huán)境變量。如果不用Docker，要怎么進(jìn)行設(shè)置？”

我：“我可以寫個(gè)Bash腳本、用make命令，或者使用其它類型的安裝程序。反正方案多種多樣，這么多年來我們一直都有辦法。”

對(duì)方：“這簡(jiǎn)直是瘋了。Bash腳本有可能中斷，你就得花時(shí)間調(diào)試；而且跟容器相比，它不一定能在其它機(jī)器上正常運(yùn)行。使用Docker，我們可以編寫build腳本，而且保證它能夠在任何一臺(tái)機(jī)器上正常運(yùn)行?！?/span>

很明顯，這就是典型的銷售代表場(chǎng)景——他們只會(huì)強(qiáng)調(diào)Docker最吸引人的特性。作為一款開發(fā)工具，Docker看起來確實(shí)擁有更出色的一致性水平，而且不像其它方案那么混亂。但在實(shí)際使用過程中，特別是在生產(chǎn)環(huán)境當(dāng)中，Docker帶來的往往只有痛苦。

您的開發(fā)團(tuán)隊(duì)可能擁有一位使用Windows機(jī)器的開發(fā)者、一位Mac用戶、一位已經(jīng)安裝Ubuntu的開發(fā)者，外加一位使用紅帽Linux的開發(fā)者。對(duì)于身為團(tuán)隊(duì)負(fù)責(zé)人的您來說，對(duì)他們使用的機(jī)器進(jìn)行全面控制幾乎是個(gè)不可能完成的任務(wù)。而乍看之下，Docker似乎能夠確保在各類平臺(tái)上提供相同的開發(fā)環(huán)境。（但這里我要提一句，千萬別在Windows環(huán)境中使用Docker——任何告訴你Docker能夠簡(jiǎn)化Windows機(jī)器開發(fā)流程的家伙都是在給你挖坑。）

但在實(shí)際生產(chǎn)過程當(dāng)中，您將能夠完全控制生產(chǎn)環(huán)境中運(yùn)行的機(jī)器。如果您希望在CentOS上實(shí)現(xiàn)標(biāo)準(zhǔn)化，完全沒有問題。您可以掌控?cái)?shù)千臺(tái)CentOS服務(wù)器，并利用舊有技術(shù)（例如Puppet）確保這些服務(wù)器擁有同樣的運(yùn)行環(huán)境。這意味著Docker并沒有傳說中那么重要。相比之下，在利用Docker進(jìn)行開發(fā)時(shí)，開發(fā)人員往往會(huì)認(rèn)為實(shí)際生產(chǎn)環(huán)境也將由Docker構(gòu)建而成——但事實(shí)并非如此。

我當(dāng)然可以列舉更多與Docker問題相關(guān)的實(shí)際案例，但這些例子真的非常無聊。目前已經(jīng)有大量博文在討論Docker設(shè)計(jì)缺陷，相信您對(duì)這些已經(jīng)有所耳聞——除非您身為Docker鐵粉，而且對(duì)一切反對(duì)意見都視而不見。對(duì)于這部分朋友，他們會(huì)直接忽略此類文章，或者在勉強(qiáng)讀完之后表示“Docker生態(tài)系統(tǒng)正在迅速發(fā)展成熟，相信到明年其就會(huì)非常穩(wěn)定且適合用于實(shí)際生產(chǎn)。”這樣的話在過去五年中每年都會(huì)出現(xiàn)。沒錯(cuò)，也許這樣的論斷最終會(huì)變成現(xiàn)實(shí)，但回到開頭——這是一場(chǎng)危險(xiǎn)的豪賭。

盡管Docker存在上述問題，但其似乎仍然獲得了成功——與我們使我?guī)缀趺考移髽I(yè)都渴望投向Docker的懷抱。為什么？據(jù)我所知，標(biāo)準(zhǔn)化是其中最為核心的理由。

再次強(qiáng)調(diào)，在發(fā)表于Hacker News上的文章的評(píng)論中，網(wǎng)友“friend-monoid”這樣評(píng)價(jià)Docker：

我們擁有大量以不同語言編寫而成的HTTP服務(wù)。以[超級(jí)]二進(jìn)制方式對(duì)其進(jìn)行整體管理是件苦差事——編寫者必須提供一種用于端口設(shè)置及地址監(jiān)聽的方案，而我必須追蹤每一種端口設(shè)置方式。有了net命名空間與更智能的iptables路由，Docker能夠幫助我完成這項(xiàng)任務(wù)。

網(wǎng)友notyourday則給出了深得我心的回應(yīng)：

當(dāng)然，如果你采用其它方法并且遵循同樣的編寫方式與規(guī)則，也能達(dá)到同樣的效果。事實(shí)上，后者的效果可能更好，因?yàn)槠鋾?huì)提供更智能的命名空間與iptables，甚至允許你完全不用分心于應(yīng)用程序的運(yùn)作狀態(tài)。
網(wǎng)友a(bǔ)nilakar回應(yīng)notyourday道:

在我看來，這正是Docker技能具備可轉(zhuǎn)移性的核心所在。也就是說，如此一來，剛剛招聘的新人也能夠很快上手新工作。很多企業(yè)仍然在使用能夠切實(shí)滿足基業(yè)務(wù)需求的構(gòu)建/部署系統(tǒng)，但卻無法提供能夠在企業(yè)之外繼續(xù)發(fā)揮作用的實(shí)用經(jīng)驗(yàn)。
據(jù)我所知，這基本總結(jié)出了Docker的真正優(yōu)勢(shì)所在。沒錯(cuò)，Docker的優(yōu)勢(shì)根本不在于能夠讓應(yīng)用的部署、安全保障或者編排變得更加輕松——這完全 就是無稽之談。事實(shí)上，Docker成為標(biāo)準(zhǔn)的惟一理由，就是人們能夠?qū)⒆约涸谝患移髽I(yè)中積累到的經(jīng)驗(yàn)應(yīng)用于另一家企業(yè)。Docker不像自定義Bash腳本那么混亂且獨(dú)特。然而，這是否值得我們押上一切？

但說句不中聽的，我覺得上述爭(zhēng)論其實(shí)是混淆容器技術(shù)與Docker。而且相當(dāng)一部分Docker支持派是在故意混淆這個(gè)問題。容器技術(shù)本身確實(shí)是個(gè)先進(jìn)的概念，但由單一公司掌控的Docker卻不可避免地存在著一定問題。繼續(xù)來看HTF Guy給出的觀點(diǎn)：

Docker不具備商業(yè)模式，也無法實(shí)現(xiàn)貨幣化。公平地講，Docker公司正在以絕望的方式將其推向全部平臺(tái)（Mac/Windows），并將所有功能特性硬湊在一起（Swarm），從而：

1. 確保任何競(jìng)爭(zhēng)對(duì)手都不具備任何顯著的獨(dú)特性；

2. 確保每個(gè)人都使用Docker及Docker工具；

3. 將客戶完全鎖定在其生態(tài)系統(tǒng)當(dāng)中；

4. 在此過程中發(fā)布大量新聞、文章與報(bào)道，增加炒作熱度；

5. 證明其估值的合理性。

Docker幾乎完全不可能面向多種產(chǎn)品及市場(chǎng)進(jìn)行水平與垂直擴(kuò)展。（這里我們姑且不論這種擴(kuò)展是否屬于適當(dāng)或者說可持續(xù)的商業(yè)決策，這又是另一個(gè)議題了。）
與此同時(shí)，Amazon、微軟、谷歌、Pivotal以及紅帽等競(jìng)爭(zhēng)對(duì)手則在以各種方式進(jìn)行競(jìng)爭(zhēng)，而且通過容器賺到了遠(yuǎn)超Docker的回報(bào)。事實(shí)上，CoreOS也在開發(fā)操作系統(tǒng)并憑借其Rocket容器化技術(shù)參與競(jìng)爭(zhēng)。
因此，即使您認(rèn)同容器技術(shù)當(dāng)中蘊(yùn)藏的巨大能量，并高度贊揚(yáng)由其帶來的設(shè)置一致性能力，也并不同改變Docker本身根基不穩(wěn)的事實(shí)。

好吧，這里我們暫時(shí)把Docker和容器看成是同一種東西。在這樣的立場(chǎng)之下，我們?cè)賮砘仡櫸抑鞍l(fā)表的文章，看看其中哪些批評(píng)意見仍然符合現(xiàn)實(shí)。

我在前文當(dāng)中錯(cuò)誤地使用“大型二進(jìn)制文件”這樣的表達(dá)，并導(dǎo)致了很多誤解。幾小時(shí)之后，我發(fā)布了以下免責(zé)聲明：

在這篇文章中，我使用“大型二進(jìn)制文件”來表達(dá)一個(gè)包含所有依賴性的二進(jìn)制文件。我的本意并不是指整個(gè)32位與64位轉(zhuǎn)換。如果單純立足Java與JVM領(lǐng)域，我會(huì)使用“uberjar”一詞。但之所以沒有使用，是因?yàn)槲蚁Ｍ诒硎鲋泻w值得肯定的GO語言及其生態(tài)系統(tǒng)。

如果再來一次我絕對(duì)會(huì)使用“超級(jí)二進(jìn)制”這個(gè)詞，雖然它代表著我個(gè)人的工作主要集中在JVM領(lǐng)域，但其表意相對(duì)更為準(zhǔn)確。這已經(jīng)是我能想到的最好的表達(dá)，因此在這篇文章中，我轉(zhuǎn)而使用“超級(jí)二進(jìn)制”的說法。

我希望開發(fā)者們能夠意識(shí)到，他們最喜愛的計(jì)算機(jī)編程方式可能并不適用于云端分布式計(jì)算體系。這里我要反復(fù)強(qiáng)調(diào)這一點(diǎn)，而且相信很多開發(fā)者已經(jīng)感覺到，云計(jì)算體系需要越來越多地適應(yīng)他們編寫的PHP代碼、Ruby代碼或者是Python代碼，而他們卻從來不會(huì)在代碼層面適應(yīng)這個(gè)新的世界。

如果您正在著手啟動(dòng)新項(xiàng)目，并預(yù)計(jì)其規(guī)模將會(huì)逐漸增大——您可能需要因此考慮其可擴(kuò)展性，或者單純重視高可用性——那么您可以使用專為云環(huán)境設(shè)計(jì)的現(xiàn)代語言。目前，很多新語言都能提供前所未有的新鮮特性，我個(gè)人使用過且給我留下深刻印象的有Go和Clojure。我個(gè)人對(duì)Rust、Scala以及Kotlin經(jīng)驗(yàn)不多，所以沒法討論太多。當(dāng)然，它們應(yīng)該也非常出色（在以往的文章中，很多讀者朋友認(rèn)為我是故意忽略了一些語言。我絕不是故意侮辱這些語言，但限于個(gè)人接觸范圍，我只會(huì)提及自己實(shí)際使用過的方案）。我讀過一些與Scala Akka框架的文章，并發(fā)現(xiàn)其中包含不少非常精彩的思路。因此雖然沒有實(shí)際使用過，但我認(rèn)為其確實(shí)設(shè)計(jì)水平極高且充滿現(xiàn)代感。

在我早前的文章中，網(wǎng)友btown寫道：

任何認(rèn)為一切現(xiàn)代Web應(yīng)用程序都是使用Golang或JVM開發(fā)完成的人，都生活在一種奇怪的自我認(rèn)知循環(huán)當(dāng)中。

再次強(qiáng)調(diào)，很多語言都非常出色; 但我不可能了解所有語言，因此只能對(duì)其中一些我親自接觸過的語言作出評(píng)價(jià)。另外，我也會(huì)批評(píng)自己曾經(jīng)使用過的舊有語言——包括PHP、Ruby以及最近人氣爆棚的Python。它們?cè)从谝环N舊有范式工，因此不適用于云端的微服務(wù)與分布式架構(gòu)。我曾在《Docker正保護(hù)我們需要盡量擺脫的編程范式》一文中對(duì)此進(jìn)行過探討。現(xiàn)在看來，似乎大家并沒有認(rèn)真考慮這個(gè)問題。我想起2000年前后，面向?qū)ο缶幊滔破鸬目駸崂顺边_(dá)到頂峰。那時(shí)候，幾乎沒人敢站出來反對(duì)這種模式。科技行業(yè)一直認(rèn)為自身是完全開放的，但實(shí)際上其中仍充斥著各類驅(qū)動(dòng)因素。在接下來的幾年中，各參與者紛紛退卻，留下一地雞毛與吃瓜群眾們的嘲笑聲。結(jié)合本文的主旨，2000年XML與面向?qū)ο缶幊坛霈F(xiàn)了過度炒作，而如今的Docker亦處于同樣的狀態(tài)之下。

Clojure語言我用得比較多，而其似乎非常適合用于編寫應(yīng)用程序并創(chuàng)建綁定依賴關(guān)系的uberjar。我也很清楚如何建立起像Jenkins這樣的系統(tǒng)，因此我的Clojure build完全能夠?qū)崿F(xiàn)自動(dòng)化運(yùn)行。我聽說很多企業(yè)選擇了令人難以置信的極端路線，其在構(gòu)建無外部依賴關(guān)系的應(yīng)用程序時(shí)，會(huì)將數(shù)據(jù)庫(kù)等全部綁定在uberjar當(dāng)中。請(qǐng)參考《利用Clojure與AWS在7個(gè)月中實(shí)現(xiàn)600倍增長(zhǎng)》一文中的內(nèi)容：

這推動(dòng)了決策二的出爐。由于數(shù)據(jù)集體積較小，因此我們能夠?qū)⒄麄€(gè)內(nèi)容數(shù)據(jù)庫(kù)添加至我們的某一版本當(dāng)中。沒錯(cuò)，您沒看錯(cuò)。我們利用Solr的一個(gè)嵌入式實(shí)例構(gòu)建我們的軟件，并采取標(biāo)準(zhǔn)化、清潔化非關(guān)系數(shù)據(jù)庫(kù)作為酒店庫(kù)存管理方案，并將其共同塞進(jìn)應(yīng)用程序部署方案當(dāng)中。

我們利用這種非傳統(tǒng)處理方式得到了巨大收益。首先，我們消除了重要的故障點(diǎn)——即代碼與數(shù)據(jù)間的不匹配問題。任何版本的軟件都將能夠正常工作——即使多年后我們將其轉(zhuǎn)移至其它系統(tǒng)當(dāng)中，且在此期間對(duì)內(nèi)容數(shù)據(jù)庫(kù)作出各類改動(dòng)，都不會(huì)影響這一結(jié)果。在這種情況下，針對(duì)不同環(huán)境的部署與配置管理工作變得極為輕松。
其次，我們?cè)诿嫦蛴脩魧又袑?shí)現(xiàn)了橫向無共享可擴(kuò)展性。其擴(kuò)展能力相當(dāng)相當(dāng)可觀。
如果不需要引入新技術(shù)（例如Docker）就能實(shí)現(xiàn)這種大規(guī)模擴(kuò)展，那么當(dāng)然沒必要多此一舉。以最簡(jiǎn)單的方式解決問題才是我們應(yīng)當(dāng)堅(jiān)持的原則。如果從Ruby/Python/Perl轉(zhuǎn)向新的語言及生態(tài)系統(tǒng)，而且能夠以更少的技術(shù)與移動(dòng)部件實(shí)現(xiàn)規(guī)?；?，那么大家應(yīng)當(dāng)甚至說必須采取這樣的處理方式。再次強(qiáng)調(diào)，我們的原則是盡可能以最簡(jiǎn)單的方式實(shí)現(xiàn)目標(biāo)，而且在大多數(shù)情況下這意味著您應(yīng)盡可能降低所使用技術(shù)的數(shù)量。受到Rich Hickey的啟發(fā)，我將“簡(jiǎn)單”與“簡(jiǎn)易”區(qū)分開來。使用一門您已經(jīng)了解的語言非?！昂?jiǎn)易”，學(xué)習(xí)一門新語言很困難——但后者卻更“簡(jiǎn)單”，或者說能夠減少系統(tǒng)中的技術(shù)總量。這里的“簡(jiǎn)單”意味著您的系統(tǒng)最終能夠以更簡(jiǎn)單的方式運(yùn)作——其代碼規(guī)模更小、配置更單純或者使用的技術(shù)數(shù)量更少。

在此前文章的評(píng)論當(dāng)中，不少讀者朋友認(rèn)為我總是提到Jenkins的作法代表著我的心態(tài)已經(jīng)過時(shí)——但有時(shí)候必須承認(rèn)，無聊的東西不一定就不好：

無聊的好處（限制水平較高）在于，這些東西的功能相對(duì)更容易理解。而更重要的是，我們能夠更輕松地了解其故障模式。……但對(duì)于閃閃發(fā)光的新技術(shù)而言，其中的未知因素要多得多，這一點(diǎn)非常重要。
換句話來說，已經(jīng)存在了十年的軟件更易于理解，而且未知因素更少。未知因素越少，運(yùn)營(yíng)開銷越低，這絕不是壞事。

我意識(shí)到，很多開發(fā)者都存在著極強(qiáng)的偏見。在閱讀這類文章時(shí)，他們傾向于揪住一個(gè)理由來駁斥整篇文章。因此如果我提到Jenkins、Ansible、Go、Clojure、Kotlin或者Akka等任何技術(shù)方案，他們都會(huì)專注于尋找這些技術(shù)中存在的缺陷，以此將文章本身貶得一文不值。而除了添加免責(zé)聲明之外，我不知道要怎樣才能跟這部分讀者朋友真正溝通——事實(shí)上，我覺得即使是添加了聲明，不想聽的讀者也仍然不會(huì)聽。

在之前的文章中，網(wǎng)友tytso寫道：

關(guān)于Go語言是大型二進(jìn)制文件先驅(qū)的說法很明顯是錯(cuò)誤的。數(shù)十年以來，人們一直在利用靜態(tài)二進(jìn)制文件（有時(shí)候會(huì)配合內(nèi)置數(shù)據(jù)資源）解決這個(gè)問題。MacOS就是其中的代表。

在這里，我要對(duì)自己的表意不清問題表達(dá)歉意。我實(shí)際上想要表達(dá)的是將所有依賴關(guān)系、一切必要配置乃至全部必要的資源都塞進(jìn)同一個(gè)二進(jìn)制文件，從而簡(jiǎn)化整體系統(tǒng)資源機(jī)制的作法。這種實(shí)踐方式在概念范圍上比簡(jiǎn)單的靜態(tài)庫(kù)鏈接更為廣泛。現(xiàn)代持續(xù)集成系統(tǒng)可通過配置以確保各二進(jìn)制文件皆被給予特定配置詶，而這些配置信息可能以惟一方式對(duì)應(yīng)二進(jìn)制文件的特定實(shí)例。因此即使您需要同時(shí)運(yùn)行同一應(yīng)用程序的上千個(gè)實(shí)例，亦可構(gòu)建起上千個(gè)在配置方面略有區(qū)別的實(shí)例變種。當(dāng)然，您可以使用Jenkins這類相對(duì)陳舊的構(gòu)建系統(tǒng)完成這項(xiàng)任務(wù)。這些系統(tǒng)易于理解，但在另一方面也確實(shí)比較無聊。但無聊不應(yīng)該成為您選擇Docker的理由——其可能帶來可怕的復(fù)雜性挑戰(zhàn)。（當(dāng)然，請(qǐng)別糾結(jié)于我在這里將Jenkins作為例子的情況，大家也可以根據(jù)喜好選擇Travis、TeamCity或者Bamboo。我常常驚訝于很多開發(fā)者居然會(huì)因?yàn)橐环N方案的選擇而放棄對(duì)整篇文章的認(rèn)同甚至是閱讀。）

有些讀者表示：

Docker能夠保護(hù)用戶免受云服務(wù)供應(yīng)商鎖定問題的影響。

當(dāng)然不是。任何一款標(biāo)準(zhǔn)化部署DevOps工具都能幫助我們解決供應(yīng)商鎖定問題。而且，這類工具選項(xiàng)可一點(diǎn)都不少見：

網(wǎng)友friend-monoid 寫道：

如果我的同事無需了解如何正確部署應(yīng)用程序，那么他們的工作內(nèi)容將得到顯著簡(jiǎn)化。如果我可以將他們的工作成果放進(jìn)容器當(dāng)中，而無需因語言或風(fēng)格而受到影響，那么我的工作內(nèi)容也將得到顯著簡(jiǎn)化。我不必再為處理崩潰、無限循環(huán)或者其它代碼錯(cuò)誤而分神。

網(wǎng)友notyourday的回應(yīng)則與我的態(tài)度不謀而合：

當(dāng)然了，因?yàn)槟阒皇前堰@套邏輯搬到了“編排”與“管理”層當(dāng)中。你仍然需要編寫代碼以正確執(zhí)行。就算給豬畫口紅，豬也仍然是豬。

更何況，如果您身在一家小公司，而且開發(fā)人員總共只有幾個(gè)人，那么將不可避免地處理彼此的代碼結(jié)果。而如果您身在大型企業(yè)，那么其中將具有獨(dú)立于開發(fā)團(tuán)隊(duì)之外的DevOps團(tuán)隊(duì)——他們多年來一直專注于處理此類問題，包括利用各類健康狀態(tài)檢查方案。健康檢查同樣涉及代碼編寫，Docker的標(biāo)準(zhǔn)化范圍并不能涵蓋這部分工作。作為應(yīng)用的開發(fā)者，您需要?jiǎng)?chuàng)建對(duì)應(yīng)端點(diǎn)，從而將200條響應(yīng)發(fā)送給DevOps以進(jìn)行定期測(cè)試。在這種情況下，Docker實(shí)際上起不到任何作用。大部分DevOps團(tuán)隊(duì)都擁有專門用于測(cè)試應(yīng)用程序是否活動(dòng)的腳本，如果目標(biāo)應(yīng)用沒有響應(yīng)，那么其將被終止并重新啟動(dòng)。

網(wǎng)友Lazare寫道：

舉例來說，我正利用腳本語言（例如Ruby、PHP或者Node.js）構(gòu)建基于舊式腳本模式的現(xiàn)有代碼庫(kù)。
.……我可以考慮如何將全部現(xiàn)有代碼打包進(jìn)Docker容器當(dāng)中，并配合一些編排方案，而后進(jìn)行發(fā)布。
根據(jù)這篇文章，我發(fā)現(xiàn)作者認(rèn)為用（超級(jí)）二進(jìn)制文件的效果更好。但情況是這樣的：您可以對(duì)PHP應(yīng)用程序進(jìn)行Docker化，這并不困難。但我們要如何構(gòu)建起（超級(jí)）二進(jìn)制文件？如果你的答案是“用Golang重寫整套代碼庫(kù)”，那這顯然毫無意義；我們首先沒有足夠的資源完成這項(xiàng)工作，其次就算這樣做了，我們也不打算采取這種毫無性價(jià)比可言的方法。最后，無論如何，我們都不喜歡Golang語言。

在這個(gè)例子當(dāng)中，這家企業(yè)長(zhǎng)久以來一直在使用PHP應(yīng)用程序，現(xiàn)在的目標(biāo)則是對(duì)該應(yīng)用程序進(jìn)行Docker化。為什么會(huì)有這樣的結(jié)論？發(fā)生了哪些變化，導(dǎo)致該應(yīng)用程序需要進(jìn)行Docker化？這就像是一個(gè)人為設(shè)定的例子。在Docker化之前，您的應(yīng)用程序運(yùn)作情況如何？舊有方法的問題是什么？您覺得Docker能夠解決這些問題嗎？

這款應(yīng)用程序的最終目標(biāo)是否能夠與其它（或者其自身的更新版本）應(yīng)用程序?qū)崿F(xiàn)編排與協(xié)調(diào)？Docker加編排通常意味著Docker加Kubernetes。（當(dāng)然，您也可以選擇使用Mesos或者Nomad等來代替Kubernetes）。這是一套非常復(fù)雜的組合方案，企業(yè)在選擇這一道路前應(yīng)該進(jìn)行認(rèn)真思考。請(qǐng)參閱《K8s是否太過復(fù)雜？》如果您的應(yīng)用規(guī)模不大，那么對(duì)其進(jìn)行整體重寫其實(shí)是個(gè)不錯(cuò)的選擇; 而如果您的應(yīng)用規(guī)模龐大，那么您應(yīng)該思考是否存在其它更為簡(jiǎn)單的實(shí)現(xiàn)途徑——例如編寫一些Chef或Ansible腳本。

我曾經(jīng)遇到過一款規(guī)模龐大的整體式應(yīng)用，其以PHP編寫而成，且使用到Symfony框架。這款應(yīng)用出現(xiàn)了糟糕的性能問題。我們開始逐步對(duì)其進(jìn)行拆分——將用于進(jìn)行HTML模板渲染的Symfony保持原狀，而對(duì)真正決定性能的部分以其它語言進(jìn)行重新編寫。我在《小型應(yīng)用的架構(gòu)問題》一文中已經(jīng)對(duì)此作出了陳述。當(dāng)時(shí)，DevOps團(tuán)隊(duì)正在利用Puppet及一些自定義腳本處理部署工作。這對(duì)我們來說已經(jīng)足夠了。無聊而穩(wěn)定的技術(shù)，確實(shí)能夠起到很好的效果。

請(qǐng)記住，您的時(shí)間是有限的。無論您投入多少時(shí)間對(duì)自己的PHP代碼進(jìn)行Docker化，您的時(shí)間都被占用了——這意味著您無法利用其完成其它現(xiàn)代化轉(zhuǎn)型。因此，請(qǐng)確保投入能夠帶來切實(shí)回報(bào)。

而讓人感到奇怪的是，人們?cè)谟懻揇ocker時(shí)，往往并不會(huì)列舉那些真正需要進(jìn)行編排的應(yīng)用示例。我見過在Spark上長(zhǎng)時(shí)間運(yùn)行的數(shù)據(jù)分析腳本，其利用Nomad進(jìn)行編排。我意識(shí)到這是一套龐大的系統(tǒng)，其每天都會(huì)將數(shù)TB數(shù)據(jù)添加至Kafka當(dāng)中，而后來到Apache Storm，最后是ElasticSearch。這套系統(tǒng)擁有一套復(fù)雜的運(yùn)行狀態(tài)檢查與監(jiān)控功能，但對(duì)于大部分工作而言，Storm本身就可以充分編排工具。Web應(yīng)用程序需要在處理海量數(shù)據(jù)之前，首先處理大量業(yè)務(wù)流程。Twitter就面對(duì)著規(guī)?？捎^的數(shù)據(jù)，其利用Aurora進(jìn)行編排。您的規(guī)模能夠與Twitter相提并論嗎？如果您在普通網(wǎng)站上使用Docker與Kubernetes，請(qǐng)馬上停下——我們有眾多更簡(jiǎn)單的網(wǎng)站運(yùn)行方法。我已經(jīng)擁有長(zhǎng)達(dá)25年的建站經(jīng)驗(yàn)，相信我，絕大多數(shù)網(wǎng)站都不需要Docker。

網(wǎng)友mwcampbell寫道：

“我真的不太贊同投入大量精力保持舊有技術(shù)正常運(yùn)行的作法?！?br/>我強(qiáng)烈反對(duì)這部分內(nèi)容。為了真正在技術(shù)與文明方面取得進(jìn)展，我們需要確保自己不會(huì)浪費(fèi)時(shí)間重新創(chuàng)造業(yè)已存在的解決方案——換言之，我們應(yīng)保持舊有技術(shù)的運(yùn)作。因此，如果Docker能夠讓2007年編寫完成的Rails應(yīng)用正常運(yùn)行，那實(shí)在是太贊了。事實(shí)上，我們?nèi)匀粦?yīng)該使用Rails、Django以及PHP等開發(fā)新的應(yīng)用程序。即使不再時(shí)髦，我們?nèi)杂欣碛墒褂眠@些已經(jīng)非常成熟的平臺(tái)與工具。
“時(shí)髦”這個(gè)詞不禁讓我想到技術(shù)領(lǐng)域廣泛存在的一種錯(cuò)誤認(rèn)知。我們能不能停止這種對(duì)時(shí)髦的盲目追捧？舉例來說，非要把技術(shù)與流行文化混為一談，就好像是認(rèn)為搖滾音樂黃金年代出現(xiàn)的一切音樂作品如今都已經(jīng)沒有存在的必要。相反，好的技術(shù)并不是流行音樂; 在1993年能夠順利執(zhí)行的方案，沒準(zhǔn)也仍然適合如今的需求場(chǎng)景。

這是一條明顯屬于反話的評(píng)論。很明顯，自認(rèn)為清醒的現(xiàn)實(shí)主義者認(rèn)為我們應(yīng)該把一切東西都Docker化，但像我這樣的瘋子則認(rèn)為我們應(yīng)該繼續(xù)使用舊有DevOps工具并將其與新型語言加以結(jié)合。在其看來，我的選擇是受到了“時(shí)尚”的驅(qū)動(dòng)，而他們對(duì)Docker的熱愛則是出于“真正在技術(shù)與文明方面取得進(jìn)展”的偉大愿望。

我的觀點(diǎn)是，只要陳舊而無聊的技術(shù)仍然能夠發(fā)揮自己的分內(nèi)作用，且不會(huì)因繼續(xù)使用而帶來額外的成本，我們就應(yīng)該繼續(xù)加以使用。但當(dāng)技術(shù)的運(yùn)行方式發(fā)生重大變化時(shí)，我們應(yīng)當(dāng)自問，某些技術(shù)是否已經(jīng)不再適應(yīng)新環(huán)境的需求。更具體地講，隨著云計(jì)算以及云環(huán)境下微服務(wù)架構(gòu)的興起，我們必須重新思考自身對(duì)技術(shù)方案的選擇。其中的指導(dǎo)原則應(yīng)該是，“我們完成當(dāng)前目標(biāo)的最簡(jiǎn)單方法是什么？”如果舊有技術(shù)能夠完成目標(biāo)，而且也屬于最簡(jiǎn)單的方法，那么其就應(yīng)該是最優(yōu)選擇。但如果新技術(shù)能夠幫助我們簡(jiǎn)化系統(tǒng)，那么我們就應(yīng)該積極接納這種新方案。

網(wǎng)友chmike寫道：

容器不僅是依賴關(guān)系的解決方案，同時(shí)也能夠有效保護(hù)邊界。

網(wǎng)友neilwilson則回應(yīng)稱：

這只是chroot的花哨強(qiáng)化版。不要相信那么多Docker宣傳。多年以來，明智的管理員一直在做類似的事情，只是我們不會(huì)花大價(jià)錢進(jìn)行公關(guān)推廣。
這也代表了我個(gè)人的全部意見。

在前文中，我曾經(jīng)提問“為什么不使用不存在外部依賴關(guān)系的超級(jí)二進(jìn)制文件？”大家可能會(huì)回答，“Docker就是這么做的！它就是一個(gè)大型二進(jìn)制文件，其中包含了應(yīng)用程序運(yùn)行所需要的一切！而且它還不依賴于任何語言！你可以使用其配合Ruby、PHP、Python、Java、Haskell乃至一切語言！”

說得沒錯(cuò)，但我建議企業(yè)應(yīng)該尋找機(jī)會(huì)減少其使用的技術(shù)方案的數(shù)量。也許大家可以利用現(xiàn)代語言與生態(tài)系統(tǒng)，從而以原生方式實(shí)現(xiàn)這種超級(jí)二進(jìn)制設(shè)計(jì)。

很多人認(rèn)為Docker的反對(duì)者們之所以提出批評(píng)，是因?yàn)槠錄]有能力變更其所在企業(yè)中的技術(shù)方案。但我們的假設(shè)是，企業(yè)實(shí)際上是在自發(fā)使用異構(gòu)混合技術(shù)，其中也包括一些不適合在云中以分布式計(jì)算實(shí)現(xiàn)的舊有技術(shù)。因此，Docker其實(shí)是一種“隱身咒”，其實(shí)際作用就是隱藏企業(yè)無法調(diào)整自身語言與生態(tài)系統(tǒng)以適應(yīng)云端分布式計(jì)算架構(gòu)的現(xiàn)實(shí)問題。

從長(zhǎng)遠(yuǎn)角度來看，這種拒不改進(jìn)的態(tài)度會(huì)毀掉一家企業(yè)。我不造成一味追求科技領(lǐng)域的最新潮流，但我支持不斷重新評(píng)估最有利于企業(yè)自我技術(shù)成果。目前，計(jì)算的總體實(shí)現(xiàn)方式正在發(fā)生變化，而被動(dòng)接受傳統(tǒng)應(yīng)用終將成為企業(yè)的痛點(diǎn)，其會(huì)隨時(shí)間推移而拖慢企業(yè)的發(fā)展速度。而真正到傳統(tǒng)應(yīng)用程序無法繼續(xù)運(yùn)行時(shí)，重新編寫將給企業(yè)帶來更大的風(fēng)險(xiǎn)。如果企業(yè)能夠找到方法對(duì)現(xiàn)有應(yīng)用程序進(jìn)行拆分與現(xiàn)代化轉(zhuǎn)型，那是再好不過。事實(shí)上，微服務(wù)架構(gòu)最重要的特色就是其允許舊有應(yīng)用程序以增量化方式實(shí)現(xiàn)現(xiàn)代化。我在《漸進(jìn)式改善的珊瑚礁模式》一文中已經(jīng)談到過這一點(diǎn)。

在前文中，我提到過一家分析企業(yè)，其每天需要向Kafka當(dāng)中添加上TB數(shù)據(jù)，而后將其分發(fā)至Apache Storm，最后再到ElasticSearch。這家企業(yè)長(zhǎng)期以來一直使用Python。當(dāng)遇到性能問題時(shí)，他們希望使用Python并發(fā)系統(tǒng)（例如Tornado）在其系統(tǒng)中實(shí)現(xiàn)大規(guī)模并發(fā)。他們將這個(gè)項(xiàng)目交給一位非常出色的工程師（他此前在英特爾公司效力），并給了他3個(gè)月時(shí)間進(jìn)行新系統(tǒng)構(gòu)建。結(jié)果——完全失敗。他們無法獲得自己希望得到的性能提升，Tornado甚至無法帶來他們所期望的細(xì)粒度并發(fā)能力與并發(fā)水平。最后，他們終于接受了這樣一個(gè)現(xiàn)實(shí)——他們不可能在各個(gè)層面都始終堅(jiān)持使用Python。如今，他們開始轉(zhuǎn)向Go與Elixir，并承認(rèn)這才是能夠真正解決問題的辦法。（我相信這家企業(yè)肯定有點(diǎn)受傷——他們是真正的Python支持者，也是一群理想主義者。）

我對(duì)他們采取的重新評(píng)估方法表示造成，但我認(rèn)為企業(yè)應(yīng)該將這一環(huán)節(jié)納入運(yùn)營(yíng)體系并定期執(zhí)行。

下面是來自網(wǎng)友pmoriarty的最強(qiáng)Docker支持論據(jù)：

你也可以對(duì)一切配置管理工具（Ansible/Chef/Salt/CFEngine/Puppet）提出幾乎完全相同的批評(píng)。它們都是一大堆亂七八糟的產(chǎn)物，起作用時(shí)你可以偷著樂，但不靈的時(shí)候也會(huì)帶來可怕的噩夢(mèng)。
所有這些工具至少還需要幾十年才能徹底發(fā)展成熟。

是的，說得沒錯(cuò)。

需要一套用于運(yùn)行WordPress的recipe？Ansible能夠提供，Docker也可以。同樣的，Docker也能夠在運(yùn)行Drupal、MySQL或者無數(shù)其它任務(wù)時(shí)提供這樣的幫助。至少在提供DevOps常規(guī)需求的默認(rèn)設(shè)置方面，Docker的表現(xiàn)確實(shí)不錯(cuò)。

如果Chef或者Ansible能夠發(fā)展得更成熟，那么我們今天也就不需要圍繞Docker展開如此激烈的爭(zhēng)論了。據(jù)我所知，一家初創(chuàng)企業(yè)曾在2013年專注于為Chef構(gòu)建框架（他們希望自己的框架能夠成為DevOps領(lǐng)域的Ruby on Rails）。他們遇到了一些問題，并在過程中發(fā)現(xiàn)其它更加有利可圖的發(fā)展方向。最終，他們分神了，也失敗了。盡管如此，他們未完成的工作可能終有一天會(huì)成功。這樣的框架將具有直接依賴操作系統(tǒng)功能的優(yōu)勢(shì)，而無需像Docker那樣徹底掩蓋掉底層操作系統(tǒng)。

Chef與Ansible都曾經(jīng)承諾為所有潛在的機(jī)器類型與一切常見的DevOps任務(wù)提供數(shù)千套腳本。很明顯，二者一直都沒能完全實(shí)現(xiàn)承諾。2005年，每家企業(yè)都會(huì)有一名DevOps人員為公司內(nèi)的所有DevOps任務(wù)編寫定制化腳本——這似乎非常正常。但到2010年，明顯應(yīng)該出現(xiàn)更為集中的常規(guī)任務(wù)腳本庫(kù)，其具體程度應(yīng)該高于Perl CPAN庫(kù)，且高度關(guān)注資源管理與編排層面的一致性問題（以實(shí)現(xiàn)可移植性）與安全性問題。也是從這時(shí)開始，Chef快速飛騰，Ansible隨后趕上，Docker也在幾年后奮起直追。很多開發(fā)者認(rèn)為Docker最終帶來的正是Chef與Ansible長(zhǎng)久以來承諾但卻未能實(shí)現(xiàn)的效果。但長(zhǎng)久以來，Docker一直只適用于內(nèi)部開發(fā)工作。直到2015年，在生產(chǎn)環(huán)境中使用Docker仍然無異于自殺。即使是在2016年，試圖利用Docker支持生產(chǎn)系統(tǒng)的企業(yè)仍然遭遇到痛苦的枷鎖。而這一切在過去一年中，仍然沒有出現(xiàn)顯著改觀。

在我看來，Docker有朝一日將被定性為一個(gè)巨大的錯(cuò)誤。其中最強(qiáng)有力的論據(jù)在于，即使最終成為標(biāo)準(zhǔn)、始終最終發(fā)展成熟，Docker也只是為科技行業(yè)目前遭遇的種種難題貼上一張“創(chuàng)可貼”。由于缺少治本的能力，Docker的命運(yùn)不可能迎來良好的結(jié)果。

我懷疑，從現(xiàn)在開始的五年之后，將會(huì)出現(xiàn)一種復(fù)雜度更低的方法實(shí)現(xiàn)云端分布式計(jì)算的標(biāo)準(zhǔn)化——請(qǐng)大家與我一道見證這一猜想。當(dāng)然，就目前來講，Docker仍然無處不在且人氣爆棚。

后話

就如作者所言，很多時(shí)候，開發(fā)者對(duì)Docker的態(tài)度是因?yàn)樾录夹g(shù)的潮流而趨勢(shì)若騖，為了使用而使用，為了時(shí)髦而時(shí)髦，雖然如此，我們依然抵擋不住對(duì)新事物的狂熱，我們依然希望能夠?qū)W會(huì)，希望能在自己的項(xiàng)目，甚至是所在領(lǐng)域嘗試使用它，個(gè)人覺得，也無可厚非，畢竟技術(shù)是不會(huì)被限定某個(gè)規(guī)則之內(nèi)的，只要你覺得它合適用在你的項(xiàng)目中，他能給你帶來效率或者性能的提升，它就是合適的。