Docker容器到底该怎么跑？聊聊我从踩坑到上生产的标准流程

笔者运维过的服务器不算少，但真正让我在半夜被叫醒的，十次里有八次跟容器有关。Docker 这东西，入门太容易了，docker run 一行命令就能把服务拉起来，但恰恰是这种”太容易”，让很多人在生产环境里栽了跟头——容器跑着跑着挂了、数据莫名其妙丢了、镜像体积膨胀到几个 G、日志把磁盘写满……

所以今天不聊虚的，站长把自己这些年从开发机到生产集群的容器使用流程完整梳理一遍，按核心原理 → 架构规范 → 加固调优 → 验证SOP的节奏走。这套流程不是官方文档的复读，是踩过坑之后沉淀下来的东西。

一、先搞懂：容器不是”轻量级虚拟机”

💡 推荐阅读：告别命令行焦虑：三款主流开源Docker管理平台深度横评，到底谁才是运维神器？

很多人对 Docker 的误解从第一句话就开始了。容器不是虚拟机，它本质上是被 Linux 内核的 Namespace（隔离视图）和 Cgroups（限制资源）约束起来的一组进程。没有 Guest OS，没有 Hypervisor 层，容器里的进程和宿主机进程共享同一个内核。

理解这一点，后面很多”为什么”就顺了：

• 为什么容器里 top 看到的进程数不对？因为它只能看到自己 Namespace 里的。
• 为什么容器里改时间会影响宿主机？因为内核是共享的。
• 为什么容器一退出数据就没了？因为可写层是跟着容器生命周期走的。

镜像呢？镜像是分层的只读文件系统，容器启动时会在最上面叠一个可写层。所有对文件的修改都写在这层，删了容器，这层也就没了。这就是为什么数据必须挂 Volume，别指望容器自己记住。

二、生产环境的标准操作流程

💡 延伸阅读：Linux服务器配置踩坑实录：SSH连不上、Nginx报502、磁盘满了？这几个高频故障站长帮你排明白了

第 1 步：镜像构建——别用 latest，别塞垃圾

笔者见过太多 Dockerfile 直接 FROM ubuntu:latest 然后 apt 装一堆东西。生产环境请遵守三条铁律：

• 基础镜像用具体版本号，比如 python:3.11-slim，别用 latest。latest 是标签不是版本，哪天上游一改你就炸了。
• 用多阶段构建把编译工具链和运行时分开，镜像能瘦一大圈。
• 合并 RUN 指令，减少层数，顺手清理 apt 缓存。

# 多阶段构建示例
FROM golang:1.21-alpine AS builder
WORKDIR /build
COPY . .
RUN CGO_ENABLED=0 go build -o app .

FROM alpine:3.19
RUN apk add --no-cache ca-certificates tzdata
WORKDIR /app
COPY --from=builder /build/app .
EXPOSE 8080
USER nobody
ENTRYPOINT ["./app"]

注意最后的 USER nobody——默认容器里是 root，这在内网还好，一旦被突破就是宿主机级别的风险。能用非 root 就用非 root。

第 2 步：网络规划——别让容器裸奔

默认的 bridge 网络够用但不优雅，容器之间只能靠 IP 通信，重启一次 IP 就变。生产环境建议：

• 同一组服务放同一个自定义 bridge 网络，容器名直接当 DNS 用，比如 db、redis；
• 对外暴露端口时绑定到 127.0.0.1，前面挂 Nginx 或 Traefik 做反代，别直接 -p 0.0.0.0:3306:3306，那等于把数据库摆到大街上；
• 跨主机通信用 overlay 网络，但小规模场景用 host 模式 + 端口管理反而更省心。

第 3 步：存储挂载——数据比容器重要

三件套：-v 挂配置、-v 挂数据、日志走 stdout。数据库目录、上传文件目录必须落盘到宿主机或者云盘。如果用的是云服务器，建议数据盘单独挂载并做好快照策略，别跟系统盘混在一起。

顺便说一句，选云服务器时别只看 CPU 内存，磁盘 IOPS 和网络带宽才是容器密集场景的瓶颈。站长自己踩过的坑：图便宜买了低配突发性能实例，结果容器一多 CPU 积分耗尽直接降频，服务响应从 50ms 飙到 2s。该花的钱别省。

三、加固与调优清单

💡 深度技术指南：深入Docker源代码：从镜像构建到容器运行的底层架构与性能调优实战

资源限制：不加限制就是定时炸弹

一个内存泄漏的容器能把整台宿主机拖垮。启动时至少限制内存和 CPU：

docker run -d \
  --name web \
  --memory="512m" --memory-swap="512m" \
  --cpus="1.5" \
  --restart=unless-stopped \
  --log-opt max-size=10m --log-opt max-file=3 \
  --network app-net \
  -v /data/web:/app/data \
  web:v1.2.0

这里有几个参数值得单独说：

参数	作用	建议值
--memory-swap	限制内存+交换总量，设为与 memory 相等即禁用 swap	等于 memory
--restart	退出后重启策略	生产用 unless-stopped
--log-opt max-size	单个日志文件上限	10m
--log-opt max-file	日志文件轮转数量	3

日志轮转是最容易被忽略的。默认 json-file 驱动不限制大小，一个高频输出的服务几天就能把磁盘写满，然后宿主机所有容器一起挂。这个坑笔者交过学费，希望你别再交。

健康检查：让编排系统知道容器到底活没活

进程在跑不代表服务可用。加上 HEALTHCHECK：

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD wget -qO- http://localhost:8080/health || exit 1

配合 Compose 或 Swarm 的 depends_on: condition: service_healthy，能避免”数据库还没起来应用就崩了”这种经典问题。

四、验证测试与 SOP 总结

上线前，站长会跑一遍这套检查：

• 镜像扫描：docker scan 或 Trivy 扫一遍 CVE，高危漏洞先修；
• 资源压测：用 stress-ng 在容器里打满，看宿主机是否稳定，OOM Killer 有没有误杀；
• 重启验证：docker restart 后数据是否还在，服务能否自动恢复；
• 日志检查：docker logs --tail 100 确认无异常，轮转是否生效；
• 安全基线：非 root 运行、无特权模式、无敏感目录挂载。

最后给个标准流程的口诀，贴在自己工位上那种：定版本、瘦镜像、限资源、转日志、挂数据、非 root、加健康检查。七条做到，容器基本上就能安安稳稳跑在生产环境里了。

容器本身不复杂，复杂的是它把操作系统层面的东西暴露给了应用开发者。多花点时间理解 Namespace 和 Cgroups，比背一百条命令都有用。

相关技术专题与延伸阅读

• 告别命令行焦虑：三款主流开源Docker管理平台深度横评，到底谁才是运维神器？
• Linux服务器配置踩坑实录：SSH连不上、Nginx报502、磁盘满了？这几个高频故障站长帮你排明白了
• 深入Docker源代码：从镜像构建到容器运行的底层架构与性能调优实战
• 选云服务器别再只看价格了！资深站长私藏的选型指南与避坑实操手册