Docker：一場令人追悔莫及的豪賭

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

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

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

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

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

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

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

有評論如下：

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

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

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

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

更可怕的是，我還沒有聽到任何一位技術(shù)管理者明確對這種“賭博”現(xiàn)狀作出陳述。大多數(shù)支持Docker的群體仍在不斷強(qiáng)調(diào)其帶來的可移植性、安全性或者編排與配置能力。沒錯，Docker確實能夠為我們提供可移植性、安全性或者編排與配置能力，但其代價也相當(dāng)可觀。在大多數(shù)情況下，編寫特定腳本反而難度更低。

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

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

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

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

然而，今年以來我們的大部分客戶都堅持

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

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

可能很多朋友都遇到過以下場景：

我：“我們不需要在項目早期使用Docker?！?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 確保任何競爭對手都不具備任何顯著的獨特性；

2. 確保每個人都使用Docker及Docker工具；

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

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

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

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

好吧，這里我們暫時把Docker和容器看成是同一種東西。在這樣的立場之下，我們再來回顧我之前發(fā)表的文章，看看其中哪些批評意見仍然符合現(xiàn)實。

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

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

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

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

如果您正在著手啟動新項目，并預(yù)計其規(guī)模將會逐漸增大——您可能需要因此考慮其可擴(kuò)展性，或者單純重視高可用性——那么您可以使用專為云環(huán)境設(shè)計的現(xiàn)代語言。目前，很多新語言都能提供前所未有的新鮮特性，我個人使用過且給我留下深刻印象的有Go和Clojure。我個人對Rust、Scala以及Kotlin經(jīng)驗不多，所以沒法討論太多。當(dāng)然，它們應(yīng)該也非常出色（在以往的文章中，很多讀者朋友認(rèn)為我是故意忽略了一些語言。我絕不是故意侮辱這些語言，但限于個人接觸范圍，我只會提及自己實際使用過的方案）。我讀過一些與Scala Akka框架的文章，并發(fā)現(xiàn)其中包含不少非常精彩的思路。因此雖然沒有實際使用過，但我認(rèn)為其確實設(shè)計水平極高且充滿現(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)，很多語言都非常出色; 但我不可能了解所有語言，因此只能對其中一些我親自接觸過的語言作出評價。另外，我也會批評自己曾經(jīng)使用過的舊有語言——包括PHP、Ruby以及最近人氣爆棚的Python。它們源于一種舊有范式工，因此不適用于云端的微服務(wù)與分布式架構(gòu)。我曾在《Docker正保護(hù)我們需要盡量擺脫的編程范式》一文中對此進(jìn)行過探討?，F(xiàn)在看來，似乎大家并沒有認(rèn)真考慮這個問題。我想起2000年前后，面向?qū)ο缶幊滔破鸬目駸崂顺边_(dá)到頂峰。那時候，幾乎沒人敢站出來反對這種模式?？萍夹袠I(yè)一直認(rèn)為自身是完全開放的，但實際上其中仍充斥著各類驅(qū)動因素。在接下來的幾年中，各參與者紛紛退卻，留下一地雞毛與吃瓜群眾們的嘲笑聲。結(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)自動化運行。我聽說很多企業(yè)選擇了令人難以置信的極端路線，其在構(gòu)建無外部依賴關(guān)系的應(yīng)用程序時，會將數(shù)據(jù)庫等全部綁定在uberjar當(dāng)中。請參考《利用Clojure與AWS在7個月中實現(xiàn)600倍增長》一文中的內(nèi)容：

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

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

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

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

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

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

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

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

有些讀者表示：

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

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

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

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

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

當(dāng)然了，因為你只是把這套邏輯搬到了“編排”與“管理”層當(dāng)中。你仍然需要編寫代碼以正確執(zhí)行。就算給豬畫口紅，豬也仍然是豬。

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

網(wǎng)友Lazare寫道：

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

在這個例子當(dāng)中，這家企業(yè)長久以來一直在使用PHP應(yīng)用程序，現(xiàn)在的目標(biāo)則是對該應(yīng)用程序進(jìn)行Docker化。為什么會有這樣的結(jié)論？發(fā)生了哪些變化，導(dǎo)致該應(yīng)用程序需要進(jìn)行Docker化？這就像是一個人為設(shè)定的例子。在Docker化之前，您的應(yīng)用程序運作情況如何？舊有方法的問題是什么？您覺得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)真思考。請參閱《K8s是否太過復(fù)雜？》如果您的應(yīng)用規(guī)模不大，那么對其進(jìn)行整體重寫其實是個不錯的選擇; 而如果您的應(yīng)用規(guī)模龐大，那么您應(yīng)該思考是否存在其它更為簡單的實現(xiàn)途徑——例如編寫一些Chef或Ansible腳本。

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

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

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

網(wǎng)友mwcampbell寫道：

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

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

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

網(wǎng)友chmike寫道：

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

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

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

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

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

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

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

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

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

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

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

是的，說得沒錯。

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

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

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

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

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

后話

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