每天5分鐘玩轉Docker容器技術（三）

每天5分鐘玩轉Docker容器技術（一）

每天5分鐘玩轉Docker容器技術（二）

base 鏡像

上一節我們介紹了最小的 Docker 鏡像，本節討論 base 鏡像。

base 鏡像有兩層含義：

1. 不依賴其他鏡像，從 scratch 構建。
2. 其他鏡像可以之為基礎進行擴展。

所以，能稱作 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。在容器層中，用戶看到的是一個疊加之後的文件系統。

1. 添加文件 在容器中創建文件時，新文件被添加到容器層中。
2. 讀取文件 在容器中讀取某個文件時，Docker 會從上往下依次在各鏡像層中查找此文件。一旦找到，立即將其複製到容器層，然後打開並讀入內存。
3. 修改文件 在容器中修改已存在的文件時，Docker 會從上往下依次在各鏡像層中查找此文件。一旦找到，立即將其複製到容器層，然後修改之。
4. 刪除文件 在容器中刪除文件時，Docker 也是從上往下依次在鏡像層中查找此文件。找到後，會在容器層中記錄下此刪除操作。

只有當需要修改時才複製一份數據，這種特性被稱作 Copy-on-Write。可見，容器層保存的是鏡像變化的部分，不會對鏡像本身進行任何修改。

這樣就解釋了我們前面提出的問題：容器層記錄對鏡像的修改，所有鏡像層都是只讀的，不會被容器修改，所以鏡像可以被多個容器共享。

構建鏡像

對於 Docker 用戶來說，最好的情況是不需要自己創建鏡像。幾乎所有常用的資料庫、中間件、應用軟體等都有現成的 Docker 官方鏡像或其他人和組織創建的鏡像，我們只需要稍作配置就可以直接使用。

使用現成鏡像的好處除了省去自己做鏡像的工作量外，更重要的是可以利用前人的經驗。特別是使用那些官方鏡像，因為 Docker 的工程師知道如何更好的在容器中運行軟體。

當然，某些情況下我們也不得不自己構建鏡像，比如：

1. 找不到現成的鏡像，比如自己開發的應用程序。
2. 需要在鏡像中加入特定的功能，比如官方鏡像幾乎都不提供 ssh。

所以本節我們將介紹構建鏡像的方法。同時分析構建的過程也能夠加深我們對前面鏡像分層結構的理解。

Docker 提供了兩種構建鏡像的方法：

1. docker commit 命令
2. Dockerfile 構建文件

docker commit

docker commit 命令是創建新鏡像最直觀的方法，其過程包含三個步驟：

1. 運行容器
2. 修改容器
3. 將容器保存為新的鏡像

舉個例子：在 ubuntu base 鏡像中安裝 vi 並保存為新鏡像。

1. 第一步， 運行容器

-it 參數的作用是以交互模式進入容器，並打開終端。412b30588f4a 是容器的內部 ID。

1. 安裝 vi

確認 vi 沒有安裝。

安裝 vi。

1. 保存為新鏡像
   在新窗口中查看當前運行的容器。

silly_goldberg 是 Docker 為我們的容器隨機分配的名字。

執行 docker commit 命令將容器保存為鏡像。

新鏡像命名為 ubuntu-with-vi。

查看新鏡像的屬性。

從 size 上看到鏡像因為安裝了軟體而變大了。

從新鏡像啟動容器，驗證 vi 已經可以使用。

以上演示了如何用 docker commit 創建新鏡像。然而，Docker 並不建議用戶通過這種方式構建鏡像。原因如下：

1. 這是一種手工創建鏡像的方式，容易出錯，效率低且可重複性弱。比如要在 debian base 鏡像中也加入 vi，還得重複前面的所有步驟。
2. 更重要的：使用者並不知道鏡像是如何創建出來的，裡面是否有惡意程序。也就是說無法對鏡像進行審計，存在安全隱患。

既然 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

原文

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎

推薦閱讀：