為什么你的Docker鏡像比我的大一倍？這五個致命差異是關鍵……
我還記得，有一次一個初級開發者對比了我們為同一個 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 1pgrep 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
