base 映象
上一節我們介紹了最小的 Docker 映象，本節討論 base 映象。
base 映象有兩層含義：
- 不依賴其他映象，從 scratch 構建。
- 其他映象可以之為基礎進行擴充套件。
所以，能稱作 base 映象的通常都是各種 Linux 發行版的 Docker 映象，比如 Ubuntu, Debian, CentOS 等。
我們以 CentOS 為例考察 base 映象包含哪些內容。
下載映象：docker pull centos
檢視映象資訊：
映象大小不到 200MB。
等一下！
一個 CentOS 才 200MB ？
平時我們安裝一個 CentOS 至少都有幾個 GB，怎麼可能才 200MB !
相信這是幾乎所有 Docker 初學者都會有的疑問，包括我自己。下面我們來解釋這個問題。
Linux 作業系統由核心空間和使用者空間組成。如下圖所示：
rootfs
核心空間是 kernel，Linux 剛啟動時會載入 bootfs 檔案系統，之後 bootfs 會被解除安裝掉。
使用者空間的檔案系統是 rootfs，包含我們熟悉的 /dev, /proc, /bin 等目錄。
對於 base 映象來說，底層直接用 Host 的 kernel，自己只需要提供 rootfs 就行了。
而對於一個精簡的 OS，rootfs 可以很小，只需要包括最基本的命令、工具和程式庫就可以了。相比其他 Linux 發行版，CentOS 的 rootfs 已經算臃腫的了，alpine 還不到 10MB。
我們平時安裝的 CentOS 除了 rootfs 還會選裝很多軟體、服務、圖形桌面等，需要好幾個 GB 就不足為奇了。
base 映象提供的是最小安裝的 Linux 發行版。
下面是 CentOS 映象的 Dockerfile 的內容：
第二行 ADD 指令新增到映象的 tar 包就是 CentOS 7 的 rootfs。在製作映象時，這個 tar 包會自動解壓到 / 目錄下，生成 /dev, /proc, /bin 等目錄。
注：可在 Docker Hub 的映象描述頁面中檢視 Dockerfile 。
支援執行多種 Linux OS
不同 Linux 發行版的區別主要就是 rootfs。
比如 Ubuntu 14.04 使用 upstart 管理服務，apt 管理軟體包；而 CentOS 7 使用 systemd 和 yum。這些都是使用者空間上的區別，Linux kernel 差別不大。
所以 Docker 可以同時支援多種 Linux 映象，模擬出多種作業系統環境。
上圖 Debian 和 BusyBox（一種嵌入式 Linux）上層提供各自的 rootfs，底層共用 Docker Host 的 kernel。
這裡需要說明的是：
1. base 映象只是在使用者空間與發行版一致，kernel 版本與發行版是不同的。
例如 CentOS 7 使用 3.x.x 的 kernel，如果 Docker Host 是 Ubuntu 16.04（比如我們的實驗環境），那麼在 CentOS 容器中使用的實際是是 Host 4.x.x 的 kernel。
① Host kernel 為 4.4.0-31
② 啟動並進入 CentOS 容器
③ 驗證容器是 CentOS 7
④ 容器的 kernel 版本與 Host 一致
2. 容器只能使用 Host 的 kernel，並且不能修改。
所有容器都共用 host 的 kernel，在容器中沒辦法對 kernel 升級。如果容器對 kernel 版本有要求（比如應用只能在某個 kernel 版本下執行），則不建議用容器，這種場景虛擬機器可能更合適。
映象的分層結構
Docker 支援通過擴充套件現有映象，建立新的映象。
實際上，Docker Hub 中 99% 的映象都是通過在 base 映象中安裝和配置需要的軟體構建出來的。比如我們現在構建一個新的映象，Dockerfile 如下：
① 新映象不再是從 scratch 開始，而是直接在 Debian base 映象上構建。
② 安裝 emacs 編輯器。
③ 安裝 apache2。
④ 容器啟動時執行 bash。
構建過程如下圖所示：
可以看到，新映象是從 base 映象一層一層疊加生成的。每安裝一個軟體，就在現有映象的基礎上增加一層。
問什麼 Docker 映象要採用這種分層結構呢？
最大的一個好處就是 - 共享資源。
比如：有多個映象都從相同的 base 映象構建而來，那麼 Docker Host 只需在磁碟上儲存一份 base 映象；同時記憶體中也只需載入一份 base 映象，就可以為所有容器服務了。而且映象的每一層都可以被共享，我們將在後面更深入地討論這個特性。
這時可能就有人會問了：如果多個容器共享一份基礎映象，當某個容器修改了基礎映象的內容，比如 /etc 下的檔案，這時其他容器的 /etc 是否也會被修改？
答案是不會！
修改會被限制在單個容器內。
這就是我們接下來要學習的容器 Copy-on-Write 特性。
可寫的容器層
當容器啟動時，一個新的可寫層被載入到映象的頂部。
這一層通常被稱作“容器層”，“容器層”之下的都叫“映象層”。
所有對容器的改動 - 無論新增、刪除、還是修改檔案都只會發生在容器層中。
只有容器層是可寫的，容器層下面的所有映象層都是隻讀的。
下面我們深入討論容器層的細節。
映象層數量可能會很多，所有映象層會聯合在一起組成一個統一的檔案系統。如果不同層中有一個相同路徑的檔案，比如 /a，上層的 /a 會覆蓋下層的 /a，也就是說使用者只能訪問到上層中的檔案 /a。在容器層中，使用者看到的是一個疊加之後的檔案系統。
- 新增檔案 在容器中建立檔案時，新檔案被新增到容器層中。
- 讀取檔案 在容器中讀取某個檔案時，Docker 會從上往下依次在各映象層中查詢此檔案。一旦找到，立即將其複製到容器層，然後開啟並讀入記憶體。
- 修改檔案 在容器中修改已存在的檔案時，Docker 會從上往下依次在各映象層中查詢此檔案。一旦找到，立即將其複製到容器層，然後修改之。
- 刪除檔案 在容器中刪除檔案時，Docker 也是從上往下依次在映象層中查詢此檔案。找到後，會在容器層中記錄下此刪除操作。
只有當需要修改時才複製一份資料，這種特性被稱作 Copy-on-Write。可見，容器層儲存的是映象變化的部分，不會對映象本身進行任何修改。
這樣就解釋了我們前面提出的問題：容器層記錄對映象的修改，所有映象層都是隻讀的，不會被容器修改，所以映象可以被多個容器共享。
構建映象
對於 Docker 使用者來說，最好的情況是不需要自己建立映象。幾乎所有常用的資料庫、中介軟體、應用軟體等都有現成的 Docker 官方映象或其他人和組織建立的映象，我們只需要稍作配置就可以直接使用。
使用現成映象的好處除了省去自己做映象的工作量外，更重要的是可以利用前人的經驗。特別是使用那些官方映象，因為 Docker 的工程師知道如何更好的在容器中執行軟體。
當然，某些情況下我們也不得不自己構建映象，比如：
- 找不到現成的映象，比如自己開發的應用程式。
- 需要在映象中加入特定的功能，比如官方映象幾乎都不提供 ssh。
所以本節我們將介紹構建映象的方法。同時分析構建的過程也能夠加深我們對前面映象分層結構的理解。
Docker 提供了兩種構建映象的方法：
- docker commit 命令
- Dockerfile 構建檔案
docker commit
docker commit 命令是建立新映象最直觀的方法，其過程包含三個步驟：
- 執行容器
- 修改容器
- 將容器儲存為新的映象
舉個例子：在 ubuntu base 映象中安裝 vi 並儲存為新映象。
- 第一步， 執行容器
-it 引數的作用是以互動模式進入容器，並開啟終端。412b30588f4a 是容器的內部 ID。
- 安裝 vi
確認 vi 沒有安裝。
安裝 vi。
- 儲存為新映象
在新視窗中檢視當前執行的容器。
silly_goldberg 是 Docker 為我們的容器隨機分配的名字。
執行 docker commit 命令將容器儲存為映象。
新映象命名為 ubuntu-with-vi。
檢視新映象的屬性。
從 size 上看到映象因為安裝了軟體而變大了。
從新映象啟動容器，驗證 vi 已經可以使用。
以上演示瞭如何用 docker commit 建立新映象。然而，Docker 並不建議使用者通過這種方式構建映象。原因如下：
- 這是一種手工建立映象的方式，容易出錯，效率低且可重複性弱。比如要在 debian base 映象中也加入 vi，還得重複前面的所有步驟。
- 更重要的：使用者並不知道映象是如何建立出來的，裡面是否有惡意程式。也就是說無法對映象進行審計，存在安全隱患。
既然 docker commit 不是推薦的方法，我們幹嘛還要花時間學習呢？
原因是：即便是用 Dockerfile（推薦方法）構建映象，底層也 docker commit 一層一層構建新映象的。學習 docker commit 能夠幫助我們更加深入地理解構建過程和映象的分層結構。
Dockerfile 構建映象
Dockerfile 是一個文字檔案，記錄了映象構建的所有步驟。
第一個 Dockerfile
用 Dockerfile 建立上節的 ubuntu-with-vi，其內容則為：
下面我們執行 docker build 命令構建映象並詳細分析每個細節。
① 當前目錄為 /root。
② Dockerfile 準備就緒。
③ 執行 docker build 命令，-t 將新映象命名為 ubuntu-with-vi-dockerfile，命令末尾的 . 指明 build context 為當前目錄。Docker 預設會從 build context 中查詢 Dockerfile 檔案，我們也可以通過 -f 引數指定 Dockerfile 的位置。
④ 從這步開始就是映象真正的構建過程。 首先 Docker 將 build context 中的所有檔案傳送給 Docker daemon。build context 為映象構建提供所需要的檔案或目錄。
Dockerfile 中的 ADD、COPY 等命令可以將 build context 中的檔案新增到映象。此例中，build context 為當前目錄 /root，該目錄下的所有檔案和子目錄都會被髮送給 Docker daemon。
所以，使用 build context 就得小心了，不要將多餘檔案放到 build context，特別不要把 /、/usr 作為 build context，否則構建過程會相當緩慢甚至失敗。
⑤ Step 1：執行 FROM，將 ubuntu 作為 base 映象。
ubuntu 映象 ID 為 f753707788c5。
⑥ Step 2：執行 RUN，安裝 vim，具體步驟為 ⑦、⑧、⑨。
⑦ 啟動 ID 為 9f4d4166f7e3 的臨時容器，在容器中通過 apt-get 安裝 vim。
⑧ 安裝成功後，將容器儲存為映象，其 ID 為 35ca89798937。
這一步底層使用的是類似 docker commit 的命令。
⑨ 刪除臨時容器 9f4d4166f7e3。
⑩ 映象構建成功。
通過 docker images 檢視映象資訊。
映象 ID 為 35ca89798937，與構建時的輸出一致。
在上面的構建過程中，我們要特別注意指令 RUN 的執行過程 ⑦、⑧、⑨。Docker 會在啟動的臨時容器中執行操作，並通過 commit 儲存為新的映象。
檢視映象分層結構
ubuntu-with-vi-dockerfile 是通過在 base 映象的頂部新增一個新的映象層而得到的。
這個新映象層的內容由 RUN apt-get update && apt-get install -y vim 生成。這一點我們可以通過 docker history 命令驗證。
docker history 會顯示映象的構建歷史，也就是 Dockerfile 的執行過程。
ubuntu-with-vi-dockerfile 與 ubuntu 映象相比，確實只是多了頂部的一層 35ca89798937，由 apt-get 命令建立，大小為 97.07MB。docker history 也向我們展示了映象的分層結構，每一層由上至下排列。
注： 表示無法獲取 IMAGE ID，通常從 Docker Hub 下載的映象會有這個問題。
作者：cloudman6