Docker 是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的鏡像中，然后發布到任何流行的 Linux或Windows 機器上，也可以實現虛擬化。容器是完全使用沙箱機制，相互之間不會有任何接口。
Docker 是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然后發布到任何流行的Linux機器上，也可以實現虛擬化，容器是完全使用沙箱機制，相互之間不會有任何接口。
一個完整的Docker有以下幾個部分組成：
1.DockerClient客戶端
2.Docker Daemon守護進程
3.Docker Image鏡像
4.DockerContainer容器
Docker 起源
Docker 是 PaaS 提供商 dotCloud 開源的一個基于 LXC 的高級容器引擎，源代碼托管在 Github 上, 基于go語言并遵從Apache2.0協議開源。
Docker自2013年以來非常火熱，無論是從 github 上的代碼活躍度，還是Redhat在RHEL6.5中集成對Docker的支持, 就連 Google 的 Compute Engine 也支持 docker 在其之上運行。
一款開源軟件能否在商業上成功，很大程度上依賴三件事 - 成功的 user case(用例), 活躍的社區和一個好故事。 dotCloud 自家的 PaaS 產品建立在docker之上，長期維護且有大量的用戶，社區也十分活躍，接下來我們看看docker的故事。
• 環境管理復雜 - 從各種OS到各種中間件到各種app, 一款產品能夠成功作為開發者需要關心的東西太多，且難于管理，這個問題幾乎在所有現代IT相關行業都需要面對。
• 云計算時代的到來 - AWS的成功, 引導開發者將應用轉移到 cloud 上, 解決了硬件管理的問題，然而中間件相關的問題依然存在 (所以openstack HEAT和 AWS cloudformation 都著力解決這個問題)。開發者思路變化提供了可能性。
• 虛擬化手段的變化 - cloud 時代采用標配硬件來降低成本，采用虛擬化手段來滿足用戶按需使用的需求以及保證可用性和隔離性。然而無論是KVM還是Xen在 docker 看來，都在浪費資源，因為用戶需要的是高效運行環境而非OS, GuestOS既浪費資源又難于管理, 更加輕量級的LXC更加靈活和快速
• LXC的移動性 - LXC在 linux 2.6 的 kernel 里就已經存在了，但是其設計之初并非為云計算考慮的，缺少標準化的描述手段和容器的可遷移性，決定其構建出的環境難于遷移和標準化管理(相對于KVM之類image和snapshot的概念)。docker 就在這個問題上做出實質性的革新。這是docker最獨特的地方。
面對上述幾個問題，docker設想是交付運行環境如同海運，OS如同一個貨輪，每一個在OS基礎上的軟件都如同一個集裝箱，用戶可以通過標準化手段自由組裝運行環境，同時集裝箱的內容可以由用戶自定義，也可以由專業人員制造。這樣，交付一個軟件，就是一系列標準化組件的集合的交付，如同樂高積木，用戶只需要選擇合適的積木組合，并且在最頂端署上自己的名字(最后一個標準化組件是用戶的app)。這也就是基于docker的PaaS產品的原型。
Docker 架構
Docker 使用客戶端-服務器 (C/S) 架構模式，使用遠程API來管理和創建Docker容器。Docker 容器通過 Docker 鏡像來創建。容器與鏡像的關系類似于面向對象編程中的對象與類。
|
Docker |
面向對象 |
|
容器 |
對象 |
|
鏡像 |
類 |
Docker采用 C/S架構 Docker daemon 作為服務端接受來自客戶的請求，并處理這些請求（創建、運行、分發容器）。客戶端和服務端既可以運行在一個機器上，也可通過 socket 或者RESTful API 來進行通信。
Docker daemon 一般在宿主主機后臺運行，等待接收來自客戶端的消息。 Docker 客戶端則為用戶提供一系列可執行命令，用戶用這些命令實現跟 Docker daemon 交互。
Docker 特性
在docker的網站上提到了docker的典型場景：
• Automating the packaging and deployment of applications（使應用的打包與部署自動化）
• Creation of lightweight, private PAAS environments（創建輕量、私密的PAAS環境）
• Automated testing and continuous integration/deployment（實現自動化測試和持續的集成/部署）
• Deploying and scaling web apps, databases and backend services（部署與擴展webapp、數據庫和后臺服務）
由于其基于LXC的輕量級虛擬化的特點，docker相比KVM之類最明顯的特點就是啟動快，資源占用小。因此對于構建隔離的標準化的運行環境，輕量級的PaaS(如dokku), 構建自動化測試和持續集成環境，以及一切可以橫向擴展的應用(尤其是需要快速啟停來應對峰谷的web應用)。
1.構建標準化的運行環境，現有的方案大多是在一個baseOS上運行一套puppet/chef，或者一個image文件，其缺點是前者需要base OS許多前提條件，后者幾乎不可以修改(因為copy on write 的文件格式在運行時rootfs是read only的)。并且后者文件體積大，環境管理和版本控制本身也是一個問題。
2.PaaS環境是不言而喻的，其設計之初和dotcloud的案例都是將其作為PaaS產品的環境基礎
3.因為其標準化構建方法(buildfile)和良好的REST API，自動化測試和持續集成/部署能夠很好的集成進來
4.因為LXC輕量級的特點，其啟動快，而且docker能夠只加載每個container變化的部分，這樣資源占用小，能夠在單機環境下與KVM之類的虛擬化方案相比能夠更加快速和占用更少資源
Docker 局限
Docker并不是全能的，設計之初也不是KVM之類虛擬化手段的替代品，簡單總結幾點：
1.Docker是基于Linux 64bit的，無法在32bit的linux/Windows/unix環境下使用
2.LXC是基于cgroup等linux kernel功能的，因此container的guest系統只能是linux base的
3.隔離性相比KVM之類的虛擬化方案還是有些欠缺，所有container公用一部分的運行庫
4.網絡管理相對簡單，主要是基于namespace隔離
5.cgroup的cpu和cpuset提供的cpu功能相比KVM的等虛擬化方案相比難以度量(所以dotcloud主要是按內存收費)
6.Docker對disk的管理比較有限
7.container隨著用戶進程的停止而銷毀，container中的log等用戶數據不便收集
針對1-2，有windows base應用的需求的基本可以pass了; 3-5主要是看用戶的需求，到底是需要一個container還是一個VM, 同時也決定了docker作為 IaaS 不太可行。
針對6,7雖然是docker本身不支持的功能，但是可以通過其他手段解決(disk quota, mount --bind)。總之，選用container還是vm, 就是在隔離性和資源復用性上做權衡。
另外即便docker 0.7能夠支持非AUFS的文件系統，但是由于其功能還不穩定，商業應用或許會存在問題，而AUFS的穩定版需要kernel 3.8, 所以如果想復制dotcloud的成功案例，可能需要考慮升級kernel或者換用ubuntu的server版本(后者提供deb更新)。這也是為什么開源界更傾向于支持ubuntu的原因(kernel版本)
Docker并非適合所有應用場景，Docker只能虛擬基于Linux的服務。Windows Azure 服務能夠運行Docker實例，但到為止Windows服務還不能被虛擬化。
可能最大的障礙在于管理實例之間的交互。由于所有應用組件被拆分到不同的容器中，所有的服務器需要以一致的方式彼此通信。這意味著任何人如果選擇復雜的基礎設施，那么必須掌握應用編程接口管理以及集群工具，比如Swarm、Mesos或者Kubernets以確保機器按照預期運轉并支持故障切換。
Docker在本質上是一個附加系統。使用文件系統的不同層構建一個應用是有可能的。每個組件被添加到之前已經創建的組件之上，可以比作為一個文件系統更明智。分層架構帶來另一方面的效率提升，當你重建存在變化的Docker鏡像時，不需要重建整個Docker鏡像，只需要重建變化的部分。
可能更為重要的是，Docker旨在用于彈性計算。每個Docker實例的運營生命周期有限，實例數量根據需求增減。在一個管理適度的系統中，這些實例生而平等，不再需要時便各自消亡了。
針對Docker環境存在的不足，意味著在開始部署Docker前需要考慮如下幾個問題。首先，Docker實例是無狀態的。這意味著它們不應該承載任何交易數據，所有數據應該保存在數據庫服務器中。
其次，開發Docker實例并不像創建一臺虛擬機、添加應用然后克隆那樣簡單。為成功創建并使用Docker基礎設施，管理員需要對系統管理的各個方面有一個全面的理解，包括Linux管理、編排及配置工具比如Puppet、Chef以及Salt。這些工具生來就基于命令行以及腳本。
Docker 原理
Docker核心解決的問題是利用LXC來實現類似VM的功能，從而利用更加節省的硬件資源提供給用戶更多的計算資源。同VM的方式不同, LXC 其并不是一套硬件虛擬化方法 - 無法歸屬到全虛擬化、部分虛擬化和半虛擬化中的任意一個，而是一個操作系統級虛擬化方法, 理解起來可能并不像VM那樣直觀。所以我們從虛擬化到docker要解決的問題出發，看看他是怎么滿足用戶虛擬化需求的。
用戶需要考慮虛擬化方法，尤其是硬件虛擬化方法，需要借助其解決的主要是以下4個問題:
• 隔離性 - 每個用戶實例之間相互隔離, 互不影響。硬件虛擬化方法給出的方法是VM, LXC給出的方法是container，更細一點是kernel namespace
• 可配額/可度量 - 每個用戶實例可以按需提供其計算資源，所使用的資源可以被計量。硬件虛擬化方法因為虛擬了CPU, memory可以方便實現, LXC則主要是利用cgroups來控制資源
• 移動性 - 用戶的實例可以很方便地復制、移動和重建。硬件虛擬化方法提供snapshot和image來實現，docker(主要)利用AUFS實現
• 安全性 - 這個話題比較大，這里強調是host主機的角度盡量保護container。硬件虛擬化的方法因為虛擬化的水平比較高，用戶進程都是在KVM等虛擬機容器中翻譯運行的, 然而對于LXC, 用戶的進程是lxc-start進程的子進程, 只是在Kernel的namespace中隔離的, 因此需要一些kernel的patch來保證用戶的運行環境不會受到來自host主機的惡意入侵, dotcloud(主要是)利用kernel grsec patch解決的.
Linux Namespace
LXC所實現的隔離性主要是來自kernel的namespace, 其中pid, net, ipc, mnt, uts 等namespace將container的進程, 網絡, 消息, 文件系統和hostname 隔離開。
pid namespace
之前提到用戶的進程是lxc-start進程的子進程, 不同用戶的進程就是通過pidnamespace隔離開的，且不同 namespace 中可以有相同PID。具有以下特征:
1.每個namespace中的pid是有自己的pid=1的進程(類似/sbin/init進程)
2.每個namespace中的進程只能影響自己的同一個namespace或子namespace中的進程
3.因為/proc包含正在運行的進程，因此在container中的pseudo-filesystem的/proc目錄只能看到自己namespace中的進程
4.因為namespace允許嵌套，父namespace可以影響子namespace的進程，所以子namespace的進程可以在父namespace中看到，但是具有不同的pid
正是因為以上的特征，所有的LXC進程在docker中的父進程為docker進程，每個lxc進程具有不同的namespace。同時由于允許嵌套，因此可以很方便的實現 LXC in LXC
net namespace
有了 pid namespace, 每個namespace中的pid能夠相互隔離，但是網絡端口還是共享host的端口。網絡隔離是通過netnamespace實現的，
每個net namespace有獨立的 network devices, IP addresses, IP routing tables, /proc/net 目錄。這樣每個container的網絡就能隔離開來。
LXC在此基礎上有5種網絡類型，docker默認采用veth的方式將container中的虛擬網卡同host上的一個docker bridge連接在一起。
ipc namespace
container中進程交互還是采用linux常見的進程間交互方法(interprocess communication - IPC), 包括常見的信號量、消息隊列和共享內存。然而同VM不同，container 的進程間交互實際上還是host上具有相同pid namespace中的進程間交互，因此需要在IPC資源申請時加入namespace信息 - 每個IPC資源有一個的 32bit ID。
mnt namespace
類似chroot，將一個進程放到一個特定的目錄執行。mnt namespace允許不同namespace的進程看到的文件結構不同，這樣每個 namespace 中的進程所看到的文件目錄就被隔離開了。同chroot不同，每個namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。
uts namespace
UTS(“UNIX Time-sharing System”) namespace允許每個container擁有獨立的hostname和domain name,
使其在網絡上可以被視作一個獨立的節點而非Host上的一個進程。
usernamespace
每個container可以有不同的 user 和 group id, 也就是說可以以container內部的用戶在container內部執行程序而非Host上的用戶。
有了以上6種namespace從進程、網絡、IPC、文件系統、UTS和用戶角度的隔離，一個container就可以對外展現出一個獨立計算機的能力，并且不同container從OS層面實現了隔離。
然而不同namespace之間資源還是相互競爭的，仍然需要類似ulimit來管理每個container所能使用的資源 - LXC 采用的是cgroup。
Control Groups
cgroups 實現了對資源的配額和度量。 cgroups 的使用非常簡單，提供類似文件的接口，在 /cgroup目錄下新建一個文件夾即可新建一個group，在此文件夾中新建task文件，并將pid寫入該文件，即可實現對該進程的資源控制。具體的資源配置選項可以在該文件夾中新建子 subsystem ，{子系統前綴}.{資源項} 是典型的配置方法，
如memory.usage_in_bytes 就定義了該group 在subsystem memory中的一個內存限制選項。
另外，cgroups中的 subsystem可以隨意組合，一個subsystem可以在不同的group中，也可以一個group包含多個subsystem - 也就是說一個 subsystem。
關于術語定義
A *cgroup* associates a set of tasks with a set of parameters for one
or more subsystems.
A *subsystem* is a module that makes use of the task grouping
facilities provided by cgroups to treat groups of tasks in
particular ways. A subsystem is typically a "resource controller" that
schedules a resource or applies per-cgroup limits, but it may be
anything that wants to act on a group of processes, e.g. a
virtualization subsystem.
我們主要關心cgroups可以限制哪些資源，即有哪些subsystem是我們關心。
cpu: 在cgroup中，并不能像硬件虛擬化方案一樣能夠定義CPU能力，但是能夠定義CPU輪轉的優先級，因此具有較高CPU優先級的進程會更可能得到CPU運算。
通過將參數寫入cpu.shares,即可定義改cgroup的CPU優先級 - 這里是一個相對權重，而非絕對值。當然在cpu這個subsystem中還有其他可配置項，手冊中有詳細說明。
cpusets : cpusets 定義了有幾個CPU可以被這個group使用，或者哪幾個CPU可以供這個group使用。在某些場景下，單CPU綁定可以防止多核間緩存切換，從而提高效率
memory : 內存相關的限制
blkio : block IO相關的統計和限制，byte/operation統計和限制(IOPS等)，讀寫速度限制等，但是這里主要統計的都是同步IO
net_cls，cpuacct ,devices ,freezer 等其他可管理項。
Linux 容器
借助于namespace的隔離機制和cgroup限額功能，LXC提供了一套統一的API和工具來建立和管理container, LXC利用了如下 kernel 的features:
• Kernel namespaces (ipc, uts, mount, pid, network and user)
• Apparmor and SELinux profiles
• Seccomp policies
• Chroots (using pivot_root)
• Kernel capabilities
• Control groups (cgroups)
LXC 向用戶屏蔽了以上 kernel 接口的細節, 提供了如下的組件大大簡化了用戶的開發和使用工作:
• The liblxc library
• Several language bindings (python3, lua and Go)
• A set of standard tools to control the containers
• Container templates
LXC 旨在提供一個共享kernel的 OS 級虛擬化方法，在執行時不用重復加載Kernel, 且container的kernel與host共享，因此可以大大加快container的 啟動過程，并顯著減少內存消耗。在實際測試中，基于LXC的虛擬化方法的IO和CPU性能幾乎接近 baremetal 的性能, 大多數數據有相比 Xen具有優勢。當然對于KVM這種也是通過Kernel進行隔離的方式, 性能優勢或許不是那么明顯, 主要還是內存消耗和啟動時間上的差異。在參考文獻中提到了利用iozone進行 Disk IO吞吐量測試KVM反而比LXC要快，而且筆者在device mapping driver下重現同樣case的實驗中也確實能得到如此結論。參考文獻從網絡虛擬化中虛擬路由的場景(網絡IO和CPU角度)比較了KVM和LXC, 得到結論是KVM在性能和隔離性的平衡上比LXC更優秀 - KVM在吞吐量上略差于LXC, 但CPU的隔離可管理項比LXC更明確。
關于CPU, DiskIO, network IO 和 memory 在KVM和LXC中的比較還是需要更多的實驗才能得出可信服的結論。
AUFS
Docker對container的使用基本是建立在LXC基礎之上的，然而LXC存在的問題是難以移動 - 難以通過標準化的模板制作、重建、復制和移動 container。
在以VM為基礎的虛擬化手段中，有image和snapshot可以用于VM的復制、重建以及移動的功能。想要通過container來實現快速的大規模部署和更新, 這些功能不可或缺。
Docker 正是利用AUFS來實現對container的快速更新 - 在docker0.7中引入了storage driver, 支持AUFS, VFS, device mapper, 也為BTRFS以及ZFS引入提供了可能。但除了AUFS都未經過dotcloud的線上使用，因此我們還是從AUFS的角度介紹。
AUFS (AnotherUnionFS) 是一種 Union FS, 簡單來說就是支持將不同目錄掛載到同一個虛擬文件系統下(unite several directories into a single virtual filesystem)的文件系統, 更進一步地, AUFS支持為每一個成員目錄(AKA branch)設定'readonly', 'readwrite' 和 'whiteout-able' 權限, 同時AUFS里有一個類似
分層的概念, 對 readonly 權限的branch可以邏輯上進行修改(增量地, 不影響readonly部分的)。通常 Union FS有兩個用途, 一方面可以實現不借助 LVM， RAID 將多個disk和掛在到一個目錄下, 另一個更常用的就是將一個readonly的branch和一個writeable的branch聯合在一起，Live CD正是基于此可以允許在 OS image 不變的基礎上允許用戶在其上進行一些寫操作。Docker在AUFS上構建的container image也正是如此，接下來我們從啟動container中的linux為例介紹docker在AUFS特性的運用。
典型的Linux啟動到運行需要兩個FS - bootfs + rootfs (從功能角度而非文件系統角度)（圖1）
bootfs (boot file system) 主要包含 bootloader 和 kernel,bootloader主要是引導加載kernel, 當boot成功后 kernel 被加載到內存中后 bootfs就被umount了.
rootfs (root file system) 包含的就是典型 Linux 系統中的 /dev, /proc, /bin, /etc 等標準目錄和文件。
