Docker 容器的檔案系統仰賴儲存驅動程式管理，其中 AUFS 和 DeviceMapper 是兩種常見的選擇。AUFS 是一種聯合檔案系統，讓多個目錄掛載至同一虛擬檔案系統，Docker 利用它實作容器分層檔案系統，分享基礎映像層以節省空間並提升啟動速度。AUFS 啟動速度快，讀寫效能佳，但寫入大檔案時效能可能下降，且未納入 Linux 核心主線，需額外設定。DeviceMapper 則是一個 Linux 核心提供的儲存框架，透過 thin provisioning 管理映像層，建立的虛擬區塊裝置僅在寫入資料時佔用空間，並支援快照功能。DeviceMapper 儲存空間管理彈性高，但需要較多設定，且預設容器檔案系統大小有限制。
Docker 儲存驅動程式：AUFS 與 DeviceMapper 的技術解析
在 Docker 的世界中，儲存驅動程式扮演著至關重要的角色，它們負責管理容器的檔案系統層以及影像層的處理。在本篇文章中，我們將探討兩種重要的 Docker 儲存驅動程式：AUFS 和 DeviceMapper。我們將分析它們的工作原理、優缺點以及實際應用中的考量。
AUFS 儲存驅動程式
AUFS（Another UnionFS）是一種聯合檔案系統，它允許將多個目錄掛載到同一個虛擬檔案系統下。Docker 利用 AUFS 實作了容器的分層檔案系統，使得多個容器可以分享相同的基礎影像層，從而節省儲存空間並提高容器的啟動速度。
AUFS 的工作原理
當使用 AUFS 儲存驅動程式時，Docker 會為每個容器建立一個新的可寫層，該層位於基礎影像層之上。當容器對檔案系統進行修改時，AUFS 會在可寫層中建立檔案或目錄的副本，並將修改寫入該副本中。這種 Copy-on-Write（CoW）機制確保了基礎影像層的不可變性，同時允許容器進行個人化的修改。
# docker exec -it 9ce0bef93b3a ls -l /etc/test
-rw-r--r-- 1 root root 0 Apr 7 00:27 /etc/test
AUFS 的優缺點
AUFS 的優點包括快速的容器啟動速度和原生讀寫效能。然而，它也有一些缺點，例如在寫入大檔案時效能下降，以及過多的影像層可能導致檔案查詢時間變長。
# docker exec -it 9ce0bef93b3a rm /etc/test
# docker commit 9ce0bef93b3a
e3b7c789792da957c4785190a5044a773c972717f6c2ba555a579ee68f4a4472
AUFS 的實際應用
在實際應用中，AUFS 是一種不錯的選擇，尤其是在需要快速啟動容器的場景中。然而，需要注意的是，AUFS 並未被納入 Linux 核心的主線，因此在某些 Linux 發行版中可能需要額外的設定。
AUFS 的刪除檔案機制
當在 AUFS 中刪除檔案時，它會建立一個特殊的「whiteout」檔案，該檔案以 .wh. 為字首，用於標記檔案已被刪除。
ls -a /var/lib/docker/aufs/diff/e3b7c789792da957c4785190a5044a773c972717f6c2ba555a579ee68f4a4472/etc/
. .. .wh.test
AUFS 的效能考量
雖然 AUFS 提供了快速的容器啟動速度和原生讀寫效能，但在某些情況下可能會出現效能問題。例如，寫入大檔案或過多的影像層可能會導致效能下降。
DeviceMapper 儲存驅動程式
DeviceMapper 是 Linux 核心提供的一種先進儲存框架，它允許將實體區塊裝置對映到虛擬區塊裝置。Docker 利用 DeviceMapper 的 thin provisioning（thinp）模組實作了影像層的管理。
DeviceMapper 的工作原理
DeviceMapper 使用 thinp 模組建立虛擬區塊裝置，這些裝置的大小可以是任意的，但實際上只在寫入資料時才會佔用儲存空間。此外，thinp 還支援建立卷快照，這些快照最初不會佔用額外的儲存空間，只有在寫入資料時才會分配額外的儲存空間。
# docker info
Containers: 0
Images: 0
Storage Driver: devicemapper
Pool Name: docker-253:1-143980-pool
...
DeviceMapper 的實際應用
在使用 DeviceMapper 時，Docker 守護程式會自動建立兩個必要的區塊裝置：一個用於儲存池，另一個用於儲存後設資料。預設情況下，這些裝置是由稀疏檔案支援的 loopback 裝置。
# ls -alhs /var/lib/docker/devicemapper/devicemapper/
total 292M
4.0K drwx------ 2 root root 4.0K Apr 7 20:58 .
4.0K drwx------ 4 root root 4.0K Apr 7 20:58 ..
291M -rw------- 1 root root 100G Apr 7 20:58 data
752K -rw------- 1 root root 2.0G Apr 7 21:07 metadata
隨著 Docker 和容器技術的不斷發展，儲存驅動程式也在不斷進化。未來，我們可能會看到更多高效能和可擴充套件性的儲存解決方案。同時，現有的儲存驅動程式也將繼續改進，以滿足日益增長的容器化工作負載需求。
Docker 儲存驅動程式詳解：DeviceMapper 與 Btrfs
在探討 Docker 的儲存機制時，我們需要深入瞭解其支援的多種儲存驅動程式。本文將重點分析 DeviceMapper 和 Btrfs 這兩種重要的儲存驅動程式，解析它們的工作原理、優缺點以及在實際應用中的表現。
DeviceMapper 儲存驅動程式
DeviceMapper 是 Docker 中一個重要的儲存驅動程式，它根據 Linux 核心的 Device Mapper 子系統實作。DeviceMapper 提供了精簡組態（thin provisioning）的功能，允許 Docker 容器和映像層使用高效的儲存管理機制。
DeviceMapper 的工作原理
-
基礎裝置的建立：DeviceMapper 首先建立一個包含空白 ext4 檔案系統的基礎裝置。所有新的映像層都是這個基礎裝置的快照。
-
精簡組態：透過精簡組態技術，DeviceMapper 能夠讓多個容器和映像層共用基礎裝置的儲存空間，只有在需要時才分配實際的儲存區塊。
-
容器檔案系統的管理：當容器執行時，其對應的 DeviceMapper 裝置會被掛載到特定的目錄下，顯示容器的檔案系統內容。當容器停止時，其對應的裝置會被解除安裝，目錄內容變為空。
DeviceMapper 的效能考量
使用 DeviceMapper 時，預設情況下 Docker 會使用稀疏檔案作為容器和映像層的後端儲存。這可能會對效能產生影響，因為每次容器修改其檔案系統時，都需要從儲存池中分配新的儲存區塊。
為了提升效能，建議在生產環境中使用真實的區塊裝置來存放資料和後設資料。這可以透過在啟動 Docker 守護程式時傳遞特定的命令列選項來實作，例如 --storage-opt。
# 使用真實區塊裝置提升效能
--storage-opt dm.datadev=/dev/sdb
--storage-opt dm.metadatadev=/dev/sdc
DeviceMapper 的優缺點
優點：
- 提供精簡組態功能，有效管理儲存空間。
- 支援使用真實區塊裝置，提升效能。
缺點：
- 需要基本的 DeviceMapper 子系統操作知識。
- 修改 DeviceMapper 選項需要停止 Docker 守護程式並清除
/var/lib/docker目錄內容。 - 預設的容器檔案系統大小為 10GB，調整此大小較為繁瑣。
Btrfs 儲存驅動程式
Btrfs 是另一種 Docker 支援的儲存驅動程式，它利用了 Btrfs 檔案系統的特性來實作容器的複製寫入（copy-on-write）機制。
Btrfs 的工作原理
-
Btrfs 的基本特性：Btrfs 是一種具有快照（snapshotting）、子卷（subvolumes）等功能的檔案系統，能夠動態地新增或移除區塊裝置，並支援透明壓縮。
-
資料儲存機制：Btrfs 將資料儲存在稱為 “chunk” 的單位中，通常大小約為 1GB。這些 chunk 分散在底層的區塊裝置上。
-
Docker 中的應用：Docker 利用 Btrfs 的快照功能來實作映像層的管理。每個映像層都是前一層的快照，從而實作了高效的儲存利用。
Btrfs 的優缺點
優點：
- 支援快照和子卷，提供靈活的檔案系統管理。
- 能夠動態管理區塊裝置，無需停機。
缺點：
- 仍然被視為一種尚未完全成熟的檔案系統。
- 可能會出現 chunk 空間耗盡的問題，需要進行重新平衡操作。
程式碼範例：檢查 DeviceMapper 狀態
# 檢視 DeviceMapper 組態
dmsetup ls
內容解密：
此命令用於列出目前 DeviceMapper 的組態狀態，包括 docker-253:1-143980-base 和 docker-253:1-143980-pool 等裝置。這有助於管理員瞭解目前的儲存組態。
graph LR
A["Docker Daemon"] -->|使用|> B["DeviceMapper"]
B -->|管理|> C["Container 1"]
B -->|管理|> D["Container 2"]
C -->|使用|> E["基礎裝置"]
D -->|使用|> E
圖表翻譯：
此圖示展示了 Docker Daemon 如何透過 DeviceMapper 管理多個容器，並共用基礎裝置的過程。這說明瞭 DeviceMapper 在 Docker 儲存架構中的核心角色。
本文探討了 Docker 中的 DeviceMapper 和 Btrfs 兩種儲存驅動程式的工作原理、優缺點以及實際應用中的表現。透過對這兩種技術的詳細分析，我們可以更好地理解如何在不同的場景下選擇合適的儲存解決方案，以滿足 Docker 環境的需求。接下來，我們將繼續探索更多 Docker 相關技術，以進一步最佳化我們的容器化應用佈署和管理。
Btrfs 儲存驅動程式的實際應用
在瞭解了 btrfs 儲存驅動程式的理論基礎後，我們現在來探討其實際應用。要使用 btrfs 驅動程式，Docker 需要將 /var/lib/docker 目錄掛載在 btrfs 檔案系統上。假設我們已經準備好了一個 btrfs 分割槽並建立了所需的目錄結構：
# grep btrfs /proc/mounts
/dev/sdb1 /var/lib/docker btrfs rw,relatime,space_cache 0 0
接下來，我們需要修改 DOCKER_OPTS 環境變數來告知 Docker 守護行程使用 btrfs 驅動程式。重新啟動守護行程後，可以透過以下命令驗證驅動程式是否正確啟用：
# docker info
Containers: 0
Images: 0
Storage Driver: btrfs
Execution Driver: native-0.2
Kernel Version: 3.13.0-24-generic
Operating System: Ubuntu 14.04 LTS
CPUs: 1
Total Memory: 490.1 MiB
Name: docker
ID: NQJM:HHFZ:5636:VGNJ:ICQA:FK4U:6A7F:EUDC:VFQL:PJFF:MI7N:TX7L
WARNING: No swap limit support
內容解密：
上述命令輸出了 Docker 的相關資訊，包括正在使用的儲存驅動程式。在本例中，Storage Driver 為 btrfs，表示 btrfs 驅動程式已正確啟用。
探索 btrfs 檔案系統
我們可以使用以下命令來檢查 btrfs 檔案系統的使用情況：
# btrfs filesystem show /var/lib/docker
Label: none uuid: 1d65647c-b920-4dc5-b2f4-de96f14fe5af
Total devices 1 FS bytes used 14.63MiB
devid 1 size 5.00GiB used 1.03GiB path /dev/sdb1
Btrfs v3.12
# btrfs filesystem df /var/lib/docker
Data, single: total=520.00MiB, used=14.51MiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=255.94MiB, used=112.00KiB
Metadata, single: total=8.00MiB, used=0.00
內容解密：
這些命令提供了 btrfs 檔案系統的詳細資訊，包括已使用的空間、總空間以及檔案系統的版本等。
Docker 與 btrfs 子卷
Docker 利用了 btrfs 的子卷（subvolume）功能。每當建立一個新的 Docker 容器時，系統會為其分配一個新的 btrfs 子卷，並將其初始化為父子卷的快照（如果有的話）。同樣的機制也適用於 Docker 映像檔。
讓我們建立一個新的容器，並進一步探索這些概念：
# docker run -d busybox top
Unable to find image 'busybox:latest' locally
511136ea3c5a: Pull complete
df7546f9f060: Pull complete
ea13149945cb: Pull complete
4986bf8c1536: Pull complete
busybox:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Status: Downloaded newer image for busybox:latest
86ab6d8602036cadb842d3a030adf2b05598ac0e178ada876da84489c7ebc612
# btrfs subvolume list /var/lib/docker/
ID 258 gen 9 top level 5 path btrfs/subvolumes/511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158
ID 259 gen 10 top level 5 path btrfs/subvolumes/df7546f9f060a2268024c8a230d8639878585defcc1bc6f79d2728a13957871b
ID 260 gen 11 top level 5 path btrfs/subvolumes/ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2
ID 261 gen 12 top level 5 path btrfs/subvolumes/4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125
ID 262 gen 13 top level 5 path btrfs/subvolumes/86ab6d8602036cadb842d3a030adf2b05598ac0e178ada876da84489c7ebc612-init
ID 263 gen 14 top level 5 path btrfs/subvolumes/86ab6d8602036cadb842d3a030adf2b05598ac0e178ada876da84489c7ebc612
內容解密：
上述命令顯示了每個 Docker 圖層（layer）都被分配了一個新的 btrfs 子卷。我們可以看到，每個子卷都有一個唯一的 ID 和路徑。
快照與提交變更
我們可以對任何圖層進行快照。快照本質上也是一個子卷，它與另一個子卷分享資料和後設資料。讓我們對執行中的容器進行一些變更並提交：
# docker exec -it 86ab6d860203 touch /etc/testfile
# docker commit 86ab6d860203
32cb186de0d0890c807873a3126e797964c0117ce814204bcbf7dc143c812a33
提交變更後，會在 /var/lib/docker/btrfs/subvolumes/ 目錄下建立一個新的 btrfs 子卷。
使用 btrfs 儲存驅動程式的注意事項
使用 btrfs 儲存驅動程式需要注意以下幾點：
- 磁碟空間監控：btrfs 對低磁碟空間非常敏感，需要持續監控並在必要時重新平衡檔案系統。
- 效能問題：對於頻繁建立和修改小檔案的工作負載（如資料函式庫），btrfs 的複製寫入（copy-on-write）機制可能會導致檔案系統碎片化，從而影響效能。
- 移除子卷：刪除 Docker btrfs 子卷時，必須先使用
btrfs subvolume delete命令，然後再物理刪除底層目錄，以避免檔案系統損壞。
Overlay 儲存驅動程式簡介
Overlay 儲存驅動程式是 Docker 最新引入的儲存驅動程式之一，它利用 OverlayFS 檔案系統提供 Docker 圖層的複製寫入功能。
OverlayFS 簡介
OverlayFS是一種聯合檔案系統（union filesystem），它將兩個檔案系統合併成一個。OverlayFS 將檔案系統分為上下兩層：
- 上層（upper）：子檔案系統，用於存放變更。
- 下層（lower）：父檔案系統，用於存放原始資料。
使用 OverlayFS 可以有效地減少儲存空間的使用，並提高 Docker 圖層的管理效率。
OverlayFS 的工作原理
OverlayFS 的工作原理是將多個目錄（稱為層）合併成一個單一的目錄樹。這種機制使得 Docker 可以高效地管理多個圖層，並且只在上層儲存變更的部分，從而節省儲存空間。
使用 OverlayFS 的優點
- 高效的儲存管理：透過只在上層儲存變更的部分，OverlayFS 可以顯著減少所需的儲存空間。
- 快速的圖層管理：OverlayFS 可以快速地建立和刪除圖層，這對於需要頻繁建立和銷毀容器的環境來說非常重要。
使用 OverlayFS 的注意事項
- 核心支援：OverlayFS 需要 Linux 核心的支援，通常需要核心版本在3.18以上。
- 效能考量：雖然 OverlayFS 在許多場景下表現良好，但在某些特定的工作負載下可能會遇到效能問題。
綜上所述，OverlayFS 為 Docker 提供了一種高效且靈活的儲存解決方案。透過瞭解其工作原理和優缺點，可以更好地在實際環境中佈署和使用 Docker。
