- 論壇徽章:
- 18
|
從我上一次對(duì)Docker進(jìn)行評(píng)價(jià)到現(xiàn)在已然經(jīng)過了一年有余，想當(dāng)初我在文章里對(duì)這套容器技術(shù)方案的架構(gòu)設(shè)計(jì)缺陷與糟糕的用戶體驗(yàn)做出了嚴(yán)厲的批判。不過在這段時(shí)間當(dāng)中，Docker項(xiàng)目也開始逐步走向成熟，迎來自己的1.0版本并在Amazon的推動(dòng)下聲名大噪，但同時(shí)用戶挫敗感、過度宣傳引發(fā)的指責(zé)甚至因漏洞遭利用而引發(fā)主機(jī)感染越來越多。當(dāng)然，Docker Hub中私有庫(kù)的引入讓用戶不必再為了托管部署而運(yùn)行自有Registry系統(tǒng)，再配合webhook以及同GitHub的緊密集成， Docker看起來有一個(gè)良好的前途。
有鑒于此，我決定再給Docker一次機(jī)會(huì)，并以六個(gè)月為周期將其引入生產(chǎn)環(huán)境。結(jié)果非常糟糕，Docker性能極差，而旁門左道的解決方案加上以用戶體驗(yàn)為代表的種種短板簡(jiǎn)直令人抓狂。實(shí)際上，Docker的性能表現(xiàn)實(shí)在太差，禁用緩存功能竟然能夠加快build速度。
（感興趣的朋友可以查看reddit與ycombinator網(wǎng)站上與該主題相關(guān)的討論內(nèi)容）。
Dockerfile
Dockerfile存在著一系列問題，它令人討厭、充滿局限、不倫不類而且包含根本性缺陷。假如要構(gòu)建一個(gè)庫(kù)的多個(gè)鏡像，例如第二個(gè)鏡像包含內(nèi)容調(diào)試工具，但兩個(gè)鏡像擁有同樣的基礎(chǔ)運(yùn)行要求。Docker不支持這種做法（詳見9198號(hào)問題），我們無法擴(kuò)展Dockerfile（詳見735號(hào)問題），使用子目錄會(huì)破壞構(gòu)建上下文并導(dǎo)致用戶無法使用ADD/COPY（詳見2224號(hào)問題）或者“管道（piping）”（詳見2112號(hào)問題），我們也不能在構(gòu)建過程中通過環(huán)境變量實(shí)現(xiàn)有條件的指令變更（詳見2637號(hào)問題）。
我們給出的解決方案是創(chuàng)建一個(gè)基礎(chǔ)鏡像，兩個(gè)特定環(huán)境的鏡像以及其它一些包括重命名以及sed替換功能的Makefile自動(dòng)化。除此之外，Docker中還有一些意想不到的“功能”有可能導(dǎo)致環(huán)境變量$HOME消失，進(jìn)而產(chǎn)生無用的錯(cuò)誤信息。太令人厭惡了。
Docker緩存/層
Docker有能力利用COW（即寫入時(shí)復(fù)制）文件系統(tǒng)實(shí)現(xiàn)緩存Dockerfile指令，這一點(diǎn)與LVM快照機(jī)制相似，而且直到最近都只支持AuFS，而后者還存在大量問題。之后，0.7版本引入了多種不同的COW實(shí)現(xiàn)方式以改進(jìn)穩(wěn)定性與性能，感興趣的朋友可以點(diǎn)擊此處了解更多細(xì)節(jié)信息。
然而，這套緩存系統(tǒng)不智能，它不能阻止單一指緩存（詳見1996號(hào)問題），產(chǎn)生了一些意料之外的副作用。它的運(yùn)行速度也極為緩慢，如果禁用緩存并避免使用層，其構(gòu)建速度甚至能夠得到提升。而Docker Hub緩慢的上傳/下載速度則讓情況進(jìn)一步惡化，這個(gè)問題我們將在下文作進(jìn)一步評(píng)述。
這些問題均源自Docker整體所采用的糟糕的架構(gòu)設(shè)計(jì)，這直接導(dǎo)致它即使是在完全不適用的情況下，依然會(huì)強(qiáng)制執(zhí)行線性指令（詳見2439號(hào)問題）。作為構(gòu)建緩慢的解決方案，可以使用支持異步執(zhí)行的第三方工具，例如Salt Stack、Puppet甚至bash，它們完全能夠達(dá)成層的目的而使層變得沒用。
Docker Hub
Docker鼓勵(lì)用戶通過Docker Hub進(jìn)行社會(huì)化合作。用戶可以在上面發(fā)布Dockerfile——包括公開與私有文件。其他用戶可以通過FROM指令而不是復(fù)制/粘貼來繼承并使用這些Dockerfile。該生態(tài)系統(tǒng)類似于AWS市場(chǎng)以及Vagrant Boxes中的AMI，從理論上講還是非常有用的。
然而由于一些原因，Docker Hub的實(shí)現(xiàn)存在缺陷。Dockerfile不支持多FROM指令（詳見3378號(hào)、5714號(hào)以及5726號(hào)問題），這意味著只能繼承單個(gè)鏡像。此外，它沒有版本強(qiáng)制。舉例來說，dockerfile/ubuntu:14.04的作者可以替換該標(biāo)簽的內(nèi)容，這相當(dāng)于允許用戶使用軟件包管理器但又不沒有版本強(qiáng)制機(jī)制。而且正如下文所提到，Docker Hub在這方面存在著令人沮喪的速度緩慢的限制。
Docker Hub還擁有一套自動(dòng)化構(gòu)建系統(tǒng)，能夠檢測(cè)到庫(kù)中新提交內(nèi)容并觸發(fā)容器構(gòu)建。因?yàn)樵S多原因，這項(xiàng)功能也是完全沒用。由于幾乎不能定制，構(gòu)建配置受到了極大限制，甚至無法支持最基本的腳本執(zhí)行前/后的鉤子。Docker Hub采用一套特殊的項(xiàng)目結(jié)構(gòu)，一個(gè)項(xiàng)目下只能有一個(gè)Dockerfile，這破壞了我們先前提到的構(gòu)建解決方案，而且構(gòu)建速度極為緩慢。
我們的解決方案是使用CircleCI，它是一個(gè)優(yōu)秀的托管CI平臺(tái)，能夠從Makefile觸發(fā)Docker構(gòu)建并推送到Docker Hub。雖然這種方式無法解決速度慢的問題，但唯一的可選方案是使用我們自己的Docker Registry，其復(fù)雜程度都到了荒唐的地步。
安全性
Docker最初使用LXC作為默認(rèn)執(zhí)行環(huán)境，但現(xiàn)在，0.9版本默認(rèn)使用libcontainer。這使得用戶可以調(diào)整命名空間功能、權(quán)限，并且可以在使用合適的exec-driver時(shí)使用自定義的LXC配置文件。
這需要一直在主機(jī)上運(yùn)行一個(gè)root守護(hù)進(jìn)程，而且Docker一直存在著若干安全漏洞，例如CVE-2014-6407以及CVE-2014-6408。坦率地講，這些問題起初就不應(yīng)該存在。甚至Gartner公司也在其追蹤報(bào)告中給出了糟糕評(píng)價(jià)，并表達(dá)了對(duì)Docker的不成熟和安全性問題的擔(dān)憂。
按照設(shè)計(jì)，Docker對(duì)于命名空間功能給予充分信任，這就導(dǎo)致其攻擊面要比其它典型的虛擬機(jī)管理程序更寬。Xen擁有129項(xiàng)CVE，相比之下Linux則擁有1279項(xiàng)。在某些情況下上述問題并非不可接受，例如在Travis CI當(dāng)中進(jìn)行公開構(gòu)建，但這對(duì)于私有、多用戶環(huán)境來說無疑是危險(xiǎn)的。
容器與虛擬機(jī)并不是一回事
命名空間與cgroups功能極為強(qiáng)大，允許一個(gè)進(jìn)程及其子進(jìn)程擁有一個(gè)共享內(nèi)核資源——例如網(wǎng)絡(luò)堆棧以及進(jìn)程表——的私有視圖。這種細(xì)粒度控制與隔離機(jī)制配合上chroot jailing與grsec，能夠提供非常出色的保護(hù)層。一些應(yīng)用程序，如uWSGI，可以在沒有Docker的情況下直接利用這些特性的優(yōu)點(diǎn)，而不支持命名空間的應(yīng)用程序則可以利用firejail實(shí)現(xiàn)沙箱化處理。如果您有冒險(xiǎn)精神，可以將這種支持直接添加到自己的容器化項(xiàng)目的代碼中，例如LXC以及Dokcer，從而在單一內(nèi)核空間中利用這些特性的有點(diǎn)高效地運(yùn)行多套發(fā)行版。相較于虛擬機(jī)管理程序，這種作法有時(shí)候會(huì)有降低內(nèi)存使用率和減少啟動(dòng)時(shí)間的好處，但其代價(jià)就是降低安全性、穩(wěn)定性以及兼容性。舉個(gè)與Linux Kernel Interface相關(guān)的最糟糕的極端案例，在內(nèi)核及用戶空間中運(yùn)行不兼容或者未經(jīng)測(cè)試的glibc組合版本很可能引發(fā)意料之外的行為。
早在2008年LXC尚處于構(gòu)思階段時(shí)，硬件輔助虛擬化也僅僅誕生了幾年時(shí)間，許多虛擬機(jī)管理程序都存在著性能以及穩(wěn)定性問題。因此，虛擬化技術(shù)并沒有得到廣泛應(yīng)用，而面對(duì)成本以及物理基礎(chǔ)設(shè)施占用減少等優(yōu)勢(shì)，上述問題是可以接受的。不過如今我們的虛擬機(jī)管理程序在性能表現(xiàn)方面幾乎與裸機(jī)設(shè)備不相上下，而且有趣的是，在某些情況下速度更快。另外，托管的、按需分配的虛擬機(jī)速度越來越快，成本越來越低，DigitalOcean在性能與成本方面都要遠(yuǎn)遠(yuǎn)勝過EC2，這也使應(yīng)用程序與虛擬機(jī)之間進(jìn)行一對(duì)一映射從經(jīng)濟(jì)角度講成為可能。
[編輯意見]正如Bryan Cantrill提出的觀點(diǎn)，虛擬化技術(shù)的性能將受到工作負(fù)載類型的顯著影響。例如，IO任務(wù)繁重的應(yīng)用程序會(huì)導(dǎo)致性能降低。
在某些特定的應(yīng)用場(chǎng)景中，容器化確實(shí)是恰當(dāng)?shù)慕鉀Q方案，不過除非能夠明確說明為什么在你的應(yīng)用場(chǎng)景中選擇此類處理方式，否則你可能應(yīng)用使用虛擬機(jī)管理程序代替。而且即使使用虛擬化技術(shù)方案，你仍然應(yīng)該利用命名空間的優(yōu)點(diǎn)，而在應(yīng)用程序沒有對(duì)這些特性提供原生支持的情況下，像firejail這樣的工具可以提供幫助。
Docker并不是必須的
Docker增加了一個(gè)復(fù)雜的侵入層，使開發(fā)、故障排查以及調(diào)試工作的難度大幅上升，它帶來的問題往往多于它能夠解決的問題。它在部署上也沒有任何優(yōu)勢(shì)，因?yàn)槟闳匀恍枰每煺諏?shí)現(xiàn)響應(yīng)式自動(dòng)擴(kuò)展。更糟糕的是，如果大家并沒有使用快照機(jī)制，那么生產(chǎn)環(huán)境的擴(kuò)展就會(huì)依賴于Docker Hub的穩(wěn)定性。
目前有不少項(xiàng)目都在濫用容器化技術(shù)，例如baseimage-docker，該鏡像旨在通過運(yùn)行作為入口的init.d簡(jiǎn)化檢查、調(diào)試和兼容，甚至還提供一個(gè)可選的SSH服務(wù)器，實(shí)際上是將容器當(dāng)作虛擬機(jī)對(duì)待，雖然作者本人以無甚說服力的言詞反對(duì)這種觀點(diǎn)。
總結(jié)
如果開發(fā)流程合乎情理，那么你已經(jīng)明白Docker不是必須的。Docker中號(hào)稱能夠帶來助益的全部功能要么完全無用，要么實(shí)現(xiàn)很差，而其最大的優(yōu)勢(shì)直接使用命名空間就很容易實(shí)現(xiàn)。如果放在8年前，Docker是一個(gè)有趣的概念，但以現(xiàn)在的眼光來看，它幾乎是沒用的。 |
|
免費(fèi)注冊(cè)
發(fā)表于 2016-06-21 23:16
