Docker鏡像的存儲機制

近幾年 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、Overlay二、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 存儲驅動

1. 驗證內核是否支持 AUFS
   $ grep aufs /proc/filesystems
   nodev aufs
2. 若內核支持，可在 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 操做將文件從只讀的鏡像層拷貝到可讀寫的容器層，而後進行修改。在文件很是大的狀況下效率比較低下。
• 刪除文件：刪除文件時，若文件在鏡像層，實際上是在容器層建立一個特殊的 whiteout 文件，容器層訪問不到，並無實際刪掉。
• 目錄重命名：目前 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 操做僅發生在首次，後續對同一文件進行修改，操做容器層文件便可
• 刪除文件或目錄：容器中刪除文件或目錄時，實際上是在容器中建立了一個 whiteout 文件，並無真的刪除文件，只是使其對用戶不可見
• 目錄重命名：僅當源路徑與目標路徑都在容器層時，調用 rename(2) 函數才成功，不然返回 EXDEV

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

很多人可能常用 docker，那麼有沒有思考過鏡像推送至遠程鏡像倉庫，是如何保存的呢？Docker 客戶端是如何與遠程鏡像倉庫交互的呢？

咱們平時本地安裝的 docker 其實包含兩部分：docker client 與 docker engine，docker client 與 docker engine 間經過 API 進行通訊。Docker engine 提供的 API 大體有認證、容器、鏡像、網絡、卷、swarm 等，具體調用形式請參考：Docker Engine API。

Docker engine 與 registry （即：遠程鏡像倉庫）的通訊也有一套完整的 API，大體包含 pull、push 鏡像所涉及的認證、受權、鏡像存儲等相關流程，具體請參考：Registry API。目前經常使用 registry 版本爲 v2，registry v2 擁有斷點續傳、併發拉取鏡像多層等特色。能併發拉取多層是由於鏡像的元信息與鏡像層數據分開存儲，當 pull 一個鏡像時，先進行認證獲取到 token 並受權經過，而後獲取鏡像的 manifest 文件，進行 signature 校驗。校驗完成後，依據 manifest 裏的層信息併發拉取各層。其中 manifest 包含的信息有：倉庫名稱、tag、鏡像層 digest 等， 更多，請參考：manifest 格式文檔。

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

目前官方 Registry 默認提供的存儲驅動包括：微軟 Azure、Google GCS、Amazon S三、Openstack Swift、本地存儲等。若須要使用本身的對象存儲服務，則須要自行實現 Registry 存儲驅動。網易雲目前將鏡像存儲在本身的對象存儲服務 NOS 上，故專門針對 NOS 實現了一套存儲驅動，另外認證服務也對接了網易雲認證服務，並結合自身業務實現了一套認證、受權邏輯，並有效地限制了倉庫配額。

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