Docker

Docker這兩年可謂大紅大紫，仿佛一夜之間，街坊鄰居茶余飯后都在說Docker，我這也掰扯掰扯Docker那點兒事情，免得不好意思跟人搭訕~~

本文有點兒雜伐脖，筆者一直在思考热幔，為什么用Docker，Docker到底能做到什么讼庇，不能做到什么绎巨，什么樣的用法是正確的，圍繞著這些蠕啄，總結了這么一篇文章场勤。

首次發(fā)文，目的是為了交流觀點歼跟，文中認識若有偏差和媳，還請不吝賜教，我始終認為不斷交流溝通總結才是進步的最快階梯哈街。

1. Docker為啥火了留瞳？

1.1. 虛擬機的痛點

傳統(tǒng)云平臺上的虛擬機，為了兼容各種系統(tǒng)骚秦，都在宿主機上再虛擬了一層硬件層她倘，業(yè)務系統(tǒng)都運行在這層虛擬硬件層之上，意識不到托管主機的存在作箍，并且因為這種虛擬硬件的隔離性硬梁，使得虛擬主機操作系統(tǒng)可以不用意識宿主機系統(tǒng)特性而運行，這種特性最大的受益者曾經是陳舊服務器上的老系統(tǒng)胞得，因為硬件老化荧止，這些系統(tǒng)都面臨著無法運行的風險，但是虛擬機的出現(xiàn)，使得這種系統(tǒng)可以順利遷移到新服務器上繼續(xù)提供服務罩息，大大降低了企業(yè)IT投入成本嗤详。

曾經，虛擬機就是很多需求的最終解決方案瓷炮，老系統(tǒng)只要虛擬好硬件就可以繼續(xù)工作無需更換葱色，新系統(tǒng)在云上申請幾個主機（而不用花大價錢去搞幾個刀片）就可以運行，還不用擔心硬件升級的成本娘香，生活多么美好苍狰。

但是，時代變了烘绽，需求變了淋昭。

如今物聯(lián)網時代，公眾系統(tǒng)都面臨動輒上千萬客戶的沖擊安接，很多系統(tǒng)都需要管理上千臺服務器翔忽。在這種背景下，性能的彈性擴張盏檐，故障的自我愈合歇式，部署的自動化等需求變得極為迫切。（此處可以閉上眼睛）想象一下一臺虛擬機鏡像部署上千臺服務器的盛景胡野，想象一下當用戶潮汐涌來時虛擬機那擴張的緩慢景象材失，再想象一下突然因為一個小需求的修改，大批服務器又要重新規(guī)劃上線部署的痛苦硫豆。如今背景下必須得尋找到一個更合適的方案來應對這些龙巨。

1.2. 新的需求

虛擬機的速度，彈性已經很難應對如今快速變化的世界熊响，IT業(yè)界必須尋找一個更快旨别，更輕量的方案來應對。

部署要快汗茄，能夠通過幾個簡單命令就能完成大規(guī)模（很多時候都是上千服務器實例）新系統(tǒng)的自動部署昼榛。并且這樣的部署重啟最好是秒級的。

彈性擴張要快剔难，平時系統(tǒng)都能穩(wěn)定運行胆屿，到了雙11就應對不了直接宕機，這是無法接受的偶宫，但是也不能因為一年一度的雙11就購買大量的昂貴硬件來應對非迹，用戶更希望能夠通過客戶使用量來進行靈活彈性伸縮，能夠在幾秒之內就擴張大量的實例來應對使用量潮汐纯趋。

版本更新或者故障恢復時也要快憎兽，并且要盡量少進行手動干預冷离。

能夠充分利用宿主機資源，這個需求也許沒那么強烈纯命，因為就算是有損耗西剥，還可以堆硬件來彌補這樣的問題。榨干宿主機資源也許是作為IT人的一個目標亿汞。

說了這么多瞭空，就是讓Docker能夠用一個優(yōu)雅的姿勢閃亮登場。

2. 實現(xiàn)Docker的技術基礎

虛擬機的劣勢自然就是Docker的優(yōu)勢疗我，啟動快咆畏，便于部署，因為沒有虛擬硬件層因此性能損耗小吴裤，而運行環(huán)境基本上做到了隔離旧找，不會對宿主機造成影響（注意“基本上”這個詞，因為共享內核麦牺，理論上某一個容器破壞內核搞掉整臺宿主機是可以的）钮蛛。

Docker使用的技術基礎，都不是什么新東西剖膳，但是Docker用go語言將其捏合到了一起魏颓，后面我們討論Docker各種效率問題的時候也會發(fā)現(xiàn)，其實我們討論的更多的是Linux本身的特性潮秘，Docker只是將這些特性組合到了一起而已琼开。

使用的核心幾個技術都在下面的圖中：

Docker and Kernel (1).png

2.1. 名字空間（namespace）技術

洪荒時代（其實是1979年易结，也沒那么久遠）枕荞，Unix出現(xiàn)了一種技術，叫做chroot（change root directory）搞动，可以在UNIX系統(tǒng)上創(chuàng)造一個封閉的目錄空間躏精，程序就直接在這個封閉目錄空間中運行而不影響系統(tǒng)整體，是系統(tǒng)環(huán)境隔離的雛形鹦肿。這技術非常成熟矗烛，我最近一次用還是在chroot空間里面自己編譯LFS系統(tǒng)，但是其沉寂了很久沒有繼續(xù)發(fā)展箩溃，也許是沒有需求就沒有推動動力吧瞭吃。

2002年，從Linux kernel 2.4.19開始涣旨，linux加入了一個新的技術歪架，叫做名字空間（namespace），這項技術提供了更豐富的隔離方案霹陡，不僅僅能夠進行目錄隔離了和蚪，連PID止状，UID，UTS（host）攒霹，NET怯疤，IPC，MNT都能夠進行隔離催束。下面這個表格可以看到如今的Linux內核都支持那些隔離內容集峦，基本上已經能夠滿足一般應用的隔離需要了。

分類系統(tǒng)調用參數(shù)相關內核版本

Mount namespacesCLONE_NEWNSLinux 2.4.19

IPC namespacesCLONE_NEWIPClinux 2.6.19

UTS namespacesCLONE_NEWUTSLinux 2.6.19

PID namespacesCLONE_NEWPIDLinux 2.6.24

Network namespacesCLONE_NEWNET始于Linux 2.6.24 完成于 Linux 2.6.29

User namespacesCLONE_NEWUSER始于 Linux 2.6.23 完成于 Linux 3.8

更詳細的內容可以參照這個：Namespaces in operation

2.2. Cgroup（Control Group）

隔離了進程的運行環(huán)境泣崩，但是各個進程的資源還是共享的少梁，一個進程如果消耗資源太多，別的進程就活不下去了矫付，這是無法接受的凯沪，虛擬機的資源隔離就做的很好，各個虛擬機就按照事先分配好的資源买优，在其配額內運行妨马，互不打擾。

Cgroup的詳細信息可以參照：Using Control Groups

cgroup的基本原理如下圖杀赢，如果想控制某一個進程烘跺，只要建立好cgroup文件，然后將相應的進程ID放進去就可以了脂崔。

作為Docker使用者滤淳，只要了解其能夠控制那些內容就可以了：

分類系統(tǒng)調用參數(shù)

cpu指定CPU時間配額，這是一個相對的概念砌左，例如如果兩個容器都被分配了50脖咐，那么這兩個容器應該平分CPU時間，也就是50%汇歹，如果再加一個是100屁擅，那之前兩個容器只能各分到25%

cpuset在多核系統(tǒng)中，指定分配哪幾個CPU核心給該組下的進程使用

blkio用于分配磁盤IO速度配額

memory用于分配內存限額产弹，此處一定要小心派歌，如果超出限額，Linux會殺死這個進程（報Out Of Memory錯誤）

net_cls用于分配網絡流量配額

device可以允許或者拒絕cgroup中的進程訪問設備

freezer用于掛起和恢復cgroup中的進程

2.3. Docker鏡像（Docker image）存儲技術

話不多說先扔個圖上來痰哨，沒看過這圖的先盯著這個圖看上一分鐘：

在Linux世界胶果，提到image這個詞兒，第一個反應想必是LiveCD斤斧，通過一張光盤早抠，就可以引導系統(tǒng)，甚至可以在系統(tǒng)上做修改折欠，并且這樣的修改不會反映到LiveCD中贝或，而保存在別的什么地方吼过，下一次你再啟動這個LiveCD，之前的修改還會看到咪奖。

神奇嗎盗忱？Docker鏡像/容器存儲的原理和這個差不多，先創(chuàng)建一個基礎鏡像層羊赵，然后將其他定制化修改也按照層的形式一層層的疊加趟佃，最后就成為了最終的鏡像，讀取這個鏡像和平時Linux mount 一個普通鏡像沒有任何分別昧捷，特別的是闲昭，容器在啟動的時候，為了支持寫操作靡挥，又在上面加了一個讀寫層序矩。所有被修改的文件的內容都會保存在這里。底層的鏡像層就會被多個容器所共享跋破，可供反復讀取與啟動簸淀。

因為歷史原因毒返，Docker并沒有提供統(tǒng)一的存儲方案劲绪，而是用插件驅動形式提供了好幾種存儲方案，包括AUFS贾富，DeviceMapper，OverlayFS弟劲，Overlay2等等（還有幾個醬油方案），下面挑幾個主流方案講講台囱。

1. AUFS（advanced multi-layered unification filesystem）：

要說AUFS，我認為它不算一個文件系統(tǒng)，被稱作一個多層文件組織方式也許更合適一些昧诱，可以在同一個文件夾下面進行層層疊加，對于同樣的文件苹丸，選取其中一個文件呈現(xiàn)在用戶面前施流，這實在是太符合Docker的設計理念了赖淤，自然而然就成為Docker長久以來默認的文件系統(tǒng)绷耍。如果你用Ubuntu/Debian吐限，默認就會用到它，但是Linux Kernel團隊不喜歡它褂始，AUFS作者也放棄加入內核的努力了诸典，所以在其他版本，尤其是Redhat系列版本上崎苗，都不會出現(xiàn)它的身影狐粱。

2. DeviceMapper：

這技術有點兒意思，以前存儲設備可以掛到各個文件夾下面使用胆数，但是各個設備資源不能互通肌蜻，比如說，有兩個1T硬盤必尼，但是想存1.5T的內容蒋搜，這事兒以前是沒得搞的，你總不能把1.5T的文件中間一刀切開然后分別存儲吧判莉，但是DeviceMapper技術解決了這個問題豆挽，它把兩個設備做成一個虛擬設備，然后系統(tǒng)訪問這個虛擬設備就可以了券盅，不用關心下面存儲調度的細節(jié)帮哈。更牛逼的是，這個虛擬設備可以混合虛擬設備锰镀，成為了一個遞歸的結構娘侍，其理論上可以無限擴展其存儲。我在Docker里面看到這個技術的時候互站，我的第一反應是私蕾，這玩意跟Docker鏡像分層技術有什么關系僵缺？為什么要用這個技術來做一個實現(xiàn)胡桃？這就要說Linux kernel團隊了，AUFS他們不喜歡磕潮，但是他們很喜歡DeviceMapper翠胰，把它做進了Kernel Mainline里面容贝，為了保證兼容性和可維護性，Docker團隊做了一個折衷之景，使用DeviceMapper的Thin Provisioning Snapshot技術斤富，來保證對于Redhat系列Linux的兼容。原理圖就是下面這個：

只是為了兼容性硬貼上去的技術锻狗，效率能好到哪里去啊满力，所以這項技術在Docker世界里面被黑就是很正常的事情了，不推薦使用轻纪。

3. OverlayFS：

AUFS的層次比較復雜油额，而且兼容性存在問題；DeviceMapper倒是血統(tǒng)正了刻帚，但是跟分層技術風馬牛不相及潦嘶，并且IO速度被人黑成了碳。OverLayFS天生就分成了兩層崇众，一個Upper層掂僵，還有一個Lower層，這大大簡化了層次結構顷歌，從Linux Kernel 3.18開始支持這種格式锰蓬，所以它也是一個正統(tǒng)血統(tǒng)的解決方案，兼容性沒有問題眯漩，性能也不差互妓，因此推薦使用。

幾個小話題：

Docker commit 命令是如何實現(xiàn)的坤塞？自然是把讀寫層固化冯勉，直接做成鏡像層的一部分了而已。

磁盤IO效率問題其實跟Docker本身關系不大了摹芙，那完全是鏡像文件系統(tǒng)和讀寫層驅動來決定的灼狰，后面也會提到。

Linux發(fā)行版真是多如牛毛浮禾，但是萬變不離其宗交胚，基本結構都是 內核 + 包管理器 + 周邊運行環(huán)境，特別是內核盈电，都可以互換蝴簇，也就是說，用CentOS的內核匆帚，給加上Debian的deb包熬词，一樣會跑的溜的飛起，DockerHub上的各種發(fā)行版的Docker鏡像，就是基于這種原理做出來的互拾，而且都可以互換運行歪今。

3. Docker的效率

提到虛擬化，第一反應肯定是效率問題颜矿，Docker真的快嗎寄猩？我們從幾個維度來討論一下Docker容器在性能上的表現(xiàn)如何，以及為什么它會這樣骑疆。

3.1. CPU效率

通過上面的討論田篇，我們知道，Docker并沒有對于CPU有任何類似于虛擬機一樣的虛擬指令化的操作箍铭，Docker用的就是實際的CPU來進行計算斯辰，僅僅是用cgroup進行了一點兒隔離而已，因此在這個維度坡疼，CPU的損耗幾乎可以忽略不計彬呻，Docker里面的進程和Native的進程沒任何區(qū)別，事實上各種Performance報告也證實了這一觀點柄瑰，IBM那份兒著名的報告里面闸氮，Docker的CPU效率和Navite進程的效率相差無幾。

參考：效率比對圖

自然的教沾，Docker也提供了參數(shù)可以限制其CPU資源占用率蒲跨，可以按照實際情況進行分配，管理方法和管理Navite進程一樣授翻。

3.2. 內存效率

內存這個維度的情況和CPU類似或悲，Docker并沒有任何內存頁虛擬映射等操作，都是直接向內核申請內存并直接進行讀寫堪唐，因此巡语，此處的性能也和Navite進程無異，不再贅述淮菠。

參考：效率比對圖

同樣的男公，Docker也提供了參數(shù)來限制每個容器的內存使用量。

3.3. 存儲效率

關于存儲話就有點兒長合陵，這要分幾條來進行討論枢赔。

1. AUFS：

AUFS不算一個文件系統(tǒng)，它必須跟后面的設備讀寫驅動一起工作才可以（比如ext4, xfs ）拥知。因此踏拜，對于新文件的讀寫，其實說的就是ext4和xfs的性能低剔，這跟普通的Native程序讀寫沒有太大的區(qū)別速梗。

2. DeviceMapper：

之前說過肮塞，這種技術本質上是一種設備管理方案。他壓根就沒有分層的概念镀琉，而且默認的讀寫方式是loop-lvm方式峦嗤，IO非常差蕊唐，必須更改成Direct-lvm才可以屋摔，有這個大坑我覺得這種方案不用也罷，就算是在Redhat系列上也不用它替梨。

3. OverlayFS：

這個解決方案是目前平衡性最好的解決方案钓试。雖然因為inode會被耗盡的bug，它被黑了很久副瀑，但是弓熏，無論從血統(tǒng)上來講，還是其本身的技術特征與Docker的契合度來講糠睡，它是平衡性比較好的解決方案挽鞠。建議在生產環(huán)境中使用它。它的讀寫效率也是跟讀寫文件系統(tǒng)的驅動有關狈孔，跟它本身沒有太大的關系信认。

4. Overlay2：

這是下一代的解決方案了，其設計理念天然解決了inode消耗的問題均抽，但是還處于試驗階段嫁赏，是將來解決Docker存儲問題的希望。

5. Volume掛載：

這是容器內外映射的一種方式油挥，僅僅調用了linux標準的 mount 功能潦蝇，因此讀寫效率和Native的mount之后讀寫沒有區(qū)別。

綜上深寥，在創(chuàng)建新文件攘乒，讀寫新文件情況下，AUFS惋鹅，OverlayFS都和Native效率差不多持灰，DeviceMapper必須要管理裸設備才能讓自己的IO跟上，DeviceMapper（loop-lvm）的IO效率最差负饲。

這幅圖是官方推薦的各種解決方案的概要堤魁，以供參考：

3.4. 網絡效率

這也是一個值得細細討論的問題，也分幾種情況說說返十。

1. HOST模式：

我們曾經說過妥泉，Linux內核的Namespace技術可以個Docker提供一個獨立的網絡棧來使用，但是HOST不同洞坑，它直接和宿主機共享網絡棧盲链，簡而言之，你如果打算追求效率的話，那就來用HOST模式吧刽沾，沒有任何效率損失本慕，其共享的程度甚至達到了連端口都會沖突，因此侧漓，在帶來效率的同時锅尘，還要注意這部分的沖突問題。

2. Bridge模式：

Docker在宿主機虛擬了一個網卡叫做Docker0布蔗，所有和外部的通信都通過Docker0來進行轉發(fā)藤违，這樣就達到了內部網絡棧的一個獨立性和可訪問性，如下圖：

一個數(shù)據包要走出去或者走進來纵揍，層次增加了不止一個顿乒，既有NAT，又有Iptable泽谨，效率不差才怪璧榄，事實也確實證明了這一點。如下圖：

和Native相比吧雹，響應速度損失不止一倍骨杂，比KVM還差。

3. Overlay網絡模式：

之前的兩種模式僅僅是在一個主機內部吮炕，但是我們的使用場景通常都是跨主機的腊脱，服務之間要通過跨主機進行通信，這通常的做法是：

1. 上一個服務注冊發(fā)現(xiàn)中心龙亲，比如Docker用的consul

2. 每臺服務主機上都加一個agent陕凹，所有跨主機通信，都走這個agent鳄炉，用UDP進行轉發(fā)杜耙，可以參考下面的圖。

在兩側都搞NAT拂盯！都要走虛擬網卡佑女！之前已經慢了很多了，這次要慢多少谈竿，自己可以計算一下团驱。當然，這不是說Overlay網絡不能用空凸，事實上生產環(huán)境也用了很多嚎花，但是用之前一定要知道要付出什么代價，在代價與收獲之間做出權衡呀洲。

3.5. 共享內核參數(shù)問題

原則上紊选，容器之間共享內核啼止，宿主機內核的參數(shù)調整自然會影響在其上運行的所有容器，但是從Docker 1.12開始兵罢，這個情況有了改變献烦，為了能夠讓各個容器能有限的進行一些內核參數(shù)的調整，特別是針對TCP/IP協(xié)議棧（net.*）能夠進行參數(shù)調整卖词，docker run 增加了 sysctl 參數(shù)条舔，允許用戶能夠修改適用于namespace隔離的內核參數(shù)沛膳。如下：

類別可配置內核參數(shù)

IPC Namespacekernel.msgmax, kernel.msgmnb, kernel.msgmni, kernel.sem, kernel.shmall, kernel.shmmax, kernel.shmmni, kernel.shm_rmid_forced Sysctls beginning with fs.mqueue.*

Network NamespaceSysctls beginning with net.*

但是這畢竟有限鳖悠，更多的參數(shù)只能在宿主機范圍內設定瓮增，不能在容器里面做定制修改赢乓。

4. 使用Docker的幾點建議

講了這么多宇弛，我想關于Docker應該有一點兒大致的印象了吧豆赏。最后再羅嗦幾點播揪。

4.1. 業(yè)務服務無狀態(tài)化

Docker最大的特點就是輕量杠园，啟動速度快顾瞪，擴張快，部署快抛蚁，因此具體實現(xiàn)業(yè)務的服務陈醒，都應該放在Docker里面進行部署，但是一定要強調瞧甩，并且一定要保證無狀態(tài)化钉跷，這是快速擴張，自主更新的基礎肚逸。

無狀態(tài)化包括：

1. 沒有Session

2. 磁盤中沒有任何中間結果文件

3. 內存中沒有任何處理中間結果爷辙，狀態(tài)

比較現(xiàn)實的替代方案是Redis，NFS文件共享等等朦促。

4.2. 使用服務名訪問其他容器

一個生產環(huán)境主機肯定不止一臺膝晾，服務肯定也是很多，因此跨主機訪問容器不可避免务冕，尤其時下Rancher血当，kubernetes這些都有資源調度機制，能夠對各個服務的容器進行動態(tài)遷移禀忆，因此使用IP地址直接進行訪問顯然是不現(xiàn)實的臊旭，幸好這種帶有資源調度的套件都有各自的DNS查詢方式，可以通過服務名直接訪問到后面的容器箩退，因此离熏，將有關聯(lián)的業(yè)務服務都放在一個網絡里面去吧，事半功倍乏德，保持最大的靈活性撤奸。

4.3. 針對某些對內核參數(shù)有要求的服務吠昭，采取獨立的資源調度機制

Docker容器是共享內核的，而內核很多參數(shù)都做不到容器隔離胧瓜，因此矢棚，如果宿主機內核更改了參數(shù)，會對其上所有容器造成影響府喳，某些參數(shù)對某些服務很有效蒲肋，對其他服務就是副作用，針對這種情況钝满，推薦采取特化的方式兜粘，讓那樣的服務獨立部署在特定調整好內核參數(shù)的宿主機上。

4.4. 針對內核版本敏感的服務弯蚜，配給特定版本內核的服務器

總會有這樣的服務存在孔轴，所以在將服務遷移到Docker之前要仔細的檢查內核兼容性問題，確保服務能夠正確運行碎捺，時刻謹記路鹰，內核是被共享的，Docker不是完全隔離的收厨！

4.5. 計算好每個容器的性能容量晋柱，并規(guī)定上限

虛擬機時代，不規(guī)劃好資源诵叁，虛擬機根本無法啟動雁竞，所以這根本不是一個問題，但是到了容器時代拧额，就算是不規(guī)定上限碑诉，Docker也能跑，但是因為所有的容器都共享一個宿主機的資源势腮，因此容器互相擠占联贩，某些容器無端占用資源（內存泄漏之類），就會把別的容器擠死捎拯。所以泪幌，還是事先規(guī)劃好容量吧，至少把資源侵占問題能夠控制在一個容器之內署照。

4.6. 基礎服務需要容器化嗎祸泪？

這里留了一個問號，也許你有很大的沖動恨不得把所有的服務建芙，包括nginx没隘，mysql，redis都給容器化了禁荸，這些服務都是有狀態(tài)的右蒲，非常難遷移阀湿，做動態(tài)擴展，并且在網絡IO上瑰妄，在磁盤IO上陷嘴，Docker都有各種各樣的問題。所以间坐，對于這些服務灾挨，一定要謹慎，好好的檢討竹宋，到底要不要容器化劳澄。

4.7. 為了能夠快速擴張，事先在宿主機上加載基礎鏡像

Docker的快速啟動讓人津津樂道蜈七，但是Docker容器在啟動的時候需要先將Docker鏡像拉下來秒拔，然后再啟動，如果鏡像比較大宪潮，那網絡傳輸時間消耗也是不可小視的溯警，因此趣苏，預先為各個宿主機先傳輸好鏡像吧狡相，這樣“有備無患”，需要的時候食磕，容器馬上就能啟動并投入工作尽棕。

4.8. 優(yōu)化你的Docker鏡像？

這又是一個問號彬伦，Docker鏡像是分層的滔悉，在Dockerfile里面多寫命令，只要這些命令涉及到了修改文件单绑，那么一條指令就是一層回官，層數(shù)多了自然就會有影響讀寫效率的擔心，但是這個證據不足搂橙，Docker團隊也一直無視這個問題歉提，所以我只是在這里提一下，盡量用一個命令去做好鏡像的配置区转，減少鏡像層數(shù)苔巨，有備無患吧。

4.9. 關于安全

說到底废离，容器之間是共享內核的侄泽，一個容器如果是惡意容器，那么會影響整臺服務器蜻韭，而且在容器內部確實能做得到悼尾，比突破虛擬機然后控制宿主機容易的多的多得多柿扣。將“它是共享內核的”時刻記在腦海里面是非常重要的。

1. 不要使用來源不明的容器闺魏，盡量使用DockerHub上的官方出品的容器窄刘，使用前要對Dockerfile做Review。

2. 在容器中不要用root用戶去運行你的應用舷胜，以防意外娩践。

3. Docker可以限定容器的權限和能力，具體參照在這里（Docker容器權限能力）, 去最小化它烹骨，但是要注意這可能會引起容器運行的不穩(wěn)定翻伺。

4. Docker官方推