AWS企業帳號服務 Dockerfile 最佳實踐：最佳化映像檔大小與建構效率

# Dockerfile 最佳實踐：最佳化映像檔大小與建構效率

在實際交付容器化應用時，很多問題並不是出在程式本身，而是出在 Dockerfile 寫法不當：映像檔過大、建構速度慢、快取命中率低、CI/CD 執行時間過長，甚至部署後才發現執行環境不一致。

如果你搜尋這個主題，通常代表你正在做以下其中一件事：

- 想縮小映像檔大小，降低推送與拉取時間
- 想提升 `docker build` 速度，減少 CI/CD 等待時間
- 想讓 Dockerfile 更穩定，避免每次小改動都全量重建
- 想解決依賴安裝慢、快取失效、映像含有不必要檔案等問題

本文不講抽象概念，直接從實際編寫 Dockerfile 時最容易踩坑的步驟切入，提供可直接使用的配置方式與排查思路。

---

## 一、先明確優化目標：你到底要解決什麼問題？

在改 Dockerfile 前，先確認目前是哪一類問題最明顯：

AWS企業帳號服務 ### 1. 映像檔太大
常見現象：

- 映像幾百 MB 到數 GB
- 推送到鏡像倉庫很慢
- 部署時拉取時間長
- 節點磁碟空間很快被佔滿

### 2. 建構速度太慢
常見現象：

- 每次 build 都重新安裝依賴
- 原始碼改一行，整個 Dockerfile 全部重跑
- CI pipeline 大部分時間耗在 build

### 3. 執行階段夾帶了不必要內容
常見現象：

- 正式映像裡還包含編譯工具
- 測試檔、Git 歷史、文件、快取一併被打包
- 存在多餘套件，增加風險與維護成本

AWS企業帳號服務 對應策略其實很明確：

- **縮小映像**：減少基底體積、刪除暫存、只保留執行所需檔案
- **提升建構效率**：優化指令順序、提高快取命中、使用多階段建構
- **提升穩定性**：固定版本、減少不必要變動、隔離建構與執行環境

AWS企業帳號服務 ---

## 二、從基底映像開始：第一步就決定上限

很多 Dockerfile 一開始就寫：

```dockerfile
FROM ubuntu:latest
```

這種寫法在實務上常見，但通常不是最佳選擇。問題主要有兩個：

1. `latest` 不可控，今天能 build，明天可能因基底更新導致結果不同
2. 通用系統映像通常比語言官方精簡映像更大

### 建議做法

#### 1. 優先選擇精簡版本
例如：

```dockerfile
FROM node:20-alpine
```

或：

```dockerfile
FROM python:3.11-slim
```

如果你的應用不依賴特定系統工具，優先考慮：

- `alpine`
- `slim`
- 發行版最小化映像

### 2. 避免直接使用 latest
建議固定版本：

```dockerfile
FROM python:3.11.9-slim
```

好處：

- 建構結果更穩定
- 問題更容易回溯
- 團隊環境一致

### 3. 不要為了方便引入完整開發環境
如果你只是執行 Java jar、Node dist、Go binary，執行階段往往不需要 gcc、make、git、build-essential 這些工具。

這些工具應只存在於建構階段，而不是最終映像。

---

## 三、多階段建構：縮小映像最有效的方法之一

這是最值得優先落地的技巧。

### 適用場景

- 前端專案需先 `npm run build`
- Go 專案需編譯 binary
- Java 專案需 Maven/Gradle 打包
- Python 專案需先建 wheel 或安裝建構依賴

### 範例：Node.js 前端應用

```dockerfile
# 建構階段
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# 執行階段
FROM nginx:1.27-alpine
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
```

### 這樣做的好處

- 最終映像不包含 Node.js 編譯依賴
- 不保留 `node_modules` 建構快取與原始碼工具鏈
- 映像更小，部署更快

AWS企業帳號服務 ### 範例：Go 應用

```dockerfile
FROM golang:1.22-alpine AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app .

FROM alpine:3.20
WORKDIR /app
COPY --from=builder /src/app ./app
EXPOSE 8080
CMD ["./app"]
```

如果是純靜態編譯程式，甚至可進一步使用更精簡的執行映像。

---

## 四、COPY 順序決定快取命中率

這是很多人 build 很慢的核心原因。

### 常見低效寫法

AWS企業帳號服務 ```dockerfile
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
```

這樣寫的問題是：

只要專案中任意檔案有變化，`COPY . .` 這一層就會失效，導致後面的 `npm install` 和 `npm run build` 全部重跑。

### 正確做法：先複製依賴描述檔

```dockerfile
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build
```

這樣只有在 `package.json` 或 `package-lock.json` 變動時才會重新安裝依賴。

### 對 Python 也一樣

```dockerfile
WORKDIR /app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]
```

### 對 Java / Maven 也適用

先複製 `pom.xml`，再下載依賴，最後再複製原始碼。

這一類順序優化，通常能明顯縮短日常重複建構時間。

---

## 五、善用 .dockerignore，別把無關檔案送進建構上下文

很多映像莫名變大，或者 build 速度一直慢，根本原因不是 Dockerfile，而是建構上下文太大。

當你執行：

```bash
docker build -t myapp .
```

目前目錄下的檔案會作為 build context 傳給 Docker daemon。如果沒有 `.dockerignore`，以下內容可能全被送進去：

- `.git`
- `node_modules`
- 日誌檔
- 測試輸出
- 本地快取
- IDE 設定目錄
- 打包產物

### 建議的 .dockerignore 範例

```gitignore
.git
.gitignore
Dockerfile
.dockerignore
node_modules
npm-debug.log
dist
build
coverage
*.log
.env
.vscode
.idea
__pycache__
*.pyc
```

### 使用時要注意

- 如果 Docker build 需要某些檔案，不要誤排除
- 前端專案若在容器內 build，通常不應把原始碼忽略掉
- 若你本地已有 `dist/`，但 Dockerfile 內會重新 build，就應忽略 `dist/`

### 怎麼判斷 context 是否過大？

執行 build 時留意輸出：

```bash
Sending build context to Docker daemon 742.3MB
```

如果這個數字很大，先檢查 `.dockerignore`，通常能立刻找到可優化點。

---

## 六、合併 RUN 指令，但不要為了合併而犧牲可維護性

Docker 每個指令都會形成一層。過多層數不一定是最大問題，但不必要的中間檔若留在同一層之外，會增加映像大小。

### 常見不佳寫法

```dockerfile
RUN apt-get update
RUN apt-get install -y curl vim
RUN apt-get clean
```

這樣可能留下不必要快取資料，而且層之間的清理不一定真正減少最終映像體積。

### 建議寫法

```dockerfile
RUN apt-get update && apt-get install -y --no-install-recommends \
curl \
ca-certificates \
&& rm -rf /var/lib/apt/lists/*
```

### 重點

AWS企業帳號服務 - `apt-get update` 和 `apt-get install` 放在同一個 `RUN`
- 安裝後立即清理 `/var/lib/apt/lists/*`
- 使用 `--no-install-recommends` 減少額外套件

### Alpine 對應方式

```dockerfile
RUN apk add --no-cache curl
```

`--no-cache` 可避免額外快取檔留在映像內。

---

## 七、依賴安裝要可重現，不要讓每次 build 結果不同

如果映像今天能 build、明天失敗，問題往往不是 Docker，而是依賴版本未固定。

### Node.js

使用：

```dockerfile
RUN npm ci
```

而不是：

AWS企業帳號服務 ```dockerfile
RUN npm install
```

原因：

- `npm ci` 依 lock file 安裝
- 更適合 CI/CD
- 結果更穩定

### Python

建議固定 requirements 版本：

AWS企業帳號服務 ```txt
flask==3.0.3
redis==5.0.7
gunicorn==22.0.0
```

Dockerfile：

AWS企業帳號服務 ```dockerfile
RUN pip install --no-cache-dir -r requirements.txt
```

### Java

- 固定 Maven / Gradle 插件版本
- 固定 JDK 映像版本
- 不要依賴浮動版本標籤

AWS企業帳號服務 這樣做的好處不是理論上的，而是能減少「昨天還正常、今天突然壞掉」的 build 問題。

---

## 八、不要把機密寫進 Dockerfile

這是實務中很容易被忽略的風險。

### 錯誤示例

```dockerfile
ENV DB_PASSWORD=123456
ENV API_KEY=abcdefg
```

問題：

- 這些值可能進入映像歷史
- 被推送到倉庫後容易外洩
- 團隊多人共享時難以控管

### 正確做法

把敏感資訊放在：

AWS企業帳號服務 - 執行時環境變數
- Secret 管理服務
- CI/CD 注入參數
- 編排系統的 secrets 機制

Dockerfile 只保留必要的非敏感預設值。

---

## 九、選對 WORKDIR、USER、EXPOSE，減少後期排錯成本

這些看似簡單，但很多部署問題都和它們有關。

### WORKDIR

```dockerfile
WORKDIR /app
```

避免在 Dockerfile 裡大量使用相對混亂的路徑，否則後續 `COPY`、`RUN`、`CMD` 容易出錯。

### USER

不要所有應用都直接以 root 執行。

例如：

```dockerfile
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
```

如果你切到非 root 使用者後程式無法啟動，通常要檢查：

- 檔案權限
- 日誌目錄寫入權限
- 監聽端口是否需要特權

### EXPOSE

```dockerfile
EXPOSE 8080
```

這不是實際開放防火牆，而是讓映像使用者清楚應用預期監聽端口。

很多人把容器不能連線誤以為是 `EXPOSE` 沒寫，實際上更常見原因是：

- 容器程序沒啟動
- 應用只監聽 `127.0.0.1`
- `docker run -p` 沒映射
- 雲伺服器安全組未開放對應端口
- 系統防火牆未放行

---

## 十、實戰範例：從低效 Dockerfile 改到可用版本

下面用一個 Node.js 專案示範常見優化過程。

### 原始版本

```dockerfile
FROM node:latest
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]
```

### 存在問題

- 使用 `latest`，不可控
- `COPY . .` 太早，導致快取失效
- `npm install` 不適合追求穩定建構
- 如果只是執行 build 後產物，最終映像仍保留整個建構環境
- 可能把 `.git`、本地快取、測試檔一併打包

### 優化版本

```dockerfile
FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY --from=builder /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/index.js"]
```

### 對應 .dockerignore

```gitignore
.git
node_modules
dist
coverage
*.log
.env
.vscode
.idea
```

### 優化效果

通常可得到以下改善：

- build 更快
- 改動原始碼後依賴層可重用
- 最終映像更小
- 不再夾帶建構期無關檔案

---

## 十一、如何檢查映像為什麼這麼大？

如果你已經做了優化，但映像仍很大，建議按下面順序排查。

### 1. 看每層大小

```bash
docker history your-image:tag
```

AWS企業帳號服務 重點看：

- 哪個 `RUN` 層異常大
- 是否安裝了過多系統套件
- 是否複製了不必要的大目錄

### 2. 檢查 build context

```bash
docker build -t your-image .
```

觀察輸出中的 context 大小。

### 3. 進容器檢查目錄佔用

```bash
docker run --rm -it your-image sh
du -sh /*
```

進一步查看：

```bash
du -sh /app/*
```

### 4. 檢查是否保留了套件快取

常見位置：

- `/var/lib/apt/lists/`
- `/root/.cache/`
- pip 快取
- npm 快取

### 5. 檢查是否把整個原始碼庫都複製進去

尤其是單體倉庫、包含多個子專案時，最容易誤把全部內容送進映像。

---

## 十二、建構慢的常見原因與解決方法

### 問題 1：每次都重新安裝依賴

**原因**：`COPY . .` 放在依賴安裝前面

**解法**：

- 先複製 lock file
- 先安裝依賴
- 最後再複製原始碼

### 問題 2：CI 每次都是冷啟動

**原因**：沒有使用可重用快取策略

**解法**：

AWS企業帳號服務 - 優化 Dockerfile 指令順序
- 使用支援快取的建構方式
- 保持依賴層穩定，減少不必要變更

### 問題 3：依賴下載特別慢

**排查方向**：

- 套件源是否可達
- DNS 是否正常
- 是否需要配置公司內部代理
- 是否因地區網路導致拉取慢

### 問題 4：build 到一半磁碟滿了

**排查方向**：

- 清理無用 image 和 build cache
- 檢查 CI runner 磁碟容量
- 降低上下文與最終映像大小

常用清理命令：

```bash
docker system df
docker image prune -a
docker builder prune
```

執行前請確認不會影響正在使用的映像與快取。

---

## 十三、容器啟動後無法連線，不一定是 Dockerfile 問題

很多人在最佳化 Dockerfile 後，開始部署到伺服器，結果發現服務打不開。這時候應分層排查，而不是只盯著映像。

### 檢查 1：容器是否真的在執行

```bash
docker ps
```

### 檢查 2：應用是否監聽正確位址

應用應監聽：

- `0.0.0.0`

而不是：

- `127.0.0.1`

否則外部即使做了端口映射也連不進來。

### 檢查 3：端口映射是否正確

```bash
docker run -d -p 3000:3000 your-image
```

### 檢查 4：伺服器防火牆是否放行

Linux 常見檢查方向：

- `ufw`
- `firewalld`
- `iptables`

### 檢查 5：雲伺服器安全組是否已開對應端口

如果應用部署在雲伺服器上，即使容器本身正常，也要確認：

- 公網 IP 是否已配置
- 安全組是否允許 TCP 3000/80/443
- 系統防火牆是否同步放行

這類問題在實際上比 Dockerfile 本身更常造成「服務無法訪問」。

---

## 十四、推薦的通用最佳實踐清單

如果你想快速自查，可以直接對照下面這份清單。

### Dockerfile 編寫檢查表

- [ ] `FROM` 是否固定版本，而非 `latest`
- [ ] 是否選用更精簡的基底映像
- [ ] 是否使用多階段建構
- [ ] 是否先複製依賴描述檔，再安裝依賴
- [ ] 是否配置 `.dockerignore`
- [ ] 是否避免把 `node_modules`、`.git`、log 打進映像
- [ ] 是否清理 apt / pip / npm 快取
- [ ] 是否避免把編譯工具留在最終映像
- [ ] 是否未把密碼、Token、Key 寫進 Dockerfile
- [ ] 是否設定合理的 `WORKDIR`
- [ ] 是否使用非 root 使用者執行應用
- [ ] 是否確認應用監聽 `0.0.0.0`
- [ ] 是否檢查最終映像實際內容與層大小

---

## 十五、結語

Dockerfile 的優化，核心不是把語法寫得更花，而是解決兩個真實問題：

1. **映像不要夾帶不需要的東西**
2. **建構時不要重做不必要的步驟**

如果你現在就要開始調整，建議優先做這四件事：

1. 固定基底映像版本
2. 加上 `.dockerignore`
3. 調整 `COPY` 順序，提高快取命中
4. 改成多階段建構

這四步做完，通常就能明顯看到映像大小與建構時間的改善。

AWS企業帳號服務 如果後續你還遇到具體問題，例如：

- `npm ci` 在容器內失敗
- Python 映像太大
- Alpine 相容性問題
- Java 建構層快取無法命中
- Docker build 在 CI 中特別慢

那就要根據語言、生態與部署環境進一步做針對性調整。真正可落地的最佳實踐，永遠是結合專案現況逐步優化，而不是照搬單一模板。