摘要：年月發(fā)布了內(nèi)核對進(jìn)行了重新設(shè)計。年發(fā)布了內(nèi)核更加徹底的改造了，稱為，并且認(rèn)可其已經(jīng)穩(wěn)定。集群工具，多宿主管理運(yùn)行。通過的設(shè)置通過設(shè)置將設(shè)置上標(biāo)簽。使用兩種方式傳遞給宿主其的主機(jī)位置，環(huán)境變量和文件。

https://www.youtube.com/watch?v=heBI7oQvHZU

http://v.qq.com/page/o/8/j/o03134mlm8j.html

Docker 很像(但不是)一個輕量級的虛擬機(jī)，有自己的shell, namespace, network interface，可以以root運(yùn)行東西，有自己的服務(wù)和軟件包

虛擬機(jī)有虛擬硬件層和一個運(yùn)行其上的完整系統(tǒng)。而容器則是直接將進(jìn)程運(yùn)行于現(xiàn)有內(nèi)核上。所以啟動Docker非常輕量級，啟動非?？焖佟?/p>

Docker組成部分，簡單來看，分為三個角色，客戶端、docker 主機(jī)、docker registry。
客戶端運(yùn)行 docker run, build, pull等命令；
docker host 則有一個docker daemon 在運(yùn)行，它維護(hù)著本地的container和image；
docker registry則是集中管理所有image的地方，docker host將從docker registry取得image。

Docker 文件系統(tǒng)是分層的，這是基于Union FS的概念，在Ubuntu上使用的是aufs，可以很自然的支持這種概念。而在CentOS/RHEL上則只能使用DeviceMapper去模擬，性能和穩(wěn)定性以及一些功能會有問題。在 Linux 3.18 以后，可以使用 Overlay FS，這也是 Union FS 的實現(xiàn)。

Docker 文件系統(tǒng)分層，最底層是 bootfs(kernel)，然后是鏡像中的各種層，最后是運(yùn)行期的容器的層。容器的存儲層在容器停止后，即被廢棄。

嚴(yán)格來說并不是在容器停止后就被銷毀。容器停止后，其存儲層依然附屬于停止掉的容器。如果利用 docker start 將容器啟動后，會發(fā)現(xiàn)其內(nèi)文件系統(tǒng)的變動依然存在。而這種容器存儲層被廢棄的概念則是指另一個層面的事情。

容器應(yīng)當(dāng)被視為 immutable 的，因此容器內(nèi)部的變動應(yīng)該可以隨時被拋棄，不希望丟失的變化部分應(yīng)該存儲于掛載的數(shù)據(jù)卷中。

所以docker的工作流是 docker run, stop, rm, 再次run。每一次run都是從image建立的新鮮的container，所以里面的內(nèi)容永遠(yuǎn)是image的狀態(tài)，而沒有上一次container中的修改。所以從這個工作流程理解，container中的變動被廢棄了。

Docker 1.10 發(fā)布更新了Layer的ID問題，曾經(jīng)使用的是隨機(jī)UUID，但是發(fā)生過沖突，而且很難判斷相同UUID的layer到底是哪個。所以從1.10開始，將其升級為密碼學(xué) Hash 值，SHA256。這樣可以確保其內(nèi)容統(tǒng)一，而且Image將會更小。在 1.10 以前，Image 和 Layer 基本是一個完整的東西，但是 1.10 之后，由于使用了 SHA256，Image 和 Layer 可以分開復(fù)用重復(fù)的Layer，這樣Image可以更小。由于這種變化，如果從 1.10 以前的版本過來，必須要升級所有 images。

Docker 容器文件層會在停止后被廢棄，那么數(shù)據(jù)應(yīng)該存儲于掛載的卷中。而掛載卷可以是數(shù)據(jù)卷也可以是本地文件，注意是“本地”，不可以使用NFS, SMB之類的位置進(jìn)行掛載，這樣Docker會認(rèn)為其不安全。如果需要類似的云存儲，可以使用volume的driver，可以支持AWS S3之類的存儲。

docker run 一個容器，容器可以定義 EXPOSE 某些端口，而這些端口是容器之間可以訪問的，而不是從外部訪問，如果需要這些端口暴露于外部，那么應(yīng)該用 -p 或 --publish，將該端口發(fā)布于宿主，可以映射不同端口。

Dockerfile 是分步驟的，而每一步都會被緩存，所以重新構(gòu)建非?？臁?/p>

ENTRYPOINT 和 CMD 不同，一般 ENTRYPOINT 是要運(yùn)行的命令，而 CMD 則是參數(shù)，docker run 后面所跟隨的實際上是 CMD，也就是參數(shù)。有些鏡像把 ENTRYPOINT 設(shè)為了 sh -c，這樣 CMD 可以跟 bash 命令和腳本，所以一些人誤以為 CMD 就是命令。其實它們只是作為參數(shù)送給了 ENTRYPOINT 中指定的 sh -c。

基本命令：build, run, stop, start, ps, ps -a, images, rmi
將鏡像push到registry，docker login, docker push

Docker 的歷史是和 Linux 內(nèi)核發(fā)布?xì)v史緊密相關(guān)的。

有個特性被添加進(jìn)來，Control Groups(cgroups)。隨后，使用 cgroups 的 Linux Containers (lxc) 發(fā)布。cgroups 是今天 Docker 的基礎(chǔ)。

cgroups ，可以限制資源使用，設(shè)置優(yōu)先級，會計，控制。

距演講者說，Linux 中的 nice，實際上就是使用 cgroups 中優(yōu)先級的功能。
https://en.wikipedia.org/wiki/Nice_(Unix)
不過應(yīng)該不是。

控制的部分包括freeze和restart。

(這部分的內(nèi)容演講者講的有些錯誤，我查詢了一下，進(jìn)行修正。）

http://kernelnewbies.org/Linux_3.8#head-fc2604c967c200a26f336942caee2440a2a4099c

這次完整的實現(xiàn)了 namespace 的隔離，包括了 pid, network, hostname, mount pic, user 的namespace。

正是這次發(fā)布構(gòu)成了Docker的基礎(chǔ)，同年3月份 Docker 項目正式成為開源項目。最開始基于 lxc，現(xiàn)在抽象出來了 libcontainer，統(tǒng)一接口，下面可以支持多種容器組合，默認(rèn)使用的是 runC，不過可以換。

對 cgroups 進(jìn)行了重新設(shè)計。 http://lwn.net/Articles/601840/

Docker Networking 中的 overlay network 所依賴的就是這次內(nèi)核的改進(jìn)。

經(jīng)過多年的努力，這次終于第一次在內(nèi)核中加入了 Union FS的實現(xiàn)，這次是 Overlay fs。（Ubuntu中的aufs爭取了好多年，最后作者懶得爭取了，放棄了）。這樣對于紅帽系將來的服務(wù)器，也就終于有可能有Union FS可用了。以前只能湊合用 Device Mapper，而且本地loop還是不適合在生產(chǎn)環(huán)境使用的。所以要使用 overlay 存儲層，需要內(nèi)核在 3.18 以上。

docker 1.12 中的 overlay2 存儲層就依賴的是這次的內(nèi)核對 overlay 驅(qū)動的改進(jìn)。

更加徹底的改造了 cgroups，稱為 cgroups2，并且認(rèn)可其已經(jīng)穩(wěn)定。
http://kernelnewbies.org/Linux_4.5#head-621383bcd8bc104aed825c9ebc08a0b986690f8a

非常容易擴(kuò)展，由于所有東西都打包在一個容器里了，所以部署的時候不需要在服務(wù)器上進(jìn)行安裝了，所以很適合擴(kuò)展。

Docker 容器是 immutable 的，可以將其視為樂高積木，如果哪個壞了，扔了換個新的，而不是在舊的上面修修補(bǔ)補(bǔ)。

DevOps，開發(fā)人員(Dev)只需要考慮容器內(nèi)的東西即可，而運(yùn)營人員(Ops)則只需負(fù)責(zé)容器外部即可。

確保所有環(huán)境完全一樣，不會出現(xiàn)“我的機(jī)器上沒問題啊”這種情況。運(yùn)行、測試都在容器內(nèi)。

Compose, Machine, Swarm, Networking

定義運(yùn)行多容器應(yīng)用，單機(jī)沒問題，多主機(jī)還在試驗中。

實例中，值得注意的是，他的目錄結(jié)構(gòu)。docker-compose.yml 在項目根目錄，每個應(yīng)用都有自己獨(dú)立目錄，以及其目錄下存在 Dockerfile。這種感覺更干凈。（或許在LNMP示例項目中，我不應(yīng)該把conf都存在于同一個目錄下，而是應(yīng)該分應(yīng)用建立目錄，對應(yīng)的配置放在各自目錄下。）

另外需要注意的是，在僅有幾臺的應(yīng)用環(huán)境下，他依然定義了前端網(wǎng)絡(luò)和后端網(wǎng)絡(luò)，讓兩個網(wǎng)絡(luò)獨(dú)立。

在啟動示例的過程中，Tom Vereist 提到了這個例子寫的不好的一點(diǎn)，在 worker 項目中，它在容器里使用 maven 對項目進(jìn)行了構(gòu)建。這不是一個好的寫法，這會導(dǎo)致maven的安裝，編譯開發(fā)工具的安裝、依賴的安裝等等，會產(chǎn)生一個非常大的鏡像。建議的做法是可以在另一個容器中構(gòu)建，把構(gòu)建后的軟件包拿到運(yùn)行的容器中安裝使用即可，避免運(yùn)行時不需要的東西存在于容器中。

用于創(chuàng)建、管理 docker host，可以支持多種云平臺，提供統(tǒng)一的訪問接口。

docker 集群工具，多宿主管理運(yùn)行。

可以定義 docker host 的 label。通過 docker daemon 的 --label 設(shè)置；通過 docker-machine --engine-label, --label 設(shè)置；將 docker host 設(shè)置上標(biāo)簽。然后在運(yùn)行的時候可以通過約束標(biāo)簽，來決定該容器運(yùn)行于那些 docker host 上。

可以定義過濾器，包括兩大類，節(jié)點(diǎn)(Node)或容器(Container)。節(jié)點(diǎn)可能是約束、健康程度等；容器可以是端口、依賴等。

創(chuàng)建 Overlay network。替代 link (bridge)，link 在一些動態(tài)環(huán)境下使用會有問題。比如一群容器啟動后，link的某一個節(jié)點(diǎn)掛了，重新運(yùn)行，使用了新的ip，而還在運(yùn)行的docker使用的還是舊的ip去聯(lián)系該節(jié)點(diǎn)，導(dǎo)致無法連接。所以只能夠把所有節(jié)點(diǎn)都down掉，然后重新運(yùn)行。

嘗試了一下，兩個沒有link關(guān)系的容器，可以通過容器IP訪問對方。所以 link 是建立一種識別的辦法，而不是安全上的建立通道的概念。看了一下文檔，提到了 --icc=false 的參數(shù)來創(chuàng)建網(wǎng)絡(luò)隔離。
https://docs.docker.com/engine/userguide/networking/work-with-networks/#linking-containers-in-user-defined-networks

link (bridge)使用兩種方式傳遞給宿主其link的主機(jī)位置，環(huán)境變量和/etc/hosts文件。
https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/#communication-across-links

而多宿主環(huán)境中，使用 docker network 創(chuàng)建 overlay network，使用link鏈接主機(jī)，則會有一個內(nèi)置的DNS進(jìn)行名字的動態(tài)維護(hù)，不再使用 /etc/hosts。

在Tom 演示 docker swarm 的時候，我發(fā)現(xiàn)他和我一樣建立了一個 bash 腳本來啟動建立 docker host。我覺得應(yīng)該考慮做個工具使用 yaml 描述文件來建立 docker-machine，就像 docker-compose做的那樣。命令行中有太多的重復(fù)信息了。

腳本最后是使用 docker network 創(chuàng)建 overlay 網(wǎng)絡(luò)，Tom 提到一點(diǎn)，需要指定 --subnet ，否則將無法連通，特別是跨主機(jī)的時候，有的版本有bug，同一個網(wǎng)絡(luò)不一定使用同一段IP地址。不過現(xiàn)在這個bug已經(jīng)修復(fù)了，不指定地址跨主機(jī)沒問題。

演示 swarm 的過程中碰到了和我碰到的一樣的問題。在單機(jī)環(huán)境中，在 docker compose 中可以使用 build 來構(gòu)建鏡像。但是在 swarm 的多宿主環(huán)境中，這樣做的結(jié)果會導(dǎo)致所有的 service 會扔到同一個 docker host 中去，而如果打算使用多宿主環(huán)境（也是為什么要用swarm 的初衷），則必須使用 registry 中的 image。這樣宿主可以主動去 registry 下載 image?？梢允褂?docker hub 的服務(wù)，或者自己架設(shè) registry。

并且不可以使用 link 了，而必須使用 自定義network。Tom 說這是由于一個 link 的bug，現(xiàn)在不知道是否已經(jīng)解決了，需要試驗。

通過 environment:"constraint:type==frontend" 的形式來指定約束。

Tom 不推薦在生產(chǎn)環(huán)境中使用 compose + swarm，因為碰到了太多的問題，他甚至自己還報告了一個bug #2866。

創(chuàng)建 node clusters，可以選擇AWS, Digital Ocean, Azure，Softlayer等幾大云服務(wù)商。然后可以使用docker hub上的鏡像進(jìn)行部署。建立 Stack 需要腳本，很像compose，其實他們應(yīng)該支持compose腳本更合適，建立service。

Docker Cloud 適合小規(guī)模云的部署。

由 Google 開發(fā)，用 Go 語言寫的。Google 每周用這個運(yùn)行2百萬個containers。

一個 kubernetes 集群由 master 和 minions 組成。master 含有 etcd、scheduler；而每個 minon 含有 kubelet，proxy 和一群 pod。

不需要安裝 docker，它包含了 linux container。它也使用 etcd，所不同的是它每一個 host都運(yùn)行etcd，這樣避免了單點(diǎn)故障。fleetd，很像是網(wǎng)絡(luò)多宿主環(huán)境下的 systemd，它負(fù)責(zé)開啟停止分布在宿主中的服務(wù)。

container 本身很安全，由于 isolation，只使用必要的依賴。
可以使用 --security-opt sec comp:xxx.json，來指定安全策略。
Unikernel，可以非常靈活定制的內(nèi)核，只選擇所必須的組件使用，其它的都拋棄，信任域更小。

現(xiàn)在 docker daemon 必須以 root 運(yùn)行?，F(xiàn)在的授權(quán)機(jī)制是 all or nothing，或者可以管理所有 docker，或者完全沒有權(quán)限管理。這點(diǎn)將來可能會改變。