關於儲存驅動程式
為了有效地使用儲存驅動程式，瞭解 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 映象的容器。
儲存驅動程式處理這些層之間互動方式的詳細資訊。有多種可用的儲存驅動程式，它們在不同情況下具有優點和缺點。
容器和層
容器和映象之間的主要區別在於頂層的可寫層。對容器的所有寫入，包括新增新資料或修改現有資料，都將儲存在此可寫層中。當容器被刪除時，可寫層也會被刪除。底層映象保持不變。
由於每個容器都有自己的可寫容器層，並且所有更改都儲存在此容器層中，因此多個容器可以共享對同一個底層映象的訪問，但仍然擁有自己的資料狀態。下圖顯示了多個容器共享同一個 Ubuntu 15.04 映象。
Docker 使用儲存驅動程式來管理映象層和可寫容器層的內容。每個儲存驅動程式以不同的方式處理實現，但所有驅動程式都使用可堆疊的映象層和寫時複製 (CoW) 策略。
注意
如果您需要多個容器共享訪問完全相同的資料，請使用 Docker 卷。請參閱 卷部分，瞭解有關卷的資訊。
容器磁碟大小
要檢視正在執行的容器的大致大小，可以使用 docker ps -s 命令。有兩個不同的列與大小相關。
size：每個容器的可寫層使用的（磁碟上的）資料量。virtual size：容器使用的只讀映象資料量，加上容器的可寫層size。多個容器可能會共享一些或全部只讀映象資料。從同一個映象啟動的兩個容器共享 100% 的只讀資料，而具有不同映象（但有共同層）的兩個容器將共享這些共同層。因此，您不能簡單地將虛擬大小加總。這會高估磁碟總使用量，高估量可能很大。
所有正在執行的容器在磁碟上使用的總磁碟空間是每個容器 size 和 virtual size 值的某種組合。如果多個容器從完全相同的映象啟動，這些容器在磁碟上的總大小將為 SUM（容器的 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。您使用第一個 Dockerfile 建立一個名為 acme/my-base-image:1.0 的映象。
# syntax=docker/dockerfile:1
FROM alpine
RUN apk add --no-cache bash第二個 Dockerfile 基於 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 命令的輸出。上面的示例使用
docker image inspect命令以及--format選項來檢視圖層 ID，這些 ID 以 JSON 陣列的形式格式化。Docker 命令上的--format選項是一個強大的功能，它允許您從輸出中提取和格式化特定資訊，而無需使用awk或sed等其他工具。要了解有關使用--format標誌格式化 docker 命令輸出的更多資訊，請參閱 格式化命令和日誌輸出部分。我們還使用jq實用程式 對其進行美化，以提高可讀性。
複製使容器更高效
啟動容器時，會在其他圖層之上新增一個薄的、可寫的容器圖層。容器對檔案系統所做的任何更改都將儲存在此處。容器未更改的任何檔案都不會複製到此可寫圖層。這意味著可寫圖層儘可能小。
當容器中修改了現有檔案時，儲存驅動程式會執行寫時複製操作。涉及的具體步驟取決於特定的儲存驅動程式。對於 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.75 MB)，但沒有資料寫入容器的檔案系統，因此容器沒有使用額外的儲存空間。
注意
此步驟需要 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 檔案系統或其他最佳化。使用此儲存驅動程式時，會為每個容器建立影像資料的完整副本。