近幾年 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 操作將文件從只讀的鏡像層拷貝到可讀寫的容器層，然后進行修改。在文件非常大的情況下效率比較低下。
- 刪除文件：刪除文件時，若文件在鏡像層，其實是在容器層創建一個特殊的 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 S3、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 地址、存儲驅動信息、回調通知等。
