[[206062]]

 近幾年 Docker 風靡技術圈，不少從業人員都或多或少使用過，也了解如何通過 Dockerfile 構建鏡像，從遠程鏡像倉庫拉取自己所需鏡像，推送構建好的鏡像至遠程倉庫，根據鏡像運行容器等。這個過程十分簡單，只需執行 docker build、docker pull、docker push、docker run 等操作即可。但大家是否想過鏡像在本地到底是如何存儲的?容器又是如何根據鏡像啟動的?推送鏡像至遠程鏡像倉庫時，服務器又是如何存儲的呢?下面我們就來簡單聊一聊。

Docker 鏡像本地存儲機制及容器啟動原理

Docker 鏡像不是一個單一的文件，而是有多層構成。我們可通過 docker images 獲取本地的鏡像列表及對應的元信息， 接著可通過docker history <imageId> 查看某個鏡像各層內容及對應大小，每層對應著 Dockerfile 中的一條指令。Docker 鏡像默認存儲在 /var/lib/docker/<storage-driver>中，可通過 DOCKER_OPTS 或者 docker daemon 運行時指定 --graph= 或 -g 指定。

Docker 使用存儲驅動來管理鏡像每層內容及可讀寫的容器層，存儲驅動有 DeviceMapper、AUFS、Overlay、Overlay2、Btrfs、ZFS 等，不同的存儲驅動實現方式有差異，鏡像組織形式可能也稍有不同，但都采用棧式存儲，并采用 Copy-on-Write(CoW) 策略。且存儲驅動采用熱插拔架構，可動態調整。那么，存儲驅動那么多，該如何選擇合適的呢?大致可從以下幾方面考慮：

• 若內核支持多種存儲驅動，且沒有顯式配置，Docker 會根據它內部設置的優先級來選擇。優先級為 AUFS > Btrfs/ZFS > Overlay2 > Overlay > DeviceMapper。若使用 DeviceMapper 的話，在生產環境，一定要選擇 direct-lvm, loopback-lvm 性能非常差。
• 選擇會受限于 Docker 版本、操作系統、系統版本等。例如，AUFS 只能用于 Ubuntu 或 Debian 系統，Btrfs 只能用于 SLES (SUSE Linux Enterprise Server, 僅 Docker EE 支持)。
• 有些存儲驅動依賴于后端的文件系統。例如，Btrfs 只能運行于后端文件系統 Btrfs 上。
• 不同的存儲驅動在不同的應用場景下性能不同。例如，AUFS、Overlay、Overlay2 操作在文件級別，內存使用相對更高效，但大文件讀寫時，容器層會變得很大;DeviceMapper、Btrfs、ZFS 操作在塊級別，適合工作在寫負載高的場景;容器層數多，且寫小文件頻繁時，Overlay 效率比 Overlay2 更高;Btrfs、ZFS 更耗內存。

Docker 容器其實是在鏡像的最上層加了一層讀寫層，通常也稱為容器層。在運行中的容器里做的所有改動，如寫新文件、修改已有文件、刪除文件等操作其實都寫到了容器層。容器層刪除了，最上層的讀寫層跟著也刪除了，改動自然也丟失了。若要持久化這些改動，須通過 docker commit <containerId> [repository[:tag]] 將當前容器保存成為一個新鏡像。若想將數據持久化，或是多個容器間共享數據，需將數據存儲在 Docker volume 中，并將 volume 掛載到相應容器中。

存儲驅動決定了鏡像及容器在文件系統中的存儲方式及組織形式，下面分別對常見的 AUFS、Overlay 作一簡單介紹。

AUFS

AUFS 簡介

AUFS 是 Debian (Stretch 之前的版本，Stretch默認采用 Overlay2) 或 Ubuntu 系統上 Docker 的默認存儲驅動，也是 Docker 所有存儲驅動中最為成熟的。具有啟動快，內存、存儲使用高效等特點。如果使用的 Linux 內核版本為 4.0 或更高，且使用的是 Docker CE，可考慮使用Overlay2 (比 AUFS 性能更佳)。

配置 AUFS 存儲驅動

① 驗證內核是否支持 AUFS

$ grep aufs /proc/filesystems  
nodev aufs 

② 若內核支持，可在 docker 啟動時通過指定參數 --storage-driver=aufs 選擇 AUFS

AUFS 存儲驅動工作原理

采用 AUFS 存儲驅動時，有關鏡像和容器的所有層信息都存儲在 /var/lib/docker/aufs/ 目錄下，下面有三個子目錄：

• /diff：每個目錄中存儲著每層鏡像包含的真實內容
• /layers：存儲有關鏡像層組織的元信息，文件內容存儲著該鏡像的組建鏡像列表
• /mnt：掛載點信息存儲，當創建容器后，mnt 目錄下會多出容器對應的層及該容器的 init 層。目錄名稱與容器 ID 不一致。實際的讀寫層存儲在 /var/lib/docker/aufs/diff，直到容器刪除，此讀寫層才會被清除掉。

采用 AUFS 后容器如何讀寫文件?

讀文件

• 容器進行讀文件操作有以下三種場景：
• 容器層不存在： 要讀取的文件在容器層中不存在，存儲驅動會從鏡像層逐層向下找，多個鏡像層中若存在同名文件，上層的有效。
• 文件只存在容器層：讀取容器層文件

容器層與鏡像層同時存在：讀取容器層文件

修改文件或目錄

容器中進行文件的修改同樣存在三種場景：

• ***次寫文件：若待修改的文件在某個鏡像層中，AUFS 會先執行 copy_up 操作將文件從只讀的鏡像層拷貝到可讀寫的容器層，然后進行修改。在文件非常大的情況下效率比較低下。
• 刪除文件：刪除文件時，若文件在鏡像層，其實是在容器層創建一個特殊的 writeout 文件，容器層訪問不到，并沒有實際刪掉。

目錄重命名：目前 AUFS 還不支持目錄重命名。

OverlayFS

OverlayFS 簡介

OverlayFS 是一種類似 AUFS 的現代聯合文件系統，但實現更簡單，性能更優。OverlayFS 嚴格說來是 Linux 內核的一種文件系統，對應的 Docker 存儲驅動為 Overlay 或者 Overlay2，Overlay2 需 Linux 內核 4.0 及以上，Overlay 需內核 3.18 及以上。且目前僅 Docker 社區版支持。條件許可的話，盡量使用 Overlay2，與 Overlay 相比，它的 inode 利用率更高。

容器如何使用 Overlay/Overlay2 讀寫文件

讀文件

讀文件存在以下三種場景：

• 文件不存在容器層：若容器要讀的文件不在容器層，會繼續從底層的鏡像層找
• 文件僅在容器層：若容器要讀的文件在容器層，直接讀取，不用在底層的鏡像層查找
• 文件同時在容器層和鏡像層：若容器要讀的文件在容器層和鏡像層中都存在，則從容器層讀取

修改文件或目錄

寫文件存在以下三種場景：

• ***寫文件：若要寫的文件位于鏡像層中，則執行 copy_up 將文件從鏡像層拷貝至容器層，然后進行修改，并在容器層保存一份新的。若文件較大，效率較低。OverlayFS 工作在文件級別而不是塊級別，這意味著即使對文件稍作修改且文件很大，也須將整個文件拷貝至容器層進行修改。但需注意的是，copy_up 操作僅發生在***，后續對同一文件進行修改，操作容器層文件即可
• 刪除文件或目錄：容器中刪除文件或目錄時，其實是在容器中創建了一個 writeout 文件，并沒有真的刪除文件，只是使其對用戶不可見
• 目錄重命名：僅當源路徑與目標路徑都在容器層時，調用 rename(2) 函數才成功，否則返回 EXDEV

遠程鏡像倉庫如何存儲鏡像?

不少人可能經常使用 Docker，那么有沒有思考過鏡像推送至遠程鏡像倉庫，是如何保存的呢?Docker 客戶端是如何與遠程鏡像倉庫交互的呢?

我們平時本地安裝的 Docker 其實包含兩部分：docker client 與 docker engine，docker client 與 docker engine 間通過 API 進行通信。Docker engine 提供的 API 大致有認證、容器、鏡像、網絡、卷、swarm 等，具體調用形式請參考：Docker Engine API(https://docs.docker.com/engine/api/v1.27/#)。

Docker engine 與 registry (即：遠程鏡像倉庫)的通信也有一套完整的 API，大致包含 pull、push 鏡像所涉及的認證、授權、鏡像存儲等相關流程，具體請參考：Registry API(https://github.com/docker/distribution/blob/master/docs/spec/api.md)。目前常用 Registry 版本為 v2，Registry v2 擁有斷點續傳、并發拉取鏡像多層等特點。能并發拉取多層是因為鏡像的元信息與鏡像層數據分開存儲，當 pull 一個鏡像時，先進行認證獲取到 token 并授權通過，然后獲取鏡像的 manifest 文件，進行 signature 校驗。校驗完成后，依據 manifest 里的層信息并發拉取各層。其中 manifest 包含的信息有：倉庫名稱、tag、鏡像層 digest 等， 更多，請參考：manifest 格式文檔(https://github.com/docker/distribution/blob/master/docs/spec/manifest-v2-1.md)。

各層拉下來后，也會先在本地進行校驗，校驗算法采用 sha256。Push 過程則先將鏡像各層并發推至 Registry，推送完成后，再將鏡像的 manifest 推至 Registry。Registry 其實并不負責具體的存儲工作，具體存儲介質根據使用方來定，Registry 只是提供一套標準的存儲驅動接口，具體存儲驅動實現由使用方實現。

目前官方 Registry 默認提供的存儲驅動包括：微軟 Azure、Google gcs、Amazon s3、OpenStack swift、阿里云 OSS、本地存儲等。若需要使用自己的對象存儲服務，則需要自行實現 registry 存儲驅動。網易云目前將鏡像存儲在自己的對象存儲服務 nos 上，故專門針對 nos 實現了一套存儲驅動，另外認證服務也對接了網易云認證服務，并結合自身業務實現了一套認證、授權邏輯，并有效地限制了倉庫配額。

Registry 干的事情其實很簡單，大致可分為：① 讀配置 ;② 注冊 handler ;③ 監聽。本質上 Registry 是個 HTTP 服務，啟動后，監聽在配置文件設定的某端口上。當 http 請求過來后，便會觸發之前注冊過的 Handler。Handler 包含 manifest、tag、blob、blob-upload、blob-upload-chunk、catalog 等六類，具體請可參考 Registry 源碼： /registry/handlers/app.go:92。配置文件包含監聽端口、auth 地址、存儲驅動信息、回調通知等。