儲存驅動程式

為了有效使用儲存驅動程式，了解 Docker 如何建置和儲存映像檔，以及容器如何使用這些映像檔至關重要。您可以使用此資訊來做出明智的選擇，決定儲存應用程式資料的最佳方式，並避免潛在的效能問題。

儲存驅動程式與 Docker 磁碟區的比較

Docker 使用儲存驅動程式來儲存映像檔層，並將資料儲存在容器的可寫入層中。容器的可寫入層在容器刪除後不會持續存在，但適合儲存執行時產生的暫時性資料。儲存驅動程式針對空間效率進行了優化，但（取決於儲存驅動程式）寫入速度低於原生檔案系統效能，特別是對於使用寫入時複製檔案系統的儲存驅動程式。寫入密集型應用程式，例如資料庫儲存，會受到效能開銷的影響，尤其是在唯讀層中存在預先資料的情況下。

請使用 Docker 磁碟區來儲存寫入密集型資料、必須在容器生命週期結束後仍持續存在的資料，以及必須在容器之間共享的資料。請參閱磁碟區一節，了解如何使用磁碟區來持久化資料並提升效能。

映像檔和層

Docker 映像檔由一系列的層所組成。每個層都代表映像檔 Dockerfile 中的一個指令。除了最後一個層之外，每個層都是唯讀的。請看以下 Dockerfile：

# syntax=docker/dockerfile:1

FROM ubuntu:22.04
LABEL org.opencontainers.image.authors="org@example.com"
COPY . /app
RUN make /app
RUN rm -r $HOME/.cache
CMD python /app/app.py

此 Dockerfile 包含四個命令。修改檔案系統的命令會建立一個新層。FROM 語句會從 ubuntu:22.04 映像檔建立一個層。LABEL 命令僅修改映像檔的中繼資料，並不會產生新層。COPY 命令會從您的 Docker 用戶端目前目錄新增一些檔案。第一個 RUN 命令使用 make 命令建置您的應用程式，並將結果寫入一個新層。第二個 RUN 命令會移除快取目錄，並將結果寫入一個新層。最後，CMD 指令指定要在容器內執行的命令，該命令僅修改映像檔的中繼資料，因此不會產生映像檔層。

每個層都只是與其前一個層之間的差異集。請注意，_新增_ 和 _移除_ 檔案都會導致一個新層。在上述範例中，$HOME/.cache 目錄已被移除，但仍會在前一個層中可用，並會增加映像檔的總大小。請參閱撰寫 Dockerfile 的最佳實踐和使用多階段建置章節，了解如何優化 Dockerfile 以產生高效映像檔。

這些層彼此堆疊。當您建立新容器時，會在底層之上新增一個可寫入層。這個層通常稱為「容器層」。對執行中容器所做的所有變更，例如寫入新檔案、修改現有檔案和刪除檔案，都會寫入此薄型可寫入容器層。下圖顯示一個基於 ubuntu:15.04 映像檔的容器。

Layers of a container based on the Ubuntu image

儲存驅動程式處理這些層之間互動方式的細節。有不同的儲存驅動程式可用，它們在不同的情況下各有利弊。

容器和層

容器和映像檔之間的主要區別是頂部的可寫入層。所有對容器的寫入操作，無論是新增還是修改現有資料，都儲存在這個可寫入層中。當容器被刪除時，可寫入層也會被刪除。底層映像檔保持不變。

由於每個容器都有自己的可寫入容器層，並且所有變更都儲存在此容器層中，因此多個容器可以共享對同一底層映像檔的存取權，但仍擁有自己的資料狀態。下圖顯示多個容器共享相同的 Ubuntu 15.04 映像檔。

Docker 使用儲存驅動程式來管理映像檔層和可寫入容器層的內容。每個儲存驅動程式的實作方式不同，但所有驅動程式都使用可堆疊的映像檔層和寫入時複製 (CoW) 策略。

注意
如果您需要多個容器共享存取完全相同的資料，請使用 Docker 磁碟區。請參閱磁碟區一節以了解磁碟區。

容器在磁碟上的大小

若要查看執行中容器的大約大小，您可以使用 docker ps -s 命令。有兩個不同的欄位與大小相關：

size：用於每個容器可寫入層的資料量 (在磁碟上)。
virtual size：容器使用的唯讀映像檔資料量加上容器可寫入層的 size。多個容器可以共享部分或全部唯讀映像檔資料。從同一個映像檔啟動的兩個容器共享 100% 的唯讀資料，而具有共同層的不同映像檔的兩個容器則共享這些共同層。因此，您不能直接將虛擬大小加總。這會潛在地大幅高估總磁碟使用量。

所有執行中容器在磁碟上使用的總磁碟空間是每個容器的 size 和 virtual size 值的一些組合。如果多個容器從相同的映像檔啟動，這些容器在磁碟上的總大小將是 (容器的 size) 總和加上一個映像檔的大小 (virtual size - size)。

這也不計算容器佔用磁碟空間的以下其他方式：

由日誌驅動程式儲存的日誌檔所使用的磁碟空間。如果您的容器產生大量日誌資料且未設定日誌輪替，這可能會佔用大量空間。
容器使用的磁碟區和繫結掛載。
容器設定檔所使用的磁碟空間，通常很小。
寫入磁碟的記憶體（如果啟用交換）。
檢查點，如果您正在使用實驗性的檢查點/還原功能。

寫入時複製 (CoW) 策略

寫入時複製是一種共享和複製檔案的策略，旨在實現最大效率。如果檔案或目錄存在於映像檔的較低層中，並且另一個層（包括可寫入層）需要讀取它，它只會使用現有檔案。當另一個層第一次需要修改該檔案時（在建置映像檔或執行容器時），該檔案會被複製到該層並進行修改。這可以最大限度地減少 I/O 和後續每個層的大小。這些優點將在下面更深入地解釋。

當您使用 docker pull 從儲存庫拉取映像檔，或者從本地尚未存在的映像檔建立容器時，每個層都會單獨拉取，並儲存在 Docker 的本地儲存區域中，在 Linux 主機上通常是 /var/lib/docker/。您可以在此範例中看到這些層正在被拉取：

$ docker pull ubuntu:22.04
22.04: Pulling from library/ubuntu
f476d66f5408: Pull complete
8882c27f669e: Pull complete
d9af21273955: Pull complete
f5029279ec12: Pull complete
Digest: sha256:6120be6a2b7ce665d0cbddc3ce6eae60fe94637c6a66985312d1f02f63cc0bcd
Status: Downloaded newer image for ubuntu:22.04
docker.io/library/ubuntu:22.04

這些層中的每一個都儲存在 Docker 主機本地儲存區域內的其獨立目錄中。若要檢查檔案系統上的層，請列出 /var/lib/docker/<storage-driver> 的內容。此範例使用 overlay2 儲存驅動程式：

$ ls /var/lib/docker/overlay2
16802227a96c24dcbeab5b37821e2b67a9f921749cd9a2e386d5a6d5bc6fc6d3
377d73dbb466e0bc7c9ee23166771b35ebdbe02ef17753d79fd3571d4ce659d7
3f02d96212b03e3383160d31d7c6aeca750d2d8a1879965b89fe8146594c453d
ec1ec45792908e90484f7e629330666e7eee599f08729c93890a7205a6ba35f5
l

目錄名稱不對應於層 ID。

現在想像您有兩個不同的 Dockerfile。您使用第一個來建立一個名為 acme/my-base-image:1.0 的映像檔。

# syntax=docker/dockerfile:1
FROM alpine
RUN apk add --no-cache bash

第二個是基於 acme/my-base-image:1.0，但有一些額外的層：

# syntax=docker/dockerfile:1
FROM acme/my-base-image:1.0
COPY . /app
RUN chmod +x /app/hello.sh
CMD /app/hello.sh

第二個映像檔包含第一個映像檔的所有層，以及由 COPY 和 RUN 指令建立的新層，還有一個讀寫容器層。Docker 已經擁有了第一個映像檔的所有層，因此不需要再次拉取它們。這兩個映像檔共享所有它們共同的層。

如果您從這兩個 Dockerfile 建置映像檔，可以使用 docker image ls 和 docker image history 命令來驗證共享層的加密 ID 是否相同。

建立一個新目錄 cow-test/ 並進入該目錄。
在 cow-test/ 中，建立一個名為 hello.sh 的新檔案，其內容如下：
#!/usr/bin/env bash echo "Hello world"
將上述第一個 Dockerfile 的內容複製到一個名為 Dockerfile.base 的新檔案中。
將上述第二個 Dockerfile 的內容複製到一個名為 Dockerfile 的新檔案中。

在 cow-test/ 目錄中，建置第一個映像檔。不要忘記在命令中包含最終的 .。這會設定 PATH，告知 Docker 到哪裡尋找需要新增到映像檔的任何檔案。

$ docker build -t acme/my-base-image:1.0 -f Dockerfile.base .
[+] Building 6.0s (11/11) FINISHED
=> [internal] load build definition from Dockerfile.base                                      0.4s
=> => transferring dockerfile: 116B                                                           0.0s
=> [internal] load .dockerignore                                                              0.3s
=> => transferring context: 2B                                                                0.0s
=> resolve image config for docker.io/docker/dockerfile:1                                     1.5s
=> [auth] docker/dockerfile:pull token for registry-1.docker.io                               0.0s
=> CACHED docker-image://docker.io/docker/dockerfile:1@sha256:9e2c9eca7367393aecc68795c671... 0.0s
=> [internal] load .dockerignore                                                              0.0s
=> [internal] load build definition from Dockerfile.base                                      0.0s
=> [internal] load metadata for docker.io/library/alpine:latest                               0.0s
=> CACHED [1/2] FROM docker.io/library/alpine                                                 0.0s
=> [2/2] RUN apk add --no-cache bash                                                          3.1s
=> exporting to image                                                                         0.2s
=> => exporting layers                                                                        0.2s
=> => writing image sha256:da3cf8df55ee9777ddcd5afc40fffc3ead816bda99430bad2257de4459625eaa   0.0s
=> => naming to docker.io/acme/my-base-image:1.0                                              0.0s

建置第二個映像檔。

$ docker build -t acme/my-final-image:1.0 -f Dockerfile .

[+] Building 3.6s (12/12) FINISHED
=> [internal] load build definition from Dockerfile                                            0.1s
=> => transferring dockerfile: 156B                                                            0.0s
=> [internal] load .dockerignore                                                               0.1s
=> => transferring context: 2B                                                                 0.0s
=> resolve image config for docker.io/docker/dockerfile:1                                      0.5s
=> CACHED docker-image://docker.io/docker/dockerfile:1@sha256:9e2c9eca7367393aecc68795c671...  0.0s
=> [internal] load .dockerignore                                                               0.0s
=> [internal] load build definition from Dockerfile                                            0.0s
=> [internal] load metadata for docker.io/acme/my-base-image:1.0                               0.0s
=> [internal] load build context                                                               0.2s
=> => transferring context: 340B                                                               0.0s
=> [1/3] FROM docker.io/acme/my-base-image:1.0                                                 0.2s
=> [2/3] COPY . /app                                                                           0.1s
=> [3/3] RUN chmod +x /app/hello.sh                                                            0.4s
=> exporting to image                                                                          0.1s
=> => exporting layers                                                                         0.1s
=> => writing image sha256:8bd85c42fa7ff6b33902ada7dcefaaae112bf5673873a089d73583b0074313dd    0.0s
=> => naming to docker.io/acme/my-final-image:1.0                                              0.0s

查看映像檔的大小。

$ docker image ls

REPOSITORY             TAG     IMAGE ID         CREATED               SIZE
acme/my-final-image    1.0     8bd85c42fa7f     About a minute ago    7.75MB
acme/my-base-image     1.0     da3cf8df55ee     2 minutes ago         7.75MB

查看每個映像檔的歷史紀錄。

$ docker image history acme/my-base-image:1.0

IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT
da3cf8df55ee   5 minutes ago   RUN /bin/sh -c apk add --no-cache bash # bui…   2.15MB    buildkit.dockerfile.v0
<missing>      7 weeks ago     /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      7 weeks ago     /bin/sh -c #(nop) ADD file:f278386b0cef68136…   5.6MB

有些步驟沒有大小 (0B)，並且只是中繼資料變更，這些變更不會產生映像檔層，除了中繼資料本身之外，也不會佔用任何大小。上述輸出顯示此映像檔由 2 個映像檔層組成。

$ docker image history  acme/my-final-image:1.0

IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT
8bd85c42fa7f   3 minutes ago   CMD ["/bin/sh" "-c" "/app/hello.sh"]            0B        buildkit.dockerfile.v0
<missing>      3 minutes ago   RUN /bin/sh -c chmod +x /app/hello.sh # buil…   39B       buildkit.dockerfile.v0
<missing>      3 minutes ago   COPY . /app # buildkit                          222B      buildkit.dockerfile.v0
<missing>      4 minutes ago   RUN /bin/sh -c apk add --no-cache bash # bui…   2.15MB    buildkit.dockerfile.v0
<missing>      7 weeks ago     /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      7 weeks ago     /bin/sh -c #(nop) ADD file:f278386b0cef68136…   5.6MB

請注意，第一個映像檔的所有步驟也都包含在最終映像檔中。最終映像檔包含來自第一個映像檔的兩個層，以及在第二個映像檔中新增的兩個層。

docker history 輸出中的 <missing> 行表示這些步驟要麼是在另一個系統上建置並屬於從 Docker Hub 拉取的 alpine 映像檔的一部分，要麼是使用 BuildKit 作為建置器建置的。在 BuildKit 之前，「經典」建置器會為每個步驟產生一個新的「中間」映像檔用於快取目的，並且 IMAGE 欄位會顯示該映像檔的 ID。

BuildKit 使用自己的快取機制，不再需要中間映像檔進行快取。請參閱BuildKit，了解 BuildKit 中的其他增強功能。

查看每個映像檔的層
使用 docker image inspect 命令查看每個映像檔中層的加密 ID
$ docker image inspect --format "{{json .RootFS.Layers}}" acme/my-base-image:1.0 [ "sha256:72e830a4dff5f0d5225cdc0a320e85ab1ce06ea5673acfe8d83a7645cbd0e9cf", "sha256:07b4a9068b6af337e8b8f1f1dae3dd14185b2c0003a9a1f0a6fd2587495b204a" ]
$ docker image inspect --format "{{json .RootFS.Layers}}" acme/my-final-image:1.0 [ "sha256:72e830a4dff5f0d5225cdc0a320e85ab1ce06ea5673acfe8d83a7645cbd0e9cf", "sha256:07b4a9068b6af337e8b8f1f1dae3dd14185b2c0003a9a1f0a6fd2587495b204a", "sha256:cc644054967e516db4689b5282ee98e4bc4b11ea2255c9630309f559ab96562e", "sha256:e84fb818852626e89a09f5143dbc31fe7f0e0a6a24cd8d2eb68062b904337af4" ]
請注意，兩個映像檔中的前兩個層是相同的。第二個映像檔增加了兩個額外的層。共享映像檔層只會在 /var/lib/docker/ 中儲存一次，並且在將映像檔推送到映像檔註冊表或從中拉取時也會共享。因此，共享映像檔層可以減少網路頻寬和儲存空間。
提示
使用 --format 選項格式化 Docker 命令的輸出。
上述範例使用帶有 --format 選項的 docker image inspect 命令來查看層 ID，其格式為 JSON 陣列。Docker 命令上的 --format 選項是一個強大的功能，允許您從輸出中提取和格式化特定資訊，而無需其他工具，例如 awk 或 sed。若要了解更多關於使用 --format 旗標格式化 docker 命令輸出，請參閱格式化命令和日誌輸出章節。我們也使用jq 工具美化了 JSON 輸出以提高可讀性。

複製使容器更有效率

當您啟動容器時，一個薄型可寫入容器層會添加到其他層之上。容器對檔案系統所做的任何變更都儲存在這裡。容器未變更的任何檔案都不會複製到此可寫入層。這表示可寫入層盡可能地小。

當容器中的現有檔案被修改時，儲存驅動程式會執行寫入時複製操作。所涉及的具體步驟取決於特定的儲存驅動程式。對於 overlay2 驅動程式，寫入時複製操作遵循以下大致順序：

在映像檔層中搜尋要更新的檔案。此過程從最新的層開始，逐層向下追溯到基本層。找到結果後，會將其新增到快取中以加速未來的操作。
對找到的第一個檔案副本執行 copy_up 操作，將檔案複製到容器的可寫入層。
任何修改都是針對這個檔案副本進行的，容器無法看到存在於較低層的唯讀檔案副本。

Btrfs、ZFS 和其他驅動程式以不同的方式處理寫入時複製。您可以在稍後的詳細描述中閱讀更多關於這些驅動程式方法的資訊。

寫入大量資料的容器比不寫入資料的容器消耗更多空間。這是因為大多數寫入操作都會在容器的薄型可寫入頂層中佔用新空間。請注意，更改檔案的中繼資料，例如更改檔案權限或檔案所有權，也可能導致 copy_up 操作，因此會將檔案複製到可寫入層。

提示
對於寫入密集型應用程式，請使用磁碟區。
對於寫入密集型應用程式，請勿將資料儲存在容器中。這類應用程式，例如寫入密集型資料庫，已知會產生問題，特別是在唯讀層中存在預先資料的情況下。
相反地，請使用 Docker 磁碟區，它們獨立於執行中的容器，並設計用於高效的 I/O。此外，磁碟區可以在容器之間共享，並且不會增加容器可寫入層的大小。請參閱使用磁碟區一節以了解磁碟區。

copy_up 操作可能會產生顯著的效能開銷。此開銷會因使用的儲存驅動程式而異。大型檔案、許多層以及深層目錄樹可能會使影響更加明顯。但由於每個 copy_up 操作僅在首次修改特定檔案時發生，因此這種影響會有所緩解。

為了驗證寫入時複製的工作方式，以下程序會啟動 5 個基於我們之前建置的 acme/my-final-image:1.0 映像檔的容器，並檢查它們佔用了多少空間。

在您的 Docker 主機終端機中，執行以下 docker run 命令。結尾的字串是每個容器的 ID。

$ docker run -dit --name my_container_1 acme/my-final-image:1.0 bash \
  && docker run -dit --name my_container_2 acme/my-final-image:1.0 bash \
  && docker run -dit --name my_container_3 acme/my-final-image:1.0 bash \
  && docker run -dit --name my_container_4 acme/my-final-image:1.0 bash \
  && docker run -dit --name my_container_5 acme/my-final-image:1.0 bash

40ebdd7634162eb42bdb1ba76a395095527e9c0aa40348e6c325bd0aa289423c
a5ff32e2b551168b9498870faf16c9cd0af820edf8a5c157f7b80da59d01a107
3ed3c1a10430e09f253704116965b01ca920202d52f3bf381fbb833b8ae356bc
939b3bf9e7ece24bcffec57d974c939da2bdcc6a5077b5459c897c1e2fa37a39
cddae31c314fbab3f7eabeb9b26733838187abc9a2ed53f97bd5b04cd7984a5a

執行帶有 --size 選項的 docker ps 命令，以驗證 5 個容器正在執行，並查看每個容器的大小。

$ docker ps --size --format "table {{.ID}}\t{{.Image}}\t{{.Names}}\t{{.Size}}"

CONTAINER ID   IMAGE                     NAMES            SIZE
cddae31c314f   acme/my-final-image:1.0   my_container_5   0B (virtual 7.75MB)
939b3bf9e7ec   acme/my-final-image:1.0   my_container_4   0B (virtual 7.75MB)
3ed3c1a10430   acme/my-final-image:1.0   my_container_3   0B (virtual 7.75MB)
a5ff32e2b551   acme/my-final-image:1.0   my_container_2   0B (virtual 7.75MB)
40ebdd763416   acme/my-final-image:1.0   my_container_1   0B (virtual 7.75MB)

上述輸出顯示所有容器共享映像檔的唯讀層 (7.75MB)，但沒有資料寫入容器的檔案系統，因此容器沒有使用額外的儲存空間。

注意
此步驟需要 Linux 機器，且不適用於 Docker Desktop，因為它需要存取 Docker Daemon 的檔案儲存。

雖然 docker ps 的輸出提供了關於容器可寫入層所佔用磁碟空間的資訊，但它不包含每個容器儲存的中繼資料和日誌檔案的資訊。

可以透過探索 Docker Daemon 的儲存位置（預設為 /var/lib/docker）來獲取更多詳細資訊。

$ sudo du -sh /var/lib/docker/containers/*

36K  /var/lib/docker/containers/3ed3c1a10430e09f253704116965b01ca920202d52f3bf381fbb833b8ae356bc
36K  /var/lib/docker/containers/40ebdd7634162eb42bdb1ba76a395095527e9c0aa40348e6c325bd0aa289423c
36K  /var/lib/docker/containers/939b3bf9e7ece24bcffec57d974c939da2bdcc6a5077b5459c897c1e2fa37a39
36K  /var/lib/docker/containers/a5ff32e2b551168b9498870faf16c9cd0af820edf8a5c157f7b80da59d01a107
36K  /var/lib/docker/containers/cddae31c314fbab3f7eabeb9b26733838187abc9a2ed53f97bd5b04cd7984a5a

這些容器在檔案系統上每個只佔用 36k 的空間。

每個容器的儲存

為了證明這一點，請執行以下命令，將單詞「hello」寫入容器 my_container_1、my_container_2 和 my_container_3 的可寫入層中的檔案：

$ for i in {1..3}; do docker exec my_container_$i sh -c 'printf hello > /out.txt'; done

之後再次執行 docker ps 命令，會顯示這些容器現在每個消耗 5 位元組。這些資料對於每個容器都是獨特的，不會共享。容器的唯讀層不受影響，並且仍然由所有容器共享。

$ docker ps --size --format "table {{.ID}}\t{{.Image}}\t{{.Names}}\t{{.Size}}"

CONTAINER ID   IMAGE                     NAMES            SIZE
cddae31c314f   acme/my-final-image:1.0   my_container_5   0B (virtual 7.75MB)
939b3bf9e7ec   acme/my-final-image:1.0   my_container_4   0B (virtual 7.75MB)
3ed3c1a10430   acme/my-final-image:1.0   my_container_3   5B (virtual 7.75MB)
a5ff32e2b551   acme/my-final-image:1.0   my_container_2   5B (virtual 7.75MB)
40ebdd763416   acme/my-final-image:1.0   my_container_1   5B (virtual 7.75MB)

前面的範例說明了寫入時複製檔案系統如何幫助容器提高效率。寫入時複製不僅節省空間，還能縮短容器啟動時間。當您建立容器（或從同一映像檔建立多個容器）時，Docker 只需建立薄型可寫入容器層。

如果 Docker 每次建立新容器時都必須完整複製底層映像檔堆疊，則容器建立時間和使用的磁碟空間將顯著增加。這將類似於虛擬機器的運作方式，每個虛擬機器有一個或多個虛擬磁碟。 vfs 儲存不提供 CoW 檔案系統或其他優化。當使用此儲存驅動程式時，會為每個容器建立映像檔資料的完整副本。