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

本文有點(diǎn)兒雜卸耘，筆者一直在思考退敦，為什么用Docker，Docker到底能做到什么蚣抗，不能做到什么侈百，什么樣的用法是正確的，圍繞著這些翰铡，總結(jié)了這么一篇文章钝域。
首次發(fā)文，目的是為了交流觀點(diǎn)锭魔，文中認(rèn)識(shí)若有偏差例证，還請(qǐng)不吝賜教，我始終認(rèn)為不斷交流溝通總結(jié)才是進(jìn)步的最快階梯迷捧。

1. Docker為啥火了织咧？

1.1. 虛擬機(jī)的痛點(diǎn)

傳統(tǒng)云平臺(tái)上的虛擬機(jī)，為了兼容各種系統(tǒng)漠秋，都在宿主機(jī)上再虛擬了一層硬件層笙蒙，業(yè)務(wù)系統(tǒng)都運(yùn)行在這層虛擬硬件層之上，意識(shí)不到托管主機(jī)的存在庆锦，并且因?yàn)檫@種虛擬硬件的隔離性捅位，使得虛擬主機(jī)操作系統(tǒng)可以不用意識(shí)宿主機(jī)系統(tǒng)特性而運(yùn)行，這種特性最大的受益者曾經(jīng)是陳舊服務(wù)器上的老系統(tǒng)肥荔，因?yàn)橛布匣@些系統(tǒng)都面臨著無(wú)法運(yùn)行的風(fēng)險(xiǎn)朝群，但是虛擬機(jī)的出現(xiàn)燕耿，使得這種系統(tǒng)可以順利遷移到新服務(wù)器上繼續(xù)提供服務(wù)，大大降低了企業(yè)IT投入成本姜胖。

曾經(jīng)誉帅，虛擬機(jī)就是很多需求的最終解決方案，老系統(tǒng)只要虛擬好硬件就可以繼續(xù)工作無(wú)需更換，新系統(tǒng)在云上申請(qǐng)幾個(gè)主機(jī)（而不用花大價(jià)錢去搞幾個(gè)刀片）就可以運(yùn)行蚜锨，還不用擔(dān)心硬件升級(jí)的成本档插，生活多么美好。

但是亚再，時(shí)代變了郭膛，需求變了。

如今物聯(lián)網(wǎng)時(shí)代氛悬，公眾系統(tǒng)都面臨動(dòng)輒上千萬(wàn)客戶的沖擊则剃，很多系統(tǒng)都需要管理上千臺(tái)服務(wù)器。在這種背景下如捅，性能的彈性擴(kuò)張棍现，故障的自我愈合，部署的自動(dòng)化等需求變得極為迫切镜遣。（此處可以閉上眼睛）想象一下一臺(tái)虛擬機(jī)鏡像部署上千臺(tái)服務(wù)器的盛景己肮，想象一下當(dāng)用戶潮汐涌來(lái)時(shí)虛擬機(jī)那擴(kuò)張的緩慢景象，再想象一下突然因?yàn)橐粋€(gè)小需求的修改悲关，大批服務(wù)器又要重新規(guī)劃上線部署的痛苦谎僻。如今背景下必須得尋找到一個(gè)更合適的方案來(lái)應(yīng)對(duì)這些。

1.2. 新的需求

虛擬機(jī)的速度坚洽，彈性已經(jīng)很難應(yīng)對(duì)如今快速變化的世界戈稿，IT業(yè)界必須尋找一個(gè)更快，更輕量的方案來(lái)應(yīng)對(duì)讶舰。

1. 部署要快鞍盗，能夠通過(guò)幾個(gè)簡(jiǎn)單命令就能完成大規(guī)模（很多時(shí)候都是上千服務(wù)器實(shí)例）新系統(tǒng)的自動(dòng)部署。并且這樣的部署重啟最好是秒級(jí)的跳昼。
2. 彈性擴(kuò)張要快般甲，平時(shí)系統(tǒng)都能穩(wěn)定運(yùn)行，到了雙11就應(yīng)對(duì)不了直接宕機(jī)鹅颊，這是無(wú)法接受的敷存，但是也不能因?yàn)橐荒暌欢鹊碾p11就購(gòu)買大量的昂貴硬件來(lái)應(yīng)對(duì)，用戶更希望能夠通過(guò)客戶使用量來(lái)進(jìn)行靈活彈性伸縮堪伍，能夠在幾秒之內(nèi)就擴(kuò)張大量的實(shí)例來(lái)應(yīng)對(duì)使用量潮汐锚烦。
3. 版本更新或者故障恢復(fù)時(shí)也要快，并且要盡量少進(jìn)行手動(dòng)干預(yù)帝雇。
4. 能夠充分利用宿主機(jī)資源涮俄，這個(gè)需求也許沒(méi)那么強(qiáng)烈，因?yàn)榫退闶怯袚p耗尸闸，還可以堆硬件來(lái)彌補(bǔ)這樣的問(wèn)題彻亲。榨干宿主機(jī)資源也許是作為IT人的一個(gè)目標(biāo)孕锄。

說(shuō)了這么多，就是讓Docker能夠用一個(gè)優(yōu)雅的姿勢(shì)閃亮登場(chǎng)苞尝。

2. 實(shí)現(xiàn)Docker的技術(shù)基礎(chǔ)

虛擬機(jī)的劣勢(shì)自然就是Docker的優(yōu)勢(shì)畸肆，啟動(dòng)快，便于部署宙址，因?yàn)闆](méi)有虛擬硬件層因此性能損耗小轴脐，而運(yùn)行環(huán)境基本上做到了隔離，不會(huì)對(duì)宿主機(jī)造成影響（注意“基本上”這個(gè)詞曼氛，因?yàn)楣蚕韮?nèi)核豁辉，理論上某一個(gè)容器破壞內(nèi)核搞掉整臺(tái)宿主機(jī)是可以的）。

Docker使用的技術(shù)基礎(chǔ)舀患，都不是什么新東西徽级，但是Docker用go語(yǔ)言將其捏合到了一起，后面我們討論Docker各種效率問(wèn)題的時(shí)候也會(huì)發(fā)現(xiàn)聊浅，其實(shí)我們討論的更多的是Linux本身的特性餐抢，Docker只是將這些特性組合到了一起而已。

使用的核心幾個(gè)技術(shù)都在下面的圖中：

Docker and Kernel (1).png

2.1. 名字空間（namespace）技術(shù)

洪荒時(shí)代（其實(shí)是1979年低匙，也沒(méi)那么久遠(yuǎn)）旷痕，Unix出現(xiàn)了一種技術(shù)，叫做chroot（change root directory）顽冶，可以在UNIX系統(tǒng)上創(chuàng)造一個(gè)封閉的目錄空間欺抗，程序就直接在這個(gè)封閉目錄空間中運(yùn)行而不影響系統(tǒng)整體，是系統(tǒng)環(huán)境隔離的雛形强重。這技術(shù)非常成熟绞呈，我最近一次用還是在chroot空間里面自己編譯LFS系統(tǒng)，但是其沉寂了很久沒(méi)有繼續(xù)發(fā)展间景，也許是沒(méi)有需求就沒(méi)有推動(dòng)動(dòng)力吧佃声。

2002年，從Linux kernel 2.4.19開(kāi)始倘要，linux加入了一個(gè)新的技術(shù)圾亏，叫做名字空間（namespace），這項(xiàng)技術(shù)提供了更豐富的隔離方案封拧，不僅僅能夠進(jìn)行目錄隔離了志鹃，連PID，UID泽西，UTS（host）曹铃，NET，IPC尝苇，MNT都能夠進(jìn)行隔離铛只。下面這個(gè)表格可以看到如今的Linux內(nèi)核都支持那些隔離內(nèi)容，基本上已經(jīng)能夠滿足一般應(yīng)用的隔離需要了糠溜。

更詳細(xì)的內(nèi)容可以參照這個(gè)：Namespaces in operation

2.2. Cgroup（Control Group）

隔離了進(jìn)程的運(yùn)行環(huán)境淳玩，但是各個(gè)進(jìn)程的資源還是共享的，一個(gè)進(jìn)程如果消耗資源太多非竿，別的進(jìn)程就活不下去了蜕着，這是無(wú)法接受的，虛擬機(jī)的資源隔離就做的很好红柱，各個(gè)虛擬機(jī)就按照事先分配好的資源承匣，在其配額內(nèi)運(yùn)行，互不打擾锤悄。

Cgroup的詳細(xì)信息可以參照：Using Control Groups

cgroup的基本原理如下圖韧骗，如果想控制某一個(gè)進(jìn)程，只要建立好cgroup文件零聚，然后將相應(yīng)的進(jìn)程ID放進(jìn)去就可以了袍暴。

作為Docker使用者，只要了解其能夠控制那些內(nèi)容就可以了：

2.3. Docker鏡像（Docker image）存儲(chǔ)技術(shù)

話不多說(shuō)先扔個(gè)圖上來(lái)躲叼，沒(méi)看過(guò)這圖的先盯著這個(gè)圖看上一分鐘：

在Linux世界，提到image這個(gè)詞兒企巢，第一個(gè)反應(yīng)想必是LiveCD枫慷，通過(guò)一張光盤，就可以引導(dǎo)系統(tǒng)浪规，甚至可以在系統(tǒng)上做修改或听，并且這樣的修改不會(huì)反映到LiveCD中，而保存在別的什么地方笋婿，下一次你再啟動(dòng)這個(gè)LiveCD誉裆，之前的修改還會(huì)看到。

神奇嗎缸濒？Docker鏡像/容器存儲(chǔ)的原理和這個(gè)差不多足丢，先創(chuàng)建一個(gè)基礎(chǔ)鏡像層粱腻，然后將其他定制化修改也按照層的形式一層層的疊加，最后就成為了最終的鏡像斩跌，讀取這個(gè)鏡像和平時(shí)Linux mount 一個(gè)普通鏡像沒(méi)有任何分別绍些，特別的是，容器在啟動(dòng)的時(shí)候耀鸦，為了支持寫(xiě)操作柬批，又在上面加了一個(gè)讀寫(xiě)層。所有被修改的文件的內(nèi)容都會(huì)保存在這里袖订。底層的鏡像層就會(huì)被多個(gè)容器所共享氮帐，可供反復(fù)讀取與啟動(dòng)。

因?yàn)闅v史原因洛姑，Docker并沒(méi)有提供統(tǒng)一的存儲(chǔ)方案上沐，而是用插件驅(qū)動(dòng)形式提供了好幾種存儲(chǔ)方案，包括AUFS楞艾，DeviceMapper奄容，OverlayFS，Overlay2等等（還有幾個(gè)醬油方案）产徊，下面挑幾個(gè)主流方案講講昂勒。

1. AUFS（advanced multi-layered unification filesystem）：
要說(shuō)AUFS，我認(rèn)為它不算一個(gè)文件系統(tǒng)舟铜，被稱作一個(gè)多層文件組織方式也許更合適一些戈盈，可以在同一個(gè)文件夾下面進(jìn)行層層疊加，對(duì)于同樣的文件谆刨，選取其中一個(gè)文件呈現(xiàn)在用戶面前塘娶，這實(shí)在是太符合Docker的設(shè)計(jì)理念了，自然而然就成為Docker長(zhǎng)久以來(lái)默認(rèn)的文件系統(tǒng)痊夭。如果你用Ubuntu/Debian刁岸，默認(rèn)就會(huì)用到它，但是Linux Kernel團(tuán)隊(duì)不喜歡它她我，AUFS作者也放棄加入內(nèi)核的努力了虹曙，所以在其他版本，尤其是Redhat系列版本上番舆，都不會(huì)出現(xiàn)它的身影酝碳。

2. DeviceMapper：
這技術(shù)有點(diǎn)兒意思，以前存儲(chǔ)設(shè)備可以掛到各個(gè)文件夾下面使用恨狈，但是各個(gè)設(shè)備資源不能互通疏哗，比如說(shuō)，有兩個(gè)1T硬盤禾怠，但是想存1.5T的內(nèi)容返奉，這事兒以前是沒(méi)得搞的贝搁，你總不能把1.5T的文件中間一刀切開(kāi)然后分別存儲(chǔ)吧，但是DeviceMapper技術(shù)解決了這個(gè)問(wèn)題芽偏，它把兩個(gè)設(shè)備做成一個(gè)虛擬設(shè)備徘公，然后系統(tǒng)訪問(wèn)這個(gè)虛擬設(shè)備就可以了，不用關(guān)心下面存儲(chǔ)調(diào)度的細(xì)節(jié)哮针。更牛逼的是，這個(gè)虛擬設(shè)備可以混合虛擬設(shè)備坦袍，成為了一個(gè)遞歸的結(jié)構(gòu)十厢，其理論上可以無(wú)限擴(kuò)展其存儲(chǔ)。我在Docker里面看到這個(gè)技術(shù)的時(shí)候捂齐，我的第一反應(yīng)是蛮放，這玩意跟Docker鏡像分層技術(shù)有什么關(guān)系？為什么要用這個(gè)技術(shù)來(lái)做一個(gè)實(shí)現(xiàn)奠宜？這就要說(shuō)Linux kernel團(tuán)隊(duì)了包颁，AUFS他們不喜歡，但是他們很喜歡DeviceMapper压真，把它做進(jìn)了Kernel Mainline里面娩嚼，為了保證兼容性和可維護(hù)性，Docker團(tuán)隊(duì)做了一個(gè)折衷滴肿，使用DeviceMapper的Thin Provisioning Snapshot技術(shù)岳悟，來(lái)保證對(duì)于Redhat系列Linux的兼容。原理圖就是下面這個(gè)：

只是為了兼容性硬貼上去的技術(shù)泼差，效率能好到哪里去啊贵少，所以這項(xiàng)技術(shù)在Docker世界里面被黑就是很正常的事情了，不推薦使用堆缘。

3. OverlayFS：
AUFS的層次比較復(fù)雜滔灶，而且兼容性存在問(wèn)題；DeviceMapper倒是血統(tǒng)正了吼肥，但是跟分層技術(shù)風(fēng)馬牛不相及录平，并且IO速度被人黑成了碳。OverLayFS天生就分成了兩層缀皱，一個(gè)Upper層萄涯，還有一個(gè)Lower層，這大大簡(jiǎn)化了層次結(jié)構(gòu)唆鸡，從Linux Kernel 3.18開(kāi)始支持這種格式涝影，所以它也是一個(gè)正統(tǒng)血統(tǒng)的解決方案，兼容性沒(méi)有問(wèn)題争占，性能也不差燃逻，因此推薦使用序目。

幾個(gè)小話題：

• Docker commit 命令是如何實(shí)現(xiàn)的？自然是把讀寫(xiě)層固化伯襟，直接做成鏡像層的一部分了而已猿涨。
• 磁盤IO效率問(wèn)題其實(shí)跟Docker本身關(guān)系不大了，那完全是鏡像文件系統(tǒng)和讀寫(xiě)層驅(qū)動(dòng)來(lái)決定的姆怪，后面也會(huì)提到叛赚。
• Linux發(fā)行版真是多如牛毛，但是萬(wàn)變不離其宗稽揭，基本結(jié)構(gòu)都是 內(nèi)核 + 包管理器 + 周邊運(yùn)行環(huán)境俺附，特別是內(nèi)核，都可以互換溪掀，也就是說(shuō)事镣，用CentOS的內(nèi)核，給加上Debian的deb包揪胃，一樣會(huì)跑的溜的飛起璃哟，DockerHub上的各種發(fā)行版的Docker鏡像，就是基于這種原理做出來(lái)的喊递，而且都可以互換運(yùn)行随闪。

3. Docker的效率

提到虛擬化，第一反應(yīng)肯定是效率問(wèn)題骚勘，Docker真的快嗎蕴掏？我們從幾個(gè)維度來(lái)討論一下Docker容器在性能上的表現(xiàn)如何，以及為什么它會(huì)這樣调鲸。

3.1. CPU效率

通過(guò)上面的討論盛杰，我們知道，Docker并沒(méi)有對(duì)于CPU有任何類似于虛擬機(jī)一樣的虛擬指令化的操作藐石，Docker用的就是實(shí)際的CPU來(lái)進(jìn)行計(jì)算即供，僅僅是用cgroup進(jìn)行了一點(diǎn)兒隔離而已，因此在這個(gè)維度于微，CPU的損耗幾乎可以忽略不計(jì)逗嫡，Docker里面的進(jìn)程和Native的進(jìn)程沒(méi)任何區(qū)別，事實(shí)上各種Performance報(bào)告也證實(shí)了這一觀點(diǎn)株依，IBM那份兒著名的報(bào)告里面驱证，Docker的CPU效率和Navite進(jìn)程的效率相差無(wú)幾。

參考：效率比對(duì)圖

自然的恋腕，Docker也提供了參數(shù)可以限制其CPU資源占用率抹锄，可以按照實(shí)際情況進(jìn)行分配，管理方法和管理Navite進(jìn)程一樣。

3.2. 內(nèi)存效率

內(nèi)存這個(gè)維度的情況和CPU類似伙单，Docker并沒(méi)有任何內(nèi)存頁(yè)虛擬映射等操作获高，都是直接向內(nèi)核申請(qǐng)內(nèi)存并直接進(jìn)行讀寫(xiě)，因此吻育，此處的性能也和Navite進(jìn)程無(wú)異念秧，不再贅述。

參考：效率比對(duì)圖

同樣的布疼，Docker也提供了參數(shù)來(lái)限制每個(gè)容器的內(nèi)存使用量摊趾。

3.3. 存儲(chǔ)效率

關(guān)于存儲(chǔ)話就有點(diǎn)兒長(zhǎng)，這要分幾條來(lái)進(jìn)行討論游两。

1. AUFS：
AUFS不算一個(gè)文件系統(tǒng)砾层，它必須跟后面的設(shè)備讀寫(xiě)驅(qū)動(dòng)一起工作才可以（比如ext4, xfs ）。因此器罐，對(duì)于新文件的讀寫(xiě)，其實(shí)說(shuō)的就是ext4和xfs的性能渐行，這跟普通的Native程序讀寫(xiě)沒(méi)有太大的區(qū)別轰坊。
2. DeviceMapper：
之前說(shuō)過(guò)，這種技術(shù)本質(zhì)上是一種設(shè)備管理方案祟印。他壓根就沒(méi)有分層的概念肴沫，而且默認(rèn)的讀寫(xiě)方式是loop-lvm方式愿卒，IO非常差搞挣，必須更改成Direct-lvm才可以剃毒，有這個(gè)大坑我覺(jué)得這種方案不用也罷元媚，就算是在Redhat系列上也不用它氏豌。
3. OverlayFS：
這個(gè)解決方案是目前平衡性最好的解決方案蜜自。雖然因?yàn)閕node會(huì)被耗盡的bug揽祥，它被黑了很久哪亿，但是卓鹿，無(wú)論從血統(tǒng)上來(lái)講菱魔，還是其本身的技術(shù)特征與Docker的契合度來(lái)講，它是平衡性比較好的解決方案吟孙。建議在生產(chǎn)環(huán)境中使用它澜倦。它的讀寫(xiě)效率也是跟讀寫(xiě)文件系統(tǒng)的驅(qū)動(dòng)有關(guān)，跟它本身沒(méi)有太大的關(guān)系杰妓。
4. Overlay2：
這是下一代的解決方案了藻治，其設(shè)計(jì)理念天然解決了inode消耗的問(wèn)題，但是還處于試驗(yàn)階段巷挥，是將來(lái)解決Docker存儲(chǔ)問(wèn)題的希望桩卵。
5. Volume掛載：
這是容器內(nèi)外映射的一種方式，僅僅調(diào)用了linux標(biāo)準(zhǔn)的 mount 功能，因此讀寫(xiě)效率和Native的mount之后讀寫(xiě)沒(méi)有區(qū)別吸占。
綜上晴叨，在創(chuàng)建新文件，讀寫(xiě)新文件情況下矾屯，AUFS兼蕊，OverlayFS都和Native效率差不多，DeviceMapper必須要管理裸設(shè)備才能讓自己的IO跟上件蚕，DeviceMapper（loop-lvm）的IO效率最差孙技。

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

3.4. 網(wǎng)絡(luò)效率

這也是一個(gè)值得細(xì)細(xì)討論的問(wèn)題排作，也分幾種情況說(shuō)說(shuō)牵啦。
1. HOST模式：
我們?cè)?jīng)說(shuō)過(guò)，Linux內(nèi)核的Namespace技術(shù)可以個(gè)Docker提供一個(gè)獨(dú)立的網(wǎng)絡(luò)棧來(lái)使用妄痪，但是HOST不同哈雏，它直接和宿主機(jī)共享網(wǎng)絡(luò)棧，簡(jiǎn)而言之衫生，你如果打算追求效率的話裳瘪，那就來(lái)用HOST模式吧，沒(méi)有任何效率損失罪针，其共享的程度甚至達(dá)到了連端口都會(huì)沖突彭羹，因此，在帶來(lái)效率的同時(shí)泪酱，還要注意這部分的沖突問(wèn)題派殷。
2. Bridge模式：
Docker在宿主機(jī)虛擬了一個(gè)網(wǎng)卡叫做Docker0，所有和外部的通信都通過(guò)Docker0來(lái)進(jìn)行轉(zhuǎn)發(fā)墓阀，這樣就達(dá)到了內(nèi)部網(wǎng)絡(luò)棧的一個(gè)獨(dú)立性和可訪問(wèn)性毡惜，如下圖：

一個(gè)數(shù)據(jù)包要走出去或者走進(jìn)來(lái)，層次增加了不止一個(gè)斯撮，既有NAT虱黄，又有Iptable，效率不差才怪吮成，事實(shí)也確實(shí)證明了這一點(diǎn)橱乱。如下圖：

和Native相比，響應(yīng)速度損失不止一倍粱甫，比KVM還差泳叠。

3. Overlay網(wǎng)絡(luò)模式：
之前的兩種模式僅僅是在一個(gè)主機(jī)內(nèi)部，但是我們的使用場(chǎng)景通常都是跨主機(jī)的茶宵，服務(wù)之間要通過(guò)跨主機(jī)進(jìn)行通信危纫，這通常的做法是：
?? 1. 上一個(gè)服務(wù)注冊(cè)發(fā)現(xiàn)中心，比如Docker用的consul
?? 2. 每臺(tái)服務(wù)主機(jī)上都加一個(gè)agent，所有跨主機(jī)通信种蝶，都走這個(gè)agent契耿，用UDP進(jìn)行轉(zhuǎn)發(fā)，可以參考下面的圖螃征。

在兩側(cè)都搞NAT搪桂！都要走虛擬網(wǎng)卡！之前已經(jīng)慢了很多了盯滚，這次要慢多少踢械，自己可以計(jì)算一下。當(dāng)然魄藕，這不是說(shuō)Overlay網(wǎng)絡(luò)不能用内列，事實(shí)上生產(chǎn)環(huán)境也用了很多，但是用之前一定要知道要付出什么代價(jià)背率，在代價(jià)與收獲之間做出權(quán)衡话瞧。

3.5. 共享內(nèi)核參數(shù)問(wèn)題

原則上，容器之間共享內(nèi)核寝姿，宿主機(jī)內(nèi)核的參數(shù)調(diào)整自然會(huì)影響在其上運(yùn)行的所有容器交排，但是從Docker 1.12開(kāi)始，這個(gè)情況有了改變会油，為了能夠讓各個(gè)容器能有限的進(jìn)行一些內(nèi)核參數(shù)的調(diào)整个粱，特別是針對(duì)TCP/IP協(xié)議棧（net.*）能夠進(jìn)行參數(shù)調(diào)整古毛，docker run 增加了 sysctl 參數(shù)翻翩，允許用戶能夠修改適用于namespace隔離的內(nèi)核參數(shù)。如下：

但是這畢竟有限稻薇，更多的參數(shù)只能在宿主機(jī)范圍內(nèi)設(shè)定嫂冻，不能在容器里面做定制修改。

4. 使用Docker的幾點(diǎn)建議

講了這么多塞椎，我想關(guān)于Docker應(yīng)該有一點(diǎn)兒大致的印象了吧桨仿。最后再羅嗦幾點(diǎn)。

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

Docker最大的特點(diǎn)就是輕量案狠，啟動(dòng)速度快服傍，擴(kuò)張快，部署快骂铁，因此具體實(shí)現(xiàn)業(yè)務(wù)的服務(wù)吹零，都應(yīng)該放在Docker里面進(jìn)行部署，但是一定要強(qiáng)調(diào)拉庵，并且一定要保證無(wú)狀態(tài)化灿椅，這是快速擴(kuò)張，自主更新的基礎(chǔ)。
無(wú)狀態(tài)化包括：

1. 沒(méi)有Session
?? 2. 磁盤中沒(méi)有任何中間結(jié)果文件
?? 3. 內(nèi)存中沒(méi)有任何處理中間結(jié)果茫蛹，狀態(tài)

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

4.2. 使用服務(wù)名訪問(wèn)其他容器

一個(gè)生產(chǎn)環(huán)境主機(jī)肯定不止一臺(tái)婴洼，服務(wù)肯定也是很多骨坑，因此跨主機(jī)訪問(wèn)容器不可避免，尤其時(shí)下Rancher窃蹋，kubernetes這些都有資源調(diào)度機(jī)制卡啰，能夠?qū)Ω鱾€(gè)服務(wù)的容器進(jìn)行動(dòng)態(tài)遷移，因此使用IP地址直接進(jìn)行訪問(wèn)顯然是不現(xiàn)實(shí)的警没，幸好這種帶有資源調(diào)度的套件都有各自的DNS查詢方式匈辱，可以通過(guò)服務(wù)名直接訪問(wèn)到后面的容器，因此杀迹，將有關(guān)聯(lián)的業(yè)務(wù)服務(wù)都放在一個(gè)網(wǎng)絡(luò)里面去吧，事半功倍树酪，保持最大的靈活性浅碾。

4.3. 針對(duì)某些對(duì)內(nèi)核參數(shù)有要求的服務(wù)，采取獨(dú)立的資源調(diào)度機(jī)制

Docker容器是共享內(nèi)核的续语，而內(nèi)核很多參數(shù)都做不到容器隔離垂谢，因此，如果宿主機(jī)內(nèi)核更改了參數(shù)疮茄，會(huì)對(duì)其上所有容器造成影響滥朱，某些參數(shù)對(duì)某些服務(wù)很有效，對(duì)其他服務(wù)就是副作用力试，針對(duì)這種情況徙邻，推薦采取特化的方式，讓那樣的服務(wù)獨(dú)立部署在特定調(diào)整好內(nèi)核參數(shù)的宿主機(jī)上畸裳。

4.4. 針對(duì)內(nèi)核版本敏感的服務(wù)缰犁，配給特定版本內(nèi)核的服務(wù)器

總會(huì)有這樣的服務(wù)存在，所以在將服務(wù)遷移到Docker之前要仔細(xì)的檢查內(nèi)核兼容性問(wèn)題怖糊，確保服務(wù)能夠正確運(yùn)行帅容，時(shí)刻謹(jǐn)記，內(nèi)核是被共享的伍伤，Docker不是完全隔離的并徘！

4.5. 計(jì)算好每個(gè)容器的性能容量，并規(guī)定上限

虛擬機(jī)時(shí)代嚷缭，不規(guī)劃好資源饮亏，虛擬機(jī)根本無(wú)法啟動(dòng)耍贾，所以這根本不是一個(gè)問(wèn)題，但是到了容器時(shí)代路幸，就算是不規(guī)定上限荐开，Docker也能跑，但是因?yàn)樗械娜萜鞫脊蚕硪粋€(gè)宿主機(jī)的資源简肴，因此容器互相擠占晃听，某些容器無(wú)端占用資源（內(nèi)存泄漏之類），就會(huì)把別的容器擠死砰识。所以能扒，還是事先規(guī)劃好容量吧，至少把資源侵占問(wèn)題能夠控制在一個(gè)容器之內(nèi)辫狼。

4.6. 基礎(chǔ)服務(wù)需要容器化嗎初斑？

這里留了一個(gè)問(wèn)號(hào)，也許你有很大的沖動(dòng)恨不得把所有的服務(wù)膨处，包括nginx见秤，mysql，redis都給容器化了真椿，這些服務(wù)都是有狀態(tài)的鹃答，非常難遷移，做動(dòng)態(tài)擴(kuò)展突硝，并且在網(wǎng)絡(luò)IO上测摔，在磁盤IO上，Docker都有各種各樣的問(wèn)題解恰。所以锋八，對(duì)于這些服務(wù)，一定要謹(jǐn)慎修噪，好好的檢討查库，到底要不要容器化路媚。

4.7. 為了能夠快速擴(kuò)張黄琼，事先在宿主機(jī)上加載基礎(chǔ)鏡像

Docker的快速啟動(dòng)讓人津津樂(lè)道，但是Docker容器在啟動(dòng)的時(shí)候需要先將Docker鏡像拉下來(lái)整慎，然后再啟動(dòng)脏款，如果鏡像比較大，那網(wǎng)絡(luò)傳輸時(shí)間消耗也是不可小視的裤园，因此撤师，預(yù)先為各個(gè)宿主機(jī)先傳輸好鏡像吧，這樣“有備無(wú)患”拧揽，需要的時(shí)候剃盾，容器馬上就能啟動(dòng)并投入工作腺占。

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

這又是一個(gè)問(wèn)號(hào)痒谴，Docker鏡像是分層的衰伯，在Dockerfile里面多寫(xiě)命令，只要這些命令涉及到了修改文件积蔚，那么一條指令就是一層意鲸，層數(shù)多了自然就會(huì)有影響讀寫(xiě)效率的擔(dān)心，但是這個(gè)證據(jù)不足尽爆，Docker團(tuán)隊(duì)也一直無(wú)視這個(gè)問(wèn)題怎顾，所以我只是在這里提一下，盡量用一個(gè)命令去做好鏡像的配置漱贱，減少鏡像層數(shù)槐雾，有備無(wú)患吧。

4.9. 關(guān)于安全

說(shuō)到底幅狮，容器之間是共享內(nèi)核的蚜退，一個(gè)容器如果是惡意容器，那么會(huì)影響整臺(tái)服務(wù)器彪笼，而且在容器內(nèi)部確實(shí)能做得到钻注，比突破虛擬機(jī)然后控制宿主機(jī)容易的多的多得多。將“它是共享內(nèi)核的”時(shí)刻記在腦海里面是非常重要的配猫。
?? 1. 不要使用來(lái)源不明的容器幅恋，盡量使用DockerHub上的官方出品的容器，使用前要對(duì)Dockerfile做Review泵肄。
?? 2. 在容器中不要用root用戶去運(yùn)行你的應(yīng)用捆交，以防意外。
?? 3. Docker可以限定容器的權(quán)限和能力腐巢，具體參照在這里（Docker容器權(quán)限能力）, 去最小化它品追，但是要注意這可能會(huì)引起容器運(yùn)行的不穩(wěn)定。
?? 4. Docker官方推了一個(gè)安全檢查程序冯丙，可以時(shí)不時(shí)的去檢查一下肉瓦。