為什么你的Docker鏡像比我的大一倍？這五個致命差異是關鍵……

2025-09-22 09:50:33

云計算云原生

在本文中，我將展示?5 個真實可用的 Dockerfile 技巧——資深開發者每天都在用的技巧，這些技巧能節省時間、減少膨脹，并讓容器更適合生產環境。

我還記得，有一次一個初級開發者對比了我們為同一個 Node.js 應用構建的 Docker 鏡像后，這樣問我。

我們用了相同的基礎鏡像、相同的依賴、相同的應用。但我的構建結果更輕、更快、也更容易調試。

“秘訣是什么？”

沒有魔法。

只有經驗。

在本文中，我將展示 5 個真實可用的 Dockerfile 技巧——資深開發者每天都在用的技巧，這些技巧能節省時間、減少膨脹，并讓容器更適合生產環境。

每一條都會詳細解釋，并附帶真實可運行的示例。

技巧 1：最小化層（Minimize Layers）

假設你要在基于 Debian 的鏡像里安裝一些工具：

# Junior way
RUN apt-get update
RUN apt-get install -y curl
RUN apt-get clean

每條 RUN 指令都會新建一個鏡像層。這不僅讓鏡像變大，還會拖慢構建速度和緩存利用率。

資深開發者會這樣寫：

# Senior way
RUN apt-get update && \
    apt-get install -y curl && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

為什么重要：

把命令合并到一條 RUN 里，能減少層數。
rm -rf /var/lib/apt/lists/* 會清除臨時包元數據——省下幾 MB。
&& 保證只要有一條命令失敗，構建會立刻停止，避免留下不完整狀態。

動手試試：

分別用兩種寫法執行 docker build，再 docker images 對比大小。
你會發現資深版本明顯更小、更干凈。

技巧 2：使用 .dockerignore

你不會把 .git 文件夾上傳到生產環境——那為什么要把它放進 Docker 構建上下文？

默認情況下，所有文件都會被送進 Docker 守護進程，除非你顯式忽略。

問題所在：

# Without .dockerignore
COPY . .

如果本地目錄里有：

node_modules/
.git/
logs/
test data…

它們全都會被復制進去——既拖慢構建，又撐爆鏡像。

解決辦法：

在項目根目錄新建一個名為 .dockerignore 的文件：

node_modules
.git
*.log
Dockerfile

現在只有相關文件會被打包。

高級提示：

執行下面這條命令，看看究竟哪些文件被送進了 Docker：

docker build . --no-cache --progress=plain

你會震驚于沒有 .dockerignore 時有多少“垃圾”被復制進去。

技巧 3：多階段構建，打造干凈的生產鏡像

這是 Docker 最強大、卻常被初級開發者忽略的功能之一。

場景：

你在構建 React 應用。
你需要 node 來構建，但運行時并不需要它。

初級 Dockerfile：

FROM node:18
WORKDIR /app
COPY . .
RUN npm install && npm run build
CMD ["npx", "serve", "build"]

最終鏡像里殘留了所有構建工具——無謂的膨脹。

資深 Dockerfile（多階段）：

# Stage 1: Builder
FROM node:18 as builder
WORKDIR /app
COPY . .
RUN npm install && npm run build


# Stage 2: Production
FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html

好處：

最終鏡像體積極小。
沒有 node_modules、沒有源碼、沒有構建工具。
更安全、更快速。

多階段構建尤其適用于：

前端應用
Java 應用（Maven/Gradle 構建）
Go 應用（靜態二進制輸出）

構建并運行：

docker build -t myapp .
docker run -p 80:80 myapp

你的應用將由 nginx 提供，全程看不到 node。

技巧 4：鎖定鏡像版本（Pin Image Versions）

這一點常常導致生產環境噩夢。

危險寫法：

FROM python:latest

今天能跑，可明天 latest 更新后呢？

構建可能失敗，應用可能崩潰。

穩妥寫法：

FROM python:3.11.6-slim

務必鎖定到：

具體版本號
盡可能用精簡變體（slim、alpine）

為什么重要：

docker pull python:latest
docker pull python:3.11.6-slim

對比體積——再想想 CI/CD 時的可靠性。

注意：

別盲目給所有語言都用 alpine——某些庫因 musl 兼容性問題會編譯失敗。務必先測試。

技巧 5：用 HEALTHCHECK 給容器加上自愈能力

資深工程師的標志之一，就是讓系統能在故障時自動恢復。

Docker 的 HEALTHCHECK 正好能做到。

初級開發者常忽略：

大多數初級 Dockerfile 只是簡單啟動應用：

CMD ["node", "server.js"]

可一旦容器跑起來，就沒人知道應用是否還活著。

應用假死怎么辦？
拋出異常但進程沒退怎么辦？
啟動成功，幾分鐘后又崩了怎么辦？

Docker 會愉快地顯示容器“運行中”，即使里面的應用已經壞了。

資深 Dockerfile：

資深開發者會定義 HEALTHCHECK，定期檢查應用是否仍然正常。

HEALTHCHECK --interval=30s --timeout=10s \
  CMD curl -f http://localhost:8080/health || exit 1

每 30 秒執行一次 curl：

返回 200 → Docker 認為容器健康。
失敗 → Docker 標記為不健康。

參數拆解：

--interval=30s：每 30 秒檢查一次。
--timeout=10s：超過 10 秒沒響應就判失敗。
--start-period=10s：給應用 10 秒啟動時間，期間不計入失敗。
--retries=3：連續 3 次失敗才標記為不健康。
CMD：真正的健康檢查命令——這里訪問 /health。

實際項目中的價值：

開發階段：及早發現啟動時的問題。
預發/生產：Docker Swarm、Kubernetes、ECS 會自動重啟被標為不健康的容器。
CI/CD：在運行測試或發布前，更有信心容器真的啟動成功了。

如果應用沒有 /health 接口，也可以用其他方式：

檢查某個文件是否存在
看端口有沒有監聽
甚至測數據庫連不連得通

附加小技巧：進程級健康檢查

如果你的應用沒 HTTP 接口——比如 CLI 工具、TCP 服務、后臺worker——照樣能用 HEALTHCHECK，只要盯著進程在不在。

可以嘗試：

HEALTHCHECK --interval=30s --timeout=10s \
  CMD pgrep myserver || exit 1

pgrep myserver 查找名為 myserver 的進程。

找到 → 退出碼 0，容器健康。

找不到 → 非 0，容器不健康。

適用于：

非 HTTP 服務
純二進制或腳本
遺留守護進程

真實示例：

Java 應用這樣啟動：

CMD ["java", "-jar", "myapp.jar"]

健康檢查可寫成：

HEALTHCHECK CMD pgrep java || exit 1

簡單有效，確保主進程沒悄悄崩潰。

最后的話

這些 Dockerfile 技巧不是什么高深火箭科學，而是讓容器更快、更小、更安全的實用習慣。

快速回顧：

合并 RUN 命令，減少鏡像層。
用 .dockerignore 提速構建。
多階段構建，生成精簡生產鏡像。
鎖定版本，避免未來驚嚇。
加入 HEALTHCHECK，實現監控與自愈。

下次用 Docker 時，挑一兩招試試——看看你的配置能干凈多少。

作者丨Ujjawal Rohra 編譯丨Rio

來源丨網址：https://medium.com/@ujjawalr/5-dockerfile-tricks-that-separate-senior-developers-from-juniors-bcd9846d8b7f

責任編輯：武曉燕來源： dbaplus社群

Docker 鏡像容器