天天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

原文