前言

Docker 作為容器化技術(shù)的標(biāo)準(zhǔn)，其核心價值在于對應(yīng)用運行環(huán)境的標(biāo)準(zhǔn)化封裝與隔離。要精通 Docker 的運維與開發(fā)，必須深入理解其底層命令的工作原理、數(shù)據(jù)流向以及狀態(tài)流轉(zhuǎn)機制。本文將圍繞容器的生命周期管理（Create/Start/Run）、鏡像的持久化與遷移（Import/Load）以及資源的回收機制（Rm/Rmi/Prune）展開深度剖析。

第一部分：容器生命周期管理的底層邏輯

容器的生命周期本質(zhì)上是進(jìn)程狀態(tài)與文件系統(tǒng)狀態(tài)的組合。Docker 提供了 docker create、docker start 和 docker run 三個命令來精確控制這一過程。理解這三者的區(qū)別，需要從 Docker Daemon（守護(hù)進(jìn)程）如何處理容器配置、讀寫層（Read-Write Layer）以及命名空間（Namespaces）的角度入手。

1. docker create：構(gòu)建容器靜態(tài)實體的過程

docker create 命令的核心職能是初始化容器的配置信息并建立文件系統(tǒng)層級，但并不觸發(fā)容器內(nèi)主進(jìn)程的執(zhí)行。

在執(zhí)行 docker create [IMAGE] 時，Docker Daemon 會執(zhí)行以下一系列原子操作：

1. 鏡像檢查與獲取：驗證本地是否存在指定鏡像。
2. 讀寫層分配：基于聯(lián)合文件系統(tǒng)（UnionFS），在鏡像的只讀層（Read-Only Layers）之上，疊加一層空的讀寫層。這一層用于存儲容器運行期間產(chǎn)生的所有數(shù)據(jù)變更。
3. 配置元數(shù)據(jù)生成：在 /var/lib/docker/containers/<container-id>/ 目錄下生成 config.v2.json 和 hostconfig.json 文件。這些文件記錄了容器的網(wǎng)絡(luò)設(shè)置、環(huán)境變量、掛載點以及資源限制（Cgroups 配額）。
4. 狀態(tài)標(biāo)記：將容器狀態(tài)標(biāo)記為 Created。

此命令的戰(zhàn)略意義在于“配置與運行解耦”。在復(fù)雜的編排場景中，可能需要先行預(yù)分配容器的 ID、網(wǎng)絡(luò)接口或掛載卷，待所有依賴資源就緒后，再統(tǒng)一觸發(fā)運行。

2. docker start：激活容器運行時環(huán)境

docker start [CONTAINER] 的作用是將一個處于 Created 或 Exited 狀態(tài)的靜態(tài)容器轉(zhuǎn)化為一個運行中的進(jìn)程。

當(dāng)執(zhí)行此命令時，Docker 引擎的后端運行時（如 runc）介入工作：

1. 命名空間隔離：初始化 Linux Namespaces（包括 PID、NET、IPC、MNT、UTS），為容器創(chuàng)建獨立的進(jìn)程運行環(huán)境。
2. 控制組應(yīng)用：根據(jù)創(chuàng)建時的配置，將容器進(jìn)程加入對應(yīng)的 Cgroups，實施 CPU、內(nèi)存等資源的硬限制。
3. 主進(jìn)程執(zhí)行：讀取鏡像或配置中指定的 ENTRYPOINT 和 CMD 指令，啟動 PID 為 1 的主進(jìn)程。
4. 狀態(tài)變更：將容器狀態(tài)更新為 Up。

若容器是從 Exited 狀態(tài)啟動，之前在讀寫層產(chǎn)生的數(shù)據(jù)（如日志文件、數(shù)據(jù)庫記錄）依然存在，保證了數(shù)據(jù)在容器重啟過程中的持久性。

3. docker run：復(fù)合操作的原子化封裝

docker run 是 Docker 中使用頻率最高的命令，它并非單一功能的指令，而是 docker create 和 docker start 的邏輯組合，并增加了前臺交互的處理能力。

執(zhí)行 docker run [IMAGE] 的完整內(nèi)部流程如下：

1. API 調(diào)用：Docker Client 向 Docker Daemon 發(fā)送請求。
2. 鏡像拉取：若本地缺失鏡像，觸發(fā) docker pull 操作。
3. 容器創(chuàng)建：執(zhí)行 create 邏輯，分配 ID 和文件系統(tǒng)。
4. 容器啟動：執(zhí)行 start 邏輯，拉起進(jìn)程。
5. 流附加（Attach）：默認(rèn)情況下，Client 端會監(jiān)聽容器的標(biāo)準(zhǔn)輸入（STDIN）、標(biāo)準(zhǔn)輸出（STDOUT）和標(biāo)準(zhǔn)錯誤（STDERR），實現(xiàn)日志的實時回顯或終端交互。

命令差異性總結(jié)表：

第二部分：鏡像數(shù)據(jù)的持久化、遷移與恢復(fù)

在涉及跨網(wǎng)絡(luò)環(huán)境（如氣密內(nèi)網(wǎng)）遷移 Docker 資產(chǎn)時，docker save/load 與 docker export/import 是兩組關(guān)鍵的解決方案。盡管它們最終都能生成鏡像，但其底層的數(shù)據(jù)結(jié)構(gòu)、元數(shù)據(jù)完整性以及適用場景存在本質(zhì)區(qū)別。

1. 鏡像歸檔機制：docker save 與 docker load

docker save 導(dǎo)出的 tar 包是鏡像層（Layers）與元數(shù)據(jù)的完整集合。

• 數(shù)據(jù)完整性：該命令保留了鏡像的所有歷史層級。每一個 RUN、COPY 指令生成的層都會被獨立打包。同時，包含 manifest.json 和鏡像配置 JSON 文件，完整保留了鏡像的 Tag 信息、環(huán)境變量（ENV）、端口暴露（EXPOSE）、啟動命令（CMD/ENTRYPOINT）以及構(gòu)建歷史。
• 多鏡像打包：支持一次性將多個鏡像打包進(jìn)同一個 tar 文件。

對應(yīng)地，docker load 的作用是將這個完整的歸檔文件“重放”到 Docker 的圖驅(qū)動（Graph Driver）中。

• 恢復(fù)邏輯：Docker 引擎會讀取 tar 包中的 manifest，校驗每一層的 SHA256 簽名。如果本地已存在相同的層（由 ID 標(biāo)識），則跳過加載，實現(xiàn)增量恢復(fù)；否則，解壓層數(shù)據(jù)并重建鏡像元數(shù)據(jù)。
• 結(jié)果一致性：恢復(fù)后的鏡像 ID 與源鏡像 ID 完全一致，這保證了環(huán)境的精確復(fù)制。

2. 容器快照機制：docker export 與 docker import

docker export 導(dǎo)出的對象是容器的文件系統(tǒng)快照。

• 扁平化處理：該命令會將容器當(dāng)前的讀寫層與所有只讀層合并，打包成一個單純的文件系統(tǒng) tar 包。在此過程中，所有的層級信息被丟棄，所有的構(gòu)建歷史、元數(shù)據(jù)（如 ENV、CMD）全部丟失。
• 數(shù)據(jù)范圍：僅包含容器當(dāng)前可見的文件。掛載卷（Volumes）中的數(shù)據(jù)通常不會被導(dǎo)出（除非掛載點位于導(dǎo)出路徑內(nèi)且未被特殊處理）。

docker import 則利用這個文件系統(tǒng)快照構(gòu)建一個新的鏡像。

• 鏡像重構(gòu)：導(dǎo)入后，Docker 會創(chuàng)建一個全新的鏡像層（Base Layer），包含 tar 包中的所有文件。
• 元數(shù)據(jù)重建：由于原始元數(shù)據(jù)丟失，新鏡像沒有預(yù)設(shè)的 CMD 或 ENTRYPOINT。在執(zhí)行 docker import 時，通常需要使用 --change 參數(shù)（如 --change "CMD /bin/bash"）來手動補充運行時配置。
• 結(jié)果特性：生成的是一個沒有父層歷史的“扁平”鏡像，體積可能比原始分層鏡像更小，但也失去了分層共享的優(yōu)勢。

3. 核心差異深度對比

第三部分：Docker 資源的清理與維護(hù)策略

隨著 Docker 的長期運行，系統(tǒng)中會積累大量的容器、鏡像、網(wǎng)絡(luò)和卷資源。無效資源不僅占用磁盤空間（尤其是 /var/lib/docker），還可能導(dǎo)致 IP 地址耗盡或構(gòu)建緩存沖突。docker rm、docker rmi 和 docker prune 分別針對不同粒度的資源清理提供了解決方案。

1. docker rm：容器實例的移除

docker rm 專門用于移除容器記錄及其可寫層。

• 狀態(tài)約束：默認(rèn)只能移除 Exited 或 Created 狀態(tài)的容器。若容器正在運行，Docker 守護(hù)進(jìn)程會拒絕操作，以防止誤刪生產(chǎn)服務(wù)。
• 強制刪除機制：使用 -f (--force) 參數(shù)時，Docker 會通過 SIGKILL 信號強制終止容器進(jìn)程，隨后執(zhí)行刪除操作。
• 數(shù)據(jù)卷殘留：這是一個關(guān)鍵的知識盲點。默認(rèn)執(zhí)行 docker rm container_name 不會刪除該容器關(guān)聯(lián)的匿名卷（Anonymous Volumes）。這些卷會變成“懸空卷”（Dangling Volumes），長期占用磁盤。正確的做法是使用 docker rm -v container_name，隨容器一同清理關(guān)聯(lián)的匿名卷。

2. docker rmi：鏡像資產(chǎn)的移除

docker rmi 用于從本地存儲庫中卸載鏡像。

• 引用計數(shù)檢查：Docker 采用引用計數(shù)機制管理鏡像。當(dāng)執(zhí)行 docker rmi image_id 時，系統(tǒng)會檢查是否有已停止或運行中的容器依賴于該鏡像的任何一層。如果存在依賴（即引用計數(shù) > 0），刪除操作會失敗。必須先刪除相關(guān)容器 (docker rm)，釋放引用后才能刪除鏡像。
• 標(biāo)簽解綁 vs 物理刪除：
  • 當(dāng)一個鏡像 ID 對應(yīng)多個 Tag（如 image:latest 和 image:v1）時，docker rmi image:latest 僅執(zhí)行解綁操作（Untag），鏡像實體依然存在。
  • 當(dāng)該鏡像 ID 的最后一個 Tag 被移除，或者直接通過 ID 進(jìn)行刪除時，Docker 才會觸發(fā)物理刪除，清理文件系統(tǒng)中的層數(shù)據(jù)。

3. docker prune：全系統(tǒng)層面的垃圾回收

docker prune 是 Docker 的垃圾回收（GC）指令集，用于批量清理“懸空”或“未使用”的資源。

• 懸空資源 (Dangling)：指沒有 Tag 且沒有被任何容器引用的鏡像（通常顯示為 <none>:<none>），或者是沒有關(guān)聯(lián)任何容器的卷。這些通常是構(gòu)建過程中產(chǎn)生的中間產(chǎn)物。
• 未使用資源 (Unused)：指當(dāng)前未被任何正在運行的容器所引用的資源。范圍比“懸空”更廣。

核心指令解析：

• docker image prune：默認(rèn)僅清理懸空鏡像。
• docker container prune：批量清理所有處于 Exited 狀態(tài)的容器。
• docker system prune：這是最激進(jìn)的清理命令。它會同時執(zhí)行以下操作：
  1. 刪除所有已停止的容器。
  2. 刪除所有未被容器使用的網(wǎng)絡(luò)。
  3. 刪除所有懸空鏡像。
  4. 刪除構(gòu)建緩存（Build Cache）。
• docker system prune -a：極度危險操作。加上 -a (--all) 標(biāo)志后，它不僅刪除懸空鏡像，還會刪除所有當(dāng)前未被運行容器使用的鏡像。這意味著如果本地緩存了 ubuntu:latest 鏡像但暫時沒跑容器，執(zhí)行該命令后鏡像將被直接刪除，下次使用需重新拉取。

總結(jié)

Docker 的命令體系設(shè)計嚴(yán)謹(jǐn)，分別對應(yīng)了不同的資源管理層級。

• 生命周期管理：遵循 Create (配置) -> Start (激活) -> Run (組合) 的邏輯。
• 數(shù)據(jù)遷移：區(qū)分 Save/Load (鏡像完整備份) 與 Export/Import (文件系統(tǒng)快照)。
• 資源清理：依據(jù)依賴關(guān)系鏈，從 rm (容器) 到 rmi (鏡像)，最終通過 prune 實現(xiàn)自動化的垃圾回收。

深入理解這些機制，能夠有效避免生產(chǎn)環(huán)境中的數(shù)據(jù)丟失風(fēng)險，優(yōu)化存儲空間利用率，并提升容器編排的穩(wěn)定性。

到此這篇關(guān)于Docker常見問題（多種類似命令之間的區(qū)別）的文章就介紹到這了,更多相關(guān)docker常見問題內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論