S15-J05 · Dockerfile 与 Compose

适用读者：镜像动辄 1 GB、或手动 docker run 一堆参数的人。
前置：S15-J04。
实测环境：Docker / alpine:3.20（2026-11-05）。
覆盖旧文：1265(19) 1266(76) 1267(17) 1268(18) 1269(39) 1270(38) 1271(191) = 398 点。
覆盖扩展：E-S15-016（分层与缓存）、E-S15-017（多阶段构建）。
上一篇：S15-J04 · Docker 基础：镜像、容器、数据卷
下一篇：S15-A01 · Nginx 与反向代理。

1. 一句话结论

镜像由"层"组成：每条 RUN/COPY 一层，层可复用；多阶段构建把"编译环境"留在构建阶段，只把产物带进最终镜像——实测省下 8.7 MB（20.8 → 12.1）。

2. 实测：分层长什么样

FROM alpine:3.20 AS build
RUN mkdir -p /build && echo "compile step" > /build/artifact.txt
FROM alpine:3.20
COPY --from=build /build/artifact.txt /app/artifact.txt
CMD ["cat", "/app/artifact.txt"]

实测 docker history：

0B       CMD ["cat" "/app/artifact.txt"]
12.3kB   COPY /build/artifact.txt /app/artifact.txt
0B       CMD ["/bin/sh"]
8.47MB   ADD alpine-minirootfs-3.20.10-x86_64.tar.gz

读法：基础镜像 8.47 MB + 你的产物 12.3 kB = 12.1 MB。

3. 多阶段 vs 单阶段（E-S15-017）

实测对比：

镜像	内容	大小
多阶段（`s15demo:v1`）	只有产物	12.1 MB
单阶段（`s15demo:single`，装了 `curl`）	含构建工具残留	20.8 MB

多阶段省下的 8.7 MB 就是"构建期依赖"——这是"镜像越小越安全"的直接原因（攻击面更小、拉取更快）。

4. 分层缓存：顺序决定快慢（E-S15-016）

# ✅ 依赖先、代码后（改代码不重装依赖）
COPY package.json .
RUN npm ci
COPY . .

顺序	效果
先 `COPY .` 再装依赖	每次改代码都重装依赖
先依赖文件再装	依赖层命中缓存

判据："我改一行代码会触发哪几层重建？" 触发装依赖 → 顺序错了。

5. Compose：把 `run` 参数写成文件（A-1271）

services:
  web:
    image: nginx:alpine
    ports: ["8080:80"]
    volumes: ["./html:/usr/share/nginx/html:ro"]
  redis:
    image: redis:7-alpine

命令	作用
`docker compose up -d`	起全部服务
`docker compose ps`	看状态
`docker compose logs -f web`	看日志
`docker compose down -v`	停并删卷（慎用）

判据："这套服务要一起启停吗？" 要 → Compose；单容器 → docker run 足够。

6. 五个误区

误区	真相
"多阶段只是写法好看"	实测省 8.7 MB
"层越多越慢"	层可缓存，关键在于顺序
"`COPY . .` 放前面没事"	破坏缓存
"`compose down` 不删卷"	`-v` 会删
"镜像大只是占磁盘"	拉取慢 + 攻击面大

7. 自检

镜像层由什么产生？为什么能复用？
多阶段构建省掉了什么？
COPY 顺序为什么影响构建速度？
Compose 与 docker run 的分工？
compose down -v 的风险？

8. 下一篇

S15-A01 · Nginx：反向代理、gzip 与 TLS

容器讲完，进架构师层：请求怎么进到容器，以及 TLS 在哪一层终止。

本篇属于系列《S15 · Linux 与运维》。旧文来源：A-1265/1266/1267/1268/1269/1270/1271；扩展点 E-S15-016/017。镜像大小与分层为真实构建实测。