我刚开始折腾容器那阵子，脑子里一直有个误区：以为 Docker 就等于"把一个应用打包成一个文件"，换个服务器解压一下就能跑。直到我在某个需要部署多服务联调的项目里，连续三次被环境依赖问题卡住——同样的代码，在开发机、测试机、生产机上表现各不一样，才真正意识到 Docker 的核心价值根本不是"打包"这么简单，而是把运行环境本身变成可分发、可校验、可复现的产物。
这篇内容我会从 Docker 要解决的根本问题讲起，把镜像分层、Namespace、Cgroups 这些底层机制拆开揉碎，再带着你把 run、Dockerfile、Compose 这三大块实战走一遍。中间所有命令我都尽量给出能直接跑的示例，也会把那些官方文档里不会写的"坑"和排查思路放进去。适合刚接触 Docker 的入门者系统建立知识框架，也适合用过一段时间、但对原理和调优还比较模糊的同学查漏补缺。
1. 先搞懂一件事：Docker 到底解决了什么"环境地狱"
1.1 从我经历的第一个"换个服务器就崩"说起
早期我做一个前后端分离的模拟项目，前端用 Node.js 构建，后端是一套 Python 服务，数据库用的 MySQL。开发阶段大家都觉得没什么问题，但到了部署阶段，噩梦就来了：某台测试服务器的系统库版本偏老，某个依赖装不上；另一台服务器的 Python 版本和本地不一致，一启动就报语法错误；更别提 MySQL 的字符集配置差异导致的中文乱码。那时候排查环境问题花的时间，比写业务代码还多。
Docker 对这件事的解法是"釜底抽薪"：它不只打包你的代码，而是把代码、运行时、系统库、配置文件、环境变量、启动命令全部打进一个镜像里。镜像一旦构建完成，不管在谁的机器上运行，跑出来的都是同一个环境。这就相当于搬家的时候把整个房间一起搬走，而不是只搬家具，再换个地方重新组装。理解了这一点，你才能理解后面所有概念都围绕"环境隔离"和"环境一致"展开。
1.2 镜像和容器真的是"一个东西"吗
很多人最开始把"镜像"和"容器"混着说，其实两者的关系可以类比成"程序"和"进程"。镜像是一个静态的、只读的文件集合，里面包含了一个完整可运行环境的所有内容；容器则是镜像运行起来之后的动态实例，有自己的生命周期，可以被启动、停止、删除。
用一条命令就能感受到这种关系：
docker run -d --name web-test nginx:1.25这里nginx:1.25是镜像，docker run创建出来的web-test是容器。镜像本身不会变化，但容器在运行过程中会产生自己的可写层、进程、网络配置和数据。同一个镜像可以同时启动多个容器，它们之间彼此隔离，互不干扰。官方文档里有一句话我一直觉得是理解 Docker 的关键："容器是镜像的实例，镜像构建时是静态的，容器运行时是动态的。"后面讲镜像分层时，你会更直观地看到这种关系。
2. 镜像分层的底层机制：为什么多镜像复用还能各管各的
2.1 联合文件系统：每一层的"变更记录"
Docker 镜像不是一个大文件，而是由很多只读层叠加而成的。每一层对应 Dockerfile 里的一条指令，比如FROM、RUN、COPY。层叠加的逻辑由联合文件系统实现，目前主流的存储驱动是 overlay2。
你可以把镜像层想象成一本不断修订的书：每一层只记录相对上一层的变更内容，而不是完整内容。比如基础镜像ubuntu是最底层，上面执行一条RUN apt-get install nginx，就多了一层"安装了 nginx"的差异记录。读取文件时，联合文件系统会从最上层往下找，直到找到目标文件；写入文件时则采用"写时复制"策略——底层的文件不会被修改，而是先复制到容器的可写层，再在可写层里改。
用docker history命令可以直观看到这个分层结构：
docker history nginx:1.25 docker history --no-trunc nginx:1.25--no-trunc会显示完整指令，而不只是截断后的摘要。我第一次跑这个命令的时候才真正理解了为什么 Docker 镜像能"复用"：多个镜像如果共享同一个基础层，各自再叠加自己的变更层，磁盘上只需要存一份公共层。这也解释了为什么你拉取一个新镜像时，经常看到"Already exists"——那些层已经存在了。
2.2 隔离不靠虚拟机的"三室一厅"：Namespace 与 Cgroups
虚拟机是完整的操作系统级隔离，每个虚拟机有独立的内核；容器则不同，它共享宿主机的内核，只通过内核的 Namespace 和 Cgroups 机制做资源和视图隔离。
Namespace 的作用是让容器"看到"的进程、网络、文件系统等是隔离的视图。比如 PID Namespace 让容器内进程 PID 从 1 开始，看不到宿主机其他进程；Mount Namespace 让容器有自己的挂载点视图；Network Namespace 让容器有独立的网络栈，包括自己的 IP 地址、路由表、端口。你甚至可以这样理解：Namespace 是给容器发了一副"特制眼镜"，让它只能看见分配给自己的那一部分系统资源。
Cgroups 则负责"配额管理"，限制容器最多能用多少 CPU、内存、磁盘 IO。Namespace 是"看得见什么"的问题，Cgroups 是"能用多少"的问题。两者配合，才让容器在共享内核的前提下，实现了近似虚拟机的隔离效果。
2.3 分层缓存：为什么改一个依赖会触发全局重建
镜像分层机制直接影响 Dockerfile 的构建性能。Docker 构建时，如果某条指令对应层没有变化，会直接复用缓存；但只要某一层变了，它之上的所有层都会重新构建。
举一个非常典型的反面例子：如果你把COPY . /app写在RUN pip install -r requirements.txt之前，那么只要项目里任意一行代码有改动，依赖安装层就会被强制重新执行，每次都白白跑一遍耗时的小时级安装。正确的做法是把依赖声明文件先拷进去，安装依赖，再把全部代码拷进去：
COPY requirements.txt /app/ RUN pip install -r /app/requirements.txt COPY . /app/这样依赖层能最大限度复用缓存。这个习惯在团队协作中尤其重要：某个队友天天改代码，所有人的构建都跟着天天重新装依赖，浪费的可不是一点点时间。
3. 从零启动的第一个容器：命令清单与网络数据卷详解
3.1 一条 run 命令背后的完整流程
docker run的完整流程可以拆成这几步：检查本地是否存在指定镜像，不存在则从配置的仓库拉取；基于镜像创建一个容器（分配可写层、分配容器 ID）；按照网络配置分配 IP 地址和虚拟网络接口；执行镜像里配置的启动命令；如果命令前台运行，则容器保持存活。
掌握容器生命周期，最常用的命令就是这几条：
docker run -d --name app -p 8080:80 nginx:1.25 docker ps -a docker logs -f app docker exec -it app bash docker stop app docker rm appdocker exec -it app bash是日常排障最频繁用的命令，它会进入容器内部打开一个交互式 Shell。注意-i保持标准输入打开，-t分配一个伪终端，两者配合才能获得正常终端体验。再强调一个基础但重要的点：容器主进程退出，容器就退出了。很多人困惑"为什么我的容器刚启动就变成 Exited"，通常就是因为主进程分配到了后台，或者本身是一个会在执行完就退出的命令，后面排查部分会具体分析。
3.2 端口映射与网络模式：数据是怎么"进门"的
Docker 默认网络模式是bridge，容器有自己的私有网段，宿主机和容器之间通过虚拟网桥通信。容器内跑的 Nginx 监听 80 端口，宿主机上未必能直接访问，需要做端口映射：
docker run -d --name app -p 8080:80 nginx:1.25这条命令中-p 8080:80表示宿主机 8080 端口收到的流量转发到容器 80 端口。其底层实现是 iptables 的 DNAT 规则：宿主机收到指向 8080 的 TCP 包，DAT 目标地址改写为容器的 IP，再从虚拟网桥送进容器。想验证规则可以执行：
iptables -t nat -L -n | grep 8080如果不需要端口映射，也可以直接用--network host让容器共享宿主机网络栈，此时容器直接监听宿主机端口，无 NAT 转发。这个模式性能更好，但会牺牲网络隔离性。还有一个none模式，容器没有网络接口，适合只做纯计算、不需要对外通信的作业任务。
3.3 数据能活多久：Volume、Bind Mount 与"容器不保存状态"
Docker 容器设计上是"无状态"的，容器删除后，可写层里的一切数据都会消失。要让数据持久化，必须使用数据卷（Volume）或绑定挂载（Bind Mount）。
数据卷是 Docker 管理的存储，存放在宿主机/var/lib/docker/volumes/下，推荐用--mount语法：
docker run -d --name db \ --mount source=db-data,target=/var/lib/mysql \ mysql:8.0绑定挂载则是把宿主机某个目录直接映射进容器，适合开发时热更新代码：
docker run -d --name app \ -v /home/user/project:/app \ node:18两种方式的取舍很直接：数据卷更规范、不依赖宿主机目录结构，适合数据库等持久化数据；绑定挂载更直观，适合开发和调试。我的一个习惯是数据库之类的重要数据永远用数据卷，因为docker volume ls可以统一查看和管理，备份迁移也方便；绑定挂载则只在本地开发时用，避免误删生产数据。
4. Dockerfile 的高效写法：把"能跑"升级成"跑得稳"
4.1 指令顺序决定构建缓存命中率
Dockerfile 是镜像构建的"蓝图"，它的指令顺序直接决定了层缓存命中率。除了前面提到的依赖声明放前面、代码放后面之外，还有几个值得注重的习惯。
RUN指令写多个 shell 命令时，推荐用&&连成一条，并在最后清理缓存和临时文件，这样可以减少层数。比如装系统包时：
RUN apt-get update && apt-get install -y \ curl \ vim \ && rm -rf /var/lib/apt/lists/*这样既保证了构建产物精简，也不会留下大量 apt 缓存撑大镜像体积。
还有一个很少有人注意但特别影响体验的细节：.dockerignore文件。它和.gitignore作用类似，用来排除构建上下文中的不必要文件。如果项目里有node_modules、.git、dist之类的目录却不加排除，每次构建都会把这些文件全部打包到构建上下文中，不仅慢，还容易引发缓存失效。
4.2 多阶段构建：把编译环境和运行环境分开
多阶段构建算是 Dockerfile 里最能改善实际部署形态的一招。它的思路是：在第一个阶段使用完整的编译工具链完成构建，在第二个阶段只拷贝编译产物，运行环境用精简基础镜像。
举个例子，构建一个 Go 应用：
FROM golang:1.21 AS builder WORKDIR /app COPY . . RUN CGO_ENABLED=0 go build -o myapp FROM alpine:3.19 COPY --from=builder /app/myapp /usr/local/bin/myapp ENTRYPOINT ["myapp"]最终镜像里只有编译好的二进制和我们选定的精简运行时，没有编译工具链、没有源码、没有中间缓存。实际效果是镜像体积从 GB 级别降到几十 MB。Python、Node.js 项目也可以采取类似思路，只不过要额外注意运行时依赖。比如 Python 项目可以在 builder 阶段装好依赖，在运行阶段把site-packages目录整个拷过去，配合虚拟环境路径使用。
4.3 非 root、精简镜像与信号处理
安全加固的一个普遍问题是默认 root 运行。基础镜像里没做特殊设置时，容器内进程默认以 root 身份运行，一旦容器被攻破，攻击者获得的是宿主机 root 对容器内文件系统的控制权。正确做法是创建专用用户：
RUN useradd --create-home appuser USER appuser还有一个容易被忽略的问题：容器内是否存在 PID 1 进程。在 Linux 中，PID 1 进程负责信号处理和回收孤儿进程，如果容器主进程不是 init 类程序，某些信号（比如SIGTERM）可能不会被正确处理，导致容器停止时无法优雅退出。解决方式是在基础镜像中安装tini作为 init 进程，并在 Dockerfile 中设置：
RUN apt-get install -y tini ENTRYPOINT ["/usr/bin/tini", "--"] CMD ["/your/app"]这些细节短时间内看不出区别，但在生产环境做滚动更新和优雅停机时，差距会非常明显。
5. 多容器协作编排：Compose、自定义网络和服务发现
5.1 Compose 三个核心对象：services、networks、volumes
真实项目里几乎不可能只跑一个容器。典型的三层架构是前端、后端、数据库各一个容器，他们之间需要网络互联、共享数据卷、按顺序启动。Docker Compose 是解决"多容器编排"最轻量的方式。
docker-compose.yml的顶层对象主要有三个：services定义容器，networks定义自定义网络，volumes定义持久化数据卷。一个最小化示例：
services: web: image: nginx:1.25 ports: - "8080:80" networks: - frontend app: build: . environment: - DB_HOST=db networks: - frontend - backend db: image: mysql:8.0 volumes: - db-data:/var/lib/mysql networks: - backend networks: frontend: backend: volumes: db-data:depends_on经常被误当成"等待数据库就绪"，其实它只保证容器启动顺序，不保证依赖服务可访问。数据库启动需要时间，应用容器早启动了照样连接失败。更可靠的处理是在业务代码里做重试，或者在 entrypoint 脚本里循环探测端口。这是我踩过一次之后才明白的坑。
5.2 服务发现与网络隔离：容器之间怎么"互相找人"
当你定义了自定义网络后，compose 会自动为网络配置内置 DNS，容器可以直接通过服务名访问彼此。比如后端服务要访问数据库，只需在连接串里写db:3306，而不是写容器的 IP。
自定义网络还有一个重要价值：网络隔离。上面示例里，web 容器只在frontend网络中，它无法直接访问backend网络里的数据库容器；app 容器同时接入两个网络，成了网络间的桥梁。这种拓扑比把所有容器扔进同一个默认网络安全得多，数据库对前端完全不可见。
要验证容器之间的网络连通性，可以进入容器后用getent hosts db查看解析结果，或者直接用ping测试：
docker exec -it web ping app如果两个服务不在同一个自定义网络里，ping 是根本无法通的。所以排查容器互联问题时，第一件事就是确认它们是不是在同一个网络。
5.3 环境变量与敏感信息：配置管理的取舍
配置管理是多容器项目里的一个隐性难点。Compose 支持environment直接写环境变量，但敏感信息不应该写死在 YAML 文件里。Compose 有两种常用方案：env_file加载外部文件，或者用 Docker 的 secret 机制。
外部环境文件的方式：
services: app: env_file: - .env.env文件里写入DB_PASSWORD=...。注意.env文件需要加入.gitignore，否则密钥会被提交到代码仓库，这是很多人容易忽略的安全隐患。
对于 Docker 内置的 secret 机制，可以在服务启动时将宿主机的某个文件挂载到容器内/run/secrets/目录：
services: app: secrets: - db_password secrets: db_password: file: ./secrets/db_password.txt应用读取/run/secrets/db_password文件即可获取密码。相比 environment 变量，secret 文件更不容易被docker inspect暴露。简单项目用 env_file 足够，但对敏感程度较高的场景，我建议一开始就养成用 secret 的习惯。
6. 容器不启动/磁盘暴涨/网络不通：三条排查链路复盘
6.1 容器一直重启：先日志再 inspect
容器启动失败或持续重启，是使用 Docker 最高频的故障之一。我的排查顺序固定是：先看状态，再看日志，最后 inspect。
查看容器状态：
docker ps -a --filter "name=web-test"如果状态是Restarting，说明容器主进程不断退出又被策略拉起。此时第一件事就是看日志：
docker logs --tail 100 web-test日志信息往往直接指向原因，比如"port already allocated"，那就是端口冲突；比如 permission denied，大概率是文件权限或服务要 root。如果日志看起来正常但容器还是退出了，常见原因是主进程收到信号后退出，或主进程没有保持前台运行。有些软件包默认以后台 daemon 方式启动，但容器内不能这么跑——必须保持前台进程，否则容器立刻退出。这时候再看一下镜像启动命令是什么格式：
docker inspect web-test --format '{{.Config.Cmd}}'如果启动命令是nginx -g "daemon off;"这种前台形式就正常，如果带-d反而说明被写成了后台方式。
6.2 磁盘空间悄悄涨满：system df 定位三个大块
磁盘被 Docker 占满，是运行一段时间后的常见问题。占用主要来自三块：镜像、容器可写层、数据卷。定位命令是：
docker system df它会列出镜像、容器、本地卷和构建缓存的各自占用。快速清理掉无用对象：
docker system prune -a --volumes-a会删除所有未被容器使用的镜像，--volumes会删除所有未被容器引用的数据卷。执行前务必确认没有重要数据，--volumes的删除是不可恢复的。
如果镜像构建频繁，还要关注构建缓存。查看具体占用可以使用：
docker system df -v这里会按镜像、容器、卷明细列出。有时候缓存占的空间比镜像还大，这是常态，不必慌张，按需清理即可。
6.3 网络不通的逐层探查：从容器内到外界的路径
多容器环境下网络问题的排查思路可以总结为"由内而外逐层确认"。先确认容器内自身网络是否正常：
docker exec -it app ip addr docker exec -it app ping 8.8.8.8如果 ping 不通外网 IP，说明容器没有默认路由或外网访问被限制。再试 DNS：
docker exec -it app nslookup example.com如果 IP 能通但域名解析失败，一般是宿主机 DNS 配置问题，可以在docker run时加--dns参数指定 DNS 服务器。如果只是容器之间不通，先确认它们是否在同一自定义网络：
docker network inspect my-network查看该网络下有哪些容器。大部分跨容器访问问题，根因都是：两个服务被放在了不同网络里、服务名写错、端口没监听。最后一招是抓包确认，容器内可以临时安装 tcpdump，但一来要重新构建镜像，二来会增加排查复杂度，所以我会把抓包作为最后手段而非首选。
7. 进阶加固：资源配额、安全加固与性能观测的落地姿势
7.1 给容器"定规矩"：CPU、内存、文件描述符与进程数
容器虽然共享宿主机资源，但不做限制时，某个容器可以吃满全部 CPU 和内存，拖垮其他服务。给容器设资源上限应该成为习惯，而不是等到出故障再处理。
内存限制：
docker run -d --memory=512m --memory-swap=512m my-app--memory-swap设置为和内存一致，表示不分配 swap，禁止内存超卖。CPU 限制相对灵活：
docker run -d --cpus=1.5 --cpu-shares=512 my-app--cpus限制容器最多使用 1.5 个核心，--cpu-shares是相对权重，低负载环境下不用太严格限制，但都建议设置。还有一个容易被忽略的参数是--pids-limit：
docker run -d --pids-limit=100 my-app它限制容器内最多可创建的进程数，防止某个失控进程 fork 炸弹拖垮宿主机。生产环境里，我会给所有容器都加内存和 PIDs 限制，CPU 限额则视业务是否敏感而定。
7.2 最小权限原则：只读根文件系统与丢弃内核能力
安全加固最被低估的两个参数是--read-only和--cap-drop。
docker run -d --read-only --tmpfs /tmp --cap-drop=ALL my-app--read-only让容器的根文件系统变成只读，无法写入任何文件，需要写临时数据时通过--tmpfs挂一个内存盘到/tmp。如果应用确认不需要任何内核权限，--cap-drop=ALL可以直接丢弃全部 Linux Capabilities，大幅降低容器被提权攻击的风险。需要网络端口时再单独加--cap-add=NET_BIND_SERVICE。
你可能会问：都只读了，应用还能跑吗？实际上大多数后台服务完全不依赖本地写文件，日志和临时数据走 stdout、tmpfs、外部存储即可。先把应用改成无状态，再上只读，安全等级会高一个量级。
7.3 观测不是玄学：docker stats、进程视图与日志策略
性能观测最常用的命令是docker stats，它相当于容器级的top：
docker stats --no-stream不加--no-stream会持续刷新，适合长时间观察；加参数只输出当前快照，适合截图分析。想看容器内进程的 CPU 和内存占比，可以进容器执行ps aux或者直接：
docker top my-app日志策略也是运维中必须考虑的问题。Docker 默认用 json-file 日志驱动，默认不限制大小，长时间运行的容器日志文件会无限增长，最终打满磁盘。合理的做法是在 daemon 配置中统一限制：
{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }重启 Docker 后生效。max-size=10m表示每个日志文件最大 10MB，max-file=3表示最多保留 3 个轮转文件。这个配置对单个容器可用--log-opt临时覆盖，但往往在 daemon.json 里统一设置有更好的一致性。
关于日志这方面我个人的习惯是：应用日志一律输出到 stdout，容器内不写日志文件。这样docker logs能看到所有日志，日志轮转交给 Docker 统一管理，重新部署时也不会遗留历史日志在镜像或数据卷里。
从入门到进阶，Docker 其实就三件事：理解镜像和容器代表的环境一致性，掌握 Dockerfile 和 Compose 将服务组装起来，最后用网络、存储、资源限制和安全配置让它真正能扛住生产环境。这套知识框架建立起来之后，再看 K8s、Serverless 这些更上层的技术，你会发现很多概念都是 Docker 思想在不同层次的延伸，越往后走越能体会到容器生态的巧妙之处。
