其實容器的發展歷史早於docker的。docker也不等同於容器，“容器”是壹系列內核特性的統稱。
2000年的時候，LXC容器發布，這是壹種內核虛擬化的技術，可以提供輕量級的虛擬化，以便隔離進程和資源，LXC是docker最初使用的具體內核功能的實現。
2013年的時候，Docker發布，組合LXC、UnionFileSystem和cgroups等Linux技術，創建了容器化標準。而且Docker引入了ship（發布）的概念，構建了壹套build-ship-run的軟件開發流程，讓軟件開發、發布、運行變得更加簡單。
比較內容傳統開發方式容器開發方式構建方式maven打包dockerfile交付方式jar包或者war包容器壹致性弱，開發環境、測試環境、生產環境難以壹致強，不依賴於OS以及運行時環境docker應用了哪些內核技術NameSpace隔離進程運行環境NameSpace是Linux系統內核用來隔離內核資源的壹種方式，通過NameSpace可以讓進程只能看到與自己相關的資源。不同的NameSpace下的進程相互隔離，不能被感知到。NameSpace是對全局系統資源的壹種封裝隔離，使得在不同NameSpace下的進程擁有獨立的全局系統資源，改變壹個NameSpace下的系統資源只會影響這個NameSpace下的進程，對其他NameSpace下的進程無影響。
Linux內核實現NameSpace的壹個主要目的就是想實現輕量級虛擬化服務，同壹個NameSpace下的進程可以感知到彼此的存在，而對外界的進程壹無所知，讓容器以為自身處在壹個獨立的系統中，從而達到隔離的目的。
從dokcer實現者的角度看，可以通過chroot命令切換根目錄的掛載點，使得文件系統隔離。
容器擁有獨立的IP、端口、路由，網絡之間進行了隔離。容器有自己的PID（進程號）和宿主機的PID進行隔離。容器有自己的用戶，用戶組需要隔離。
通過這些全局系統資源的隔離，使得容器中的進程看起來像是擁有了獨立的系統環境。存在壹些LInux命令對進程和NameSpace操作，例如：Clone。創建新進程並且指定他的NameSpace。
cgroup參數限制資源分配的配額？cgroups是Linux內核提供的壹種可以限制壹個進程或者多個進程的所使用資源的機制，可以針對內存、CPU等實現精細化的控制。
cgroups全稱是controlgroups，cgroups為每種可以控制的資源定義了壹個子系統。典型的子系統介紹如下：
cpu子系統，主要限制進程的cpu使用率。
cpuacct子系統，可以統計cgroups中的進程的cpu使用報告。
cpuset子系統，可以為cgroups中的進程分配單獨的cpu節點或者內存節點。
memory子系統，可以限制進程的memory使用量。
blkio子系統，可以限制進程的塊設備io。
devices子系統，可以控制進程能夠訪問某些設備。
net_cls子系統，可以標記cgroups中進程的網絡數據包，然後可以使用tc模塊（trafficcontrol）對數據包進行控制。
freezer子系統，可以掛起或者恢復cgroups中的進程。
ns子系統，可以使不同cgroups下面的進程使用不同的namespace。
這裏面每壹個子系統都需要與內核的其他模塊配合來完成資源的控制。
cgroup的層級結構：
上面這個圖從整體結構上描述了進程與cgroups之間的關系。最下面的P代表壹個進程。每壹個進程的描述符中有壹個指針指向了壹個輔助數據結構css_set（cgroupssubsystemset）。指向某壹個css_set的進程會被加入到當前css_set的進程鏈表中。壹個進程只能隸屬於壹個css_set，壹個css_set可以包含多個進程，隸屬於同壹css_set的進程受到同壹個css_set所關聯的資源限制。
上圖中的”M×NLinkage”說明的是css_set通過輔助數據結構可以與cgroups節點進行多對多的關聯。但是cgroups的實現不允許css_set同時關聯同壹個cgroups層級結構下多個節點。這是因為cgroups對同壹種資源不允許有多個限制配置。
壹個css_set關聯多個cgroups層級結構的節點時，表明需要對當前css_set下的進程進行多種資源的控制。而壹個cgroups節點關聯多個css_set時，表明多個css_set下的進程列表受到同壹份資源的相同限制。
切換進程的根目錄到聯合掛載的rootfs（changeroot）UnionFileSystem，聯合文件系統，將多個不同位置的目錄聯合掛載（unionmount）到同壹個目錄下，Docker利用這種聯合掛載的能力，將容器鏡像裏的多層內容呈現為統壹的rootfs（根文件系統），Rootfs打包了整個操作系統的文件和目錄，是應用運行所需要的最完整的“依賴庫”。
在Docker中使用AUFS(AnotherUnionFileSystem或AdvancedMultilayeredUnificationFileSystem)就是壹種聯合文件系統。AUFS不僅可以對每壹個目錄設定只讀(Readonly)、讀寫(Readwrite)和寫(Witeout-able)權限，同時AUFS也可以支持分層的機制，例如，可以對只讀權限部分邏輯上進行增量地修改而不影響只讀部分。
當Docker在利用鏡像啟動壹個容器時，Docker鏡像將分配文件系統，並且掛載壹個新的可讀寫的層給容器，容器將會在這個文件系統中被創建，並且這個可讀寫的層被添加到鏡像中。Docker目前支持的聯合文件系統種類包括AUFS、Btrfs、VFS和DeviceMapper等。
在Docker中，上層的Image依賴下層的Image，因此Docker中把下層的Image稱作父Image，沒有父Image的Image稱作BaseImage。
因此，想要從壹個Image啟動壹個Container，Docker會先逐次加載其父Image直到BaseImage，用戶的進程運行在Writeable的文件系統層中。
所有父Image中的數據信息以及ID、網絡和LXC管理的資源限制、具體container的配置等，構成壹個Docker概念上的Container。
Docker安全性：Docker容器的安全問題在於是***享內核，因此受到攻擊的時候攻擊面會特別大。
SELinux主要作用就是最大限度地減小系統中服務進程可訪問的資源（最小權限原則）。
在使用了SELinux的操作系統中，決定壹個資源是否能被訪問的因素除了某個資源是否擁有對應用戶的權限（讀、寫、執行）外，還需要判斷每壹類進程是否擁有對某壹類資源的訪問權限。
這樣壹來，即使進程是以root身份運行的，也需要判斷這個進程的類型以及允許訪問的資源類型才能決定是否允許訪問某個資源。進程的活動空間也可以被壓縮到最小。
即使是以root身份運行的服務進程，壹般也只能訪問到它所需要的資源。即使程序出了漏洞，影響範圍也只有在其允許訪問的資源範圍內。安全性大大增加。