1196 字

6 分钟

Docker 生产实践：从能跑到跑得稳的 Checklist

2026-08-06

工具运维

Docker

/

DevOps

/

Container

/

Production

先说结论#

「Docker 能跑」和「Docker 能稳定跑」是两回事。本地 docker run 一次成功，和在生产集群里扛住流量、重启、扩容，中间隔着不少坑。

这篇文章是我在生产环境踩过之后总结的 Checklist。不追求面面俱到，只讲高频、高影响的十件事，按重要程度排序。

1. 镜像尽量小，但要小得有理#

镜像体积直接影响拉取时间和启动速度。常见手段：

用 alpine 或 distroless 作为基础镜像
多阶段构建：构建阶段用全量镜像，运行阶段只拷贝产物
清理不必要的缓存和包管理器元数据

1
# 多阶段构建示例
2
FROM node:20-alpine AS build
3
WORKDIR /app
4
COPY package*.json ./
5
RUN npm ci
6
COPY . .
7
RUN npm run build
8

9
FROM node:20-alpine
10
WORKDIR /app
11
COPY --from=build /app/dist ./dist
12
COPY --from=build /app/package*.json ./
13
RUN npm ci --omit=dev
14
EXPOSE 3000
15
CMD ["node", "dist/index.js"]

但注意：不是越瘦越好。distroless 没有 shell，调试会很痛苦；alpine 的 musl libc 偶尔和依赖有兼容问题。先瘦到合理范围，别为了几十 MB 自找麻烦。

2. 非 root 用户运行#

默认容器内是 root，这是安全大忌。一旦容器被攻破，攻击者就是 root 权限。

1
FROM node:20-alpine
2
# 创建非 root 用户
3
RUN addgroup -S app && adduser -S app -G app
4
USER app

大多数官方镜像现在都支持直接切用户。这一步成本极低，收益很高。

3. 健康检查必须配#

没有健康检查，编排系统（K8s/Swarm）就不知道你的容器是不是真的活着。进程在不代表服务可用。

1
HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
2
  CMD wget -q -O - http://localhost:3000/healthz || exit 1

注意 start-period——给应用启动留时间，别一上来就被打回。

4. 日志打 stdout，别写文件#

容器里的日志应该走 stdout/stderr，由编排系统收集，而不是写到容器内的文件。原因：

容器文件系统是临时的，重启就没了
你没法轻易拿到容器内的文件
云平台（CloudWatch、ELK、Loki）都从 stdout 收集

所以应用日志直接 console.log/print，别自己写日志文件轮转。

5. 资源限制，不是可选项#

不设 --memory 和 --cpus 限制，一个失控的容器能拖垮整个节点。

1
# docker-compose 或 k8s 里都要设
2
resources:
3
  limits:
4
    memory: 512M
5
    cpus: "0.5"
6
  reservations:
7
    memory: 256M

limits 一定要设，reservations 至少给一个合理值。这是生产环境第一道防线。

6. 环境变量和密钥，别硬编码#

镜像里不要写死任何密钥。用：

环境变量（运行时注入）
Docker secrets / K8s secrets
专门的密钥管理（Vault、云厂商的 secrets manager）

镜像一旦构建就难以「撤销」里面硬编码的密钥。密钥泄露的补救成本远高于一开始就用环境变量。

7. 固定依赖版本，别用 latest#

FROM node:20-alpine 里的 20 可能今天和明天解析到不同的小版本。生产环境要可复现：

基础镜像用精确 tag（如 node:20.18.0-alpine）
依赖锁文件（package-lock.json / poetry.lock）进镜像
有需要时用 digest 固定镜像

可复现 = 可回滚 = 可调试。

8. 处理僵尸进程和信号#

容器作为 PID 1 时，要正确处理信号（SIGTERM）和孤儿进程。常见方案：

用带 PID 1 处理的运行时（如 tini）
确保应用能优雅关闭（监听 SIGTERM，完成在途请求）

1
RUN apk add --no-cache tini
2
ENTRYPOINT ["/sbin/tini", "--"]
3
CMD ["node", "dist/index.js"]

不然 docker stop 会变成 kill -9，数据库写一半就没了。

9. 镜像构建也要考虑 .dockerignore#

.dockerignore 能大幅减少构建上下文和镜像体积，避免把 node_modules、.git、日志、临时文件打进去。

1
node_modules
2
.git
3
*.log
4
.tmp
5
dist

这也是多阶段构建里第一层就过滤掉的东西。

10. 一个容器一个职责#

别在一个容器里跑 web + worker + cron。拆开：

各自独立扩缩容
一个挂了不影响其他
日志、健康检查、资源限制都更清晰

一个容器只做一件事，是容器化最大的架构收益。

验证清单#

改完以后，跑一遍这个验证：

1
# 1. 镜像构建成功且体积合理
2
docker build -t my-app .
3

4
# 2. 容器能启动且健康检查通过
5
docker run -d --name test -p 3000:3000 my-app
6
docker inspect --format='{{.State.Health.Status}}' test
7
# 期望: healthy
8

9
# 3. 优雅停止
10
docker stop test
11
# 观察日志是否有优雅关闭记录
12

13
# 4. 资源限制生效
14
docker run --rm -m 256m my-app
15
# 期望: 超出限制时 OOM，而不是拖垮宿主