Docker 用久了很多人会卡在同一个坎上命令敲得挺溜run、build、push一条龙都能跑通可一旦遇到镜像体积莫名膨胀、容器删了数据跟着没了、两个容器互相 ping 不通这类问题就开始抓瞎。我自己最早也是这样镜像越拉越多磁盘一天天见红排查半天才发现是分层缓存没清干净数据卷挂载路径写错一个字符跑了一周的测试数据直接蒸发。这些坑说到底都指向三个底层机制镜像分层原理、容器数据卷、网络通信架构。这篇内容就是把这三块掰开揉碎讲清楚从“为什么镜像能复用”到“数据到底存在哪”再到“容器之间怎么说话”每一块都配上能直接抄的操作步骤和我踩过的坑。适合已经会用 Docker 基本命令、想搞懂底层逻辑的开发者也适合被镜像体积和数据持久化折腾过的运维同学。看完你至少能做到看懂docker history每一层在干什么、设计出合理的卷挂载方案、独立排查容器网络不通的问题。1. 镜像分层原理为什么一个镜像能“共享”出几百个容器1.1 从一次镜像体积异常说起先说个真实场景。某次构建一个 Java 服务镜像Dockerfile 里就几行基础镜像、拷贝 jar 包、启动命令。结果docker images一看镜像 1.2GB。基础镜像本身才 400MBjar 包 80MB剩下 700MB 从哪来的跑docker history一看发现构建过程中把整个源码目录COPY . .拷进去了里面还带着target/、.git/、node_modules/一堆垃圾。更关键的是这些垃圾被打进了独立的一层即使后面用RUN rm -rf删掉镜像体积也不会变小——因为删除操作只是在新的一层里打了个“白障”标记底层的数据依然躺在那里。这就是不理解分层原理最典型的代价。要搞明白这件事得先接受一个核心认知Docker 镜像不是一个大文件而是一摞只读层的叠加。1.2 分层到底是怎么“叠”出来的镜像的每一层本质上是一次文件系统变更的记录。你在 Dockerfile 里写一条RUN、一条COPY、一条ADD构建时就会生成一层。每一层只记录“相对于上一层我新增、修改、删除了哪些文件”而不是完整拷贝整个文件系统。打个生活化的比方把镜像想象成一摞透明玻璃板最底下是操作系统的基础层往上每加一块板子就在上面画点新东西。所有板子叠在一起从正上方看就是最终看到的完整文件系统。容器启动时Docker 在这摞玻璃板最上面再盖一块可写玻璃板可写层容器里所有的写操作都落在这块最上面的板子上下面的只读板子纹丝不动。这个机制带来两个直接好处。第一是存储复用如果你本地有 10 个镜像都基于同一个ubuntu:22.04基础层那这个基础层在磁盘上只存一份10 个镜像共享它。第二是拉取加速docker pull时如果本地已经有某些层只会下载缺失的层这也是为什么第二次拉同系列镜像往往快得多。用命令验证一下最直观# 查看镜像的层信息 docker history --no-trunc nginx:latest # 查看镜像每层的实际大小 docker image inspect nginx:latest --format {{json .RootFS.Layers}}docker history输出的SIZE列就是每层占用的空间CREATED BY列能看到这一层是由哪条指令产生的。注意--no-trunc参数不加的话长命令会被截断成省略号排查问题时根本看不清。1.3 写时复制容器写文件时到底发生了什么理解了只读层还得理解写时复制Copy-on-WriteCoW。容器里的进程要修改一个位于只读层的文件时Docker 不会去动底层而是把这个文件先复制到最上面的可写层然后在可写层里改。原文件在只读层里保持不变。这个设计的意义在于同一个镜像启动 100 个容器底层只读层只有一份每个容器只多出自己可写层的增量。所以容器启动能做到秒级——不需要复制整个镜像只需要挂一块空的可写层上去。但 CoW 也有代价。第一次修改大文件时复制动作本身是有开销的频繁写大文件比如数据库数据文件时可写层会迅速膨胀。这就引出了后面数据卷的必要性——数据卷绕过了 CoW 机制直接挂载宿主机目录读写不经过可写层。1.4 构建缓存分层带来的双刃剑分层机制在构建时体现为缓存。Docker 构建镜像时每条指令执行前会检查之前是否构建过完全相同的层如果命中缓存直接复用跳过执行。判断依据是“指令内容 父层 ID”父层一变后面所有层的缓存全部失效。这就解释了一个常见困惑为什么我只改了 Dockerfile 最后一行整个构建却从头跑了一遍因为你在前面某行改了东西导致那一层 ID 变了它之后的所有层父 ID 都跟着变缓存自然全废。所以 Dockerfile 的指令顺序是有讲究的。把变化频率低的指令放前面变化频率高的放后面。典型反例# 反例每次改代码都会让依赖安装层缓存失效 COPY . /app RUN pip install -r /app/requirements.txt正确写法是先拷依赖清单、装依赖再拷源码# 正例依赖不变时pip install 层始终命中缓存 COPY requirements.txt /app/ RUN pip install -r /app/requirements.txt COPY . /app/这样只要requirements.txt没动pip install那层就一直复用改业务代码只重新构建最后的拷贝层构建时间能从几分钟降到几秒。1.5 镜像瘦身的三条实操路径基于分层原理镜像瘦身有明确的操作方向我按效果从大到小排第一条多阶段构建把构建工具留在构建阶段。编译型语言尤其明显。Go 项目编译需要完整的 SDK但运行只需要一个二进制文件。多阶段构建让最终镜像只包含运行所需内容# 构建阶段 FROM golang:1.21 AS builder WORKDIR /src COPY . . RUN CGO_ENABLED0 go build -o /out/app . # 运行阶段只拷二进制不带 SDK FROM alpine:3.19 COPY --frombuilder /out/app /app CMD [/app]最终镜像从 800MB 级别降到 20MB 级别效果立竿见影。第二条合并 RUN 指令减少层数并清理临时文件。关键点是清理动作必须和产生垃圾的动作在同一条 RUN 里否则清理无效# 错误分两条 RUNapt 缓存留在上一层删不掉 RUN apt-get update apt-get install -y curl RUN rm -rf /var/lib/apt/lists/* # 正确同一条 RUN 内完成安装和清理 RUN apt-get update apt-get install -y curl \ rm -rf /var/lib/apt/lists/*第三条用.dockerignore挡住不该进镜像的文件。这是最容易被忽略、性价比最高的一招。在项目根目录建.dockerignore把.git、node_modules、target、日志、测试数据全挡在外面。COPY . .时这些文件根本不会进入构建上下文既减小镜像又加快构建。注意.dockerignore只影响构建上下文不影响已经构建好的镜像。改完要重新构建才生效。另外COPY . .这种写法在团队协作里风险很高建议尽量显式列出要拷贝的目录。1.6 分层排查的常用命令组合遇到镜像体积异常我一般按这个顺序排查命令作用关注点docker history --no-trunc 镜像看每层来源和大小哪层 SIZE 异常大docker image inspect 镜像看镜像元数据RootFS 层数、配置docker run --rm -it 镜像 du -sh /*进容器看目录占用哪个目录最占空间docker build --no-cache -t test .禁用缓存重建排除缓存干扰docker history里如果看到某层CREATED BY是COPY . .且 SIZE 很大基本就是构建上下文没清理干净。如果看到RUN层很大但命令里明明有rm那就是清理没和安装放在同一条 RUN 里。2. 容器数据卷容器删了数据为什么还在2.1 可写层的生命周期陷阱先讲一个我早期踩过的坑。当时跑一个测试数据库容器往里面灌了几万条数据测完觉得容器碍事顺手docker rm -f删了。第二天想接着测重新docker run一个同样的容器数据全没了。原因很简单容器的可写层和容器生命周期绑定容器一删可写层跟着销毁。这就是数据卷存在的根本理由。可写层适合放临时文件、运行时产生的缓存但任何需要跨容器生命周期存活的数据都必须放在数据卷或绑定挂载里。数据库文件、上传的用户文件、日志归档统统属于这一类。2.2 三种挂载方式的选择逻辑Docker 提供三种把数据“放到容器外”的方式选错了会带来一堆麻烦先把区别理清楚方式存储位置管理方典型场景匿名卷Docker 管理的目录Docker临时验证不推荐生产命名卷Docker 管理的目录Docker数据库、需要备份的持久数据绑定挂载宿主机任意路径用户开发时挂源码、挂配置文件匿名卷是VOLUME /data或-v /data不指定名字时自动创建的名字是一串随机哈希删容器时容易忘记清理时间长了docker volume ls里一堆孤儿卷。我一般只在快速验证时用。命名卷是生产环境的首选。用-v mydata:/var/lib/mysql这种形式卷有明确名字生命周期独立于容器删容器不删卷多个容器可以共享同一个卷。备份、迁移都方便。绑定挂载用-v /宿主机/绝对路径:/容器路径直接把宿主机目录映射进去。开发时挂源码最方便改完代码容器里立刻生效不用重新构建镜像。但它依赖宿主机目录结构换台机器路径可能不存在所以生产环境慎用。2.3 命名卷的完整操作流程以 MySQL 为例走一遍命名卷的标准用法# 1. 创建命名卷也可以不手动创建run 时自动建 docker volume create mysql_data # 2. 启动容器挂载命名卷 docker run -d \ --name mysql-test \ -e MYSQL_ROOT_PASSWORDtest123 \ -v mysql_data:/var/lib/mysql \ mysql:8.0 # 3. 查看卷信息确认挂载点 docker volume inspect mysql_data # 4. 删容器卷保留 docker rm -f mysql-test # 5. 用同一个卷启动新容器数据还在 docker run -d \ --name mysql-test2 \ -e MYSQL_ROOT_PASSWORDtest123 \ -v mysql_data:/var/lib/mysql \ mysql:8.0第 3 步的docker volume inspect会输出卷在宿主机上的实际路径通常在/var/lib/docker/volumes/下知道这个路径对备份很有用。第 5 步启动后连进去SELECT一下之前的数据完好无损这就是命名卷的价值。2.4 绑定挂载的权限坑与路径坑绑定挂载有两个高频坑我几乎每次带新人都要讲一遍。第一个是路径必须写绝对路径。-v ./data:/app/data这种相对路径在部分场景下会被当成命名卷处理结果数据跑到 Docker 管理目录里去了你以为挂在当前目录其实完全不是。养成习惯绑定挂载一律写绝对路径。第二个是权限问题。容器内进程以非 root 用户运行时访问绑定挂载的宿主机目录可能没权限。典型报错是Permission denied。原因是宿主机目录的属主 UID 和容器内用户 UID 对不上。解决办法有两个一是启动时用--user $(id -u):$(id -g)让容器用户和宿主机当前用户 UID 一致二是提前把宿主机目录权限调好。开发环境我一般用前者省事。注意绑定挂载会覆盖容器内目标路径原有的内容。如果你挂载一个空目录到/app而镜像里/app本来有代码挂载后代码就“看不见”了。这是很多人第一次挂载时“程序突然找不到文件”的原因。要么挂到空目录要么先把镜像里的内容拷出来。2.5 数据卷的备份与迁移命名卷的数据要备份标准做法是起一个临时容器把卷挂进去打包成 tar# 备份把 mysql_data 卷打包到当前目录 docker run --rm \ -v mysql_data:/source:ro \ -v $(pwd):/backup \ alpine tar czf /backup/mysql_data_backup.tar.gz -C /source . # 恢复把 tar 解压回卷 docker run --rm \ -v mysql_data:/target \ -v $(pwd):/backup \ alpine tar xzf /backup/mysql_data_backup.tar.gz -C /target这里:ro表示只读挂载备份时防止误写。-v $(pwd):/backup把当前目录挂进临时容器作为输出位置。这个套路适用于任何命名卷换成别的卷名和路径即可。迁移到另一台机器时把 tar 文件传过去在目标机器上先docker volume create建同名卷再执行恢复命令。注意卷名要一致否则容器配置里的挂载路径对不上。2.6 卷的清理与孤儿卷治理跑久了docker volume ls会积累一堆dangling状态的孤儿卷。清理命令# 查看未被任何容器使用的卷 docker volume ls -f danglingtrue # 清理所有未使用的卷谨慎确认没有要保留的数据 docker volume prunedocker volume prune是不可逆的执行前一定确认那些卷里没有还要用的数据。我的习惯是每月清一次清理前先ls -f danglingtrue看一眼有拿不准的就先inspect确认用途再决定。3. 网络通信架构容器之间到底怎么“说话”3.1 默认桥接网络的两个硬伤docker run不指定网络时容器默认接入bridge网络。这个默认网络有两个让人抓狂的问题。第一容器之间只能用 IP 互访不能用容器名。默认 bridge 网络不提供自动 DNS 解析你ping另一个容器的名字是 ping 不通的只能docker inspect查到 IP 再连。IP 在容器重启后还可能变写死在配置里迟早出事。第二默认 bridge 上的容器和宿主机网络隔离较严。宿主机访问容器要靠端口映射-p容器访问宿主机要走特殊地址。这套机制在单容器场景够用多容器协作就很别扭。所以只要涉及两个以上容器互相通信第一件事就是自建一个用户自定义 bridge 网络。自定义网络自带 DNS 解析容器之间直接用容器名互访这是 Docker 网络最实用的一条经验。3.2 自定义网络的搭建与验证# 1. 创建自定义 bridge 网络 docker network create mynet # 2. 启动两个容器接入同一网络 docker run -d --name web --network mynet nginx:alpine docker run -d --name client --network mynet alpine sleep 3600 # 3. 在 client 里用容器名访问 web docker exec client ping -c 2 web docker exec client wget -qO- http://web第 3 步能 ping 通、能拿到 nginx 默认页说明 DNS 解析和网络连通都正常。这套“自建网络 容器名互访”的模式是绝大多数多容器应用的基础比维护 IP 映射省心太多。3.3 端口映射的底层逻辑-p 8080:80这行参数左边是宿主机端口右边是容器端口中间是映射关系。它的底层是宿主机的 iptables 规则在做转发外部请求打到宿主机 8080被转发到容器的 80。几个容易混淆的点-p 80只写一个端口宿主机随机分配一个高位端口映射到容器 80用docker port查实际映射。-p 127.0.0.1:8080:80限定只监听宿主机本地回环外部访问不到适合只给本机用的服务。多个容器映射同一个宿主机端口会冲突报port is already allocated换端口或先停掉占用的容器。排查端口问题时docker port 容器名看映射关系ss -tlnp | grep 端口看宿主机端口实际被谁占用两步基本能定位。3.4 容器访问宿主机的正确姿势容器里访问宿主机服务不同平台地址不一样。Linux 上宿主机在容器视角的地址通常是172.17.0.1默认 bridge 的网关但更稳妥的做法是启动时加--add-hosthost.docker.internal:host-gateway然后用host.docker.internal这个域名访问。这样不依赖具体网关 IP换环境也不用改配置。docker run --rm -it \ --add-hosthost.docker.internal:host-gateway \ alpine sh -c ping -c 2 host.docker.internal这个参数在需要容器连宿主机上的数据库、缓存服务时特别有用比硬编码 IP 可靠得多。3.5 网络排查的四步定位法容器网络不通我按这个顺序排查基本四步内能定位第一步确认容器在哪个网络。docker inspect 容器 --format {{json .NetworkSettings.Networks}}看它接入的网络名和分配的 IP。第二步确认目标容器是否在同一网络。不在同一网络的两个容器除非走宿主机端口映射否则默认不通。这是最常见的“ping 不通”原因。第三步容器内测试 DNS 和连通性。docker exec 容器 ping 目标容器名能解析出 IP 说明 DNS 正常ping 不通说明网络层有问题解析失败说明不在同一自定义网络。第四步看宿主机防火墙和 iptables。如果容器间通但外部访问不通检查宿主机防火墙是否放行了映射端口iptables -L -n看转发规则是否正常。现象可能原因排查命令容器名 ping 不通不在同一自定义网络docker network inspect外部访问映射端口失败防火墙拦截或端口未映射docker port、ss -tlnp容器访问宿主机失败地址写错或未加 host-gateway--add-host参数检查间歇性连接超时网络拥塞或 DNS 抖动docker exec ... nslookup3.6 多容器协作的网络设计建议实际项目里我倾向于按“功能边界”划分网络。比如一个 Web 应用拆成前端、后端、数据库三层前端和后端放一个网络后端和数据库放另一个网络数据库不直接暴露给前端网络。这样即使前端容器被攻破也摸不到数据库。Docker 允许一个容器接入多个网络用docker network connect动态添加docker network connect dbnet backend这种“按层隔离”的设计比所有容器挤在一个大网络里安全得多排查问题时边界也清晰。代价是要多维护几个网络但对稍微复杂点的应用来说完全值得。4. 三个机制串起来看一次完整的排障复盘4.1 问题现场还原把前面三块知识串成一个真实案例。某次部署一个应用现象是容器重启后配置丢失、镜像体积异常大、前端容器连不上后端容器。三个问题分别对应三个机制逐个拆。配置丢失应用把配置文件写在了容器内的/app/config目录没做任何挂载。容器一重启可写层重建配置回到镜像初始状态。这是典型的“数据放错地方”解法是把配置目录挂成命名卷或绑定挂载。镜像体积异常docker history显示某层 600MB来源是COPY . .构建上下文里带了测试数据和依赖缓存。解法是补.dockerignore并把COPY拆成先依赖后源码。前端连不上后端两个容器都跑在默认 bridge 上前端配置里写的是后端容器 IP后端重启后 IP 变了连接自然失败。解法是自建网络前端配置改用后端容器名。4.2 修复方案的落地顺序修复时我按“先网络、再数据、最后镜像”的顺序因为网络问题影响面最大数据问题最怕丢镜像问题可以最后优化。网络部分建自定义网络两个容器重新接入前端配置从 IP 改成容器名重启验证连通。数据部分建命名卷挂到配置目录把当前配置先拷进卷里再重启确认配置持久化。镜像部分补.dockerignore调整 Dockerfile 指令顺序重新构建后docker history确认体积降下来。三步做完三个问题同时消失。这个过程让我意识到很多看似独立的 Docker 故障根子都在对这三个底层机制的理解上——知道数据该放哪、网络该怎么连、镜像层怎么叠大部分问题在设计和部署阶段就能规避。4.3 一份可复用的检查清单我把这套经验整理成部署前的自查清单每次上线前过一遍镜像docker history有没有异常大的层.dockerignore是否覆盖了.git、依赖目录、测试数据数据需要持久化的目录是否都挂了卷挂的是命名卷还是绑定挂载是否符合场景绑定挂载路径是否绝对路径、权限是否对网络多容器是否在同一自定义网络互访是否用容器名而非 IP需要外部访问的端口是否映射、防火墙是否放行清理是否有孤儿卷、悬空镜像需要定期清理这份清单不复杂但能挡住八成以上的常见故障。我自己的体会是Docker 的命令好学难的是建立“数据放哪、网络怎么连、层怎么叠”的底层直觉直觉建立起来之后排查问题就不再是碰运气而是有章法地逐层排除。后面如果还要往下深挖可以研究一下存储驱动的差异overlay2 和 btrfs 在 CoW 上的表现不同以及网络插件的扩展不过那是另一个话题了。 
长河君 · 2026/10/26 19:24:18 · 阅读 1.2k Docker镜像分层、数据卷与网络通信：底层机制解析与实战排障
Docker 用久了很多人会卡在同一个坎上命令敲得挺溜run、build、push一条龙都能跑通可一旦遇到镜像体积莫名膨胀、容器删了数据跟着没了、两个容器互相 ping 不通这类问题就开始抓瞎。我自己最早也是这样镜像越拉越多磁盘一天天见红排查半天才发现是分层缓存没清干净数据卷挂载路径写错一个字符跑了一周的测试数据直接蒸发。这些坑说到底都指向三个底层机制镜像分层原理、容器数据卷、网络通信架构。这篇内容就是把这三块掰开揉碎讲清楚从“为什么镜像能复用”到“数据到底存在哪”再到“容器之间怎么说话”每一块都配上能直接抄的操作步骤和我踩过的坑。适合已经会用 Docker 基本命令、想搞懂底层逻辑的开发者也适合被镜像体积和数据持久化折腾过的运维同学。看完你至少能做到看懂docker history每一层在干什么、设计出合理的卷挂载方案、独立排查容器网络不通的问题。1. 镜像分层原理为什么一个镜像能“共享”出几百个容器1.1 从一次镜像体积异常说起先说个真实场景。某次构建一个 Java 服务镜像Dockerfile 里就几行基础镜像、拷贝 jar 包、启动命令。结果docker images一看镜像 1.2GB。基础镜像本身才 400MBjar 包 80MB剩下 700MB 从哪来的跑docker history一看发现构建过程中把整个源码目录COPY . .拷进去了里面还带着target/、.git/、node_modules/一堆垃圾。更关键的是这些垃圾被打进了独立的一层即使后面用RUN rm -rf删掉镜像体积也不会变小——因为删除操作只是在新的一层里打了个“白障”标记底层的数据依然躺在那里。这就是不理解分层原理最典型的代价。要搞明白这件事得先接受一个核心认知Docker 镜像不是一个大文件而是一摞只读层的叠加。1.2 分层到底是怎么“叠”出来的镜像的每一层本质上是一次文件系统变更的记录。你在 Dockerfile 里写一条RUN、一条COPY、一条ADD构建时就会生成一层。每一层只记录“相对于上一层我新增、修改、删除了哪些文件”而不是完整拷贝整个文件系统。打个生活化的比方把镜像想象成一摞透明玻璃板最底下是操作系统的基础层往上每加一块板子就在上面画点新东西。所有板子叠在一起从正上方看就是最终看到的完整文件系统。容器启动时Docker 在这摞玻璃板最上面再盖一块可写玻璃板可写层容器里所有的写操作都落在这块最上面的板子上下面的只读板子纹丝不动。这个机制带来两个直接好处。第一是存储复用如果你本地有 10 个镜像都基于同一个ubuntu:22.04基础层那这个基础层在磁盘上只存一份10 个镜像共享它。第二是拉取加速docker pull时如果本地已经有某些层只会下载缺失的层这也是为什么第二次拉同系列镜像往往快得多。用命令验证一下最直观# 查看镜像的层信息 docker history --no-trunc nginx:latest # 查看镜像每层的实际大小 docker image inspect nginx:latest --format {{json .RootFS.Layers}}docker history输出的SIZE列就是每层占用的空间CREATED BY列能看到这一层是由哪条指令产生的。注意--no-trunc参数不加的话长命令会被截断成省略号排查问题时根本看不清。1.3 写时复制容器写文件时到底发生了什么理解了只读层还得理解写时复制Copy-on-WriteCoW。容器里的进程要修改一个位于只读层的文件时Docker 不会去动底层而是把这个文件先复制到最上面的可写层然后在可写层里改。原文件在只读层里保持不变。这个设计的意义在于同一个镜像启动 100 个容器底层只读层只有一份每个容器只多出自己可写层的增量。所以容器启动能做到秒级——不需要复制整个镜像只需要挂一块空的可写层上去。但 CoW 也有代价。第一次修改大文件时复制动作本身是有开销的频繁写大文件比如数据库数据文件时可写层会迅速膨胀。这就引出了后面数据卷的必要性——数据卷绕过了 CoW 机制直接挂载宿主机目录读写不经过可写层。1.4 构建缓存分层带来的双刃剑分层机制在构建时体现为缓存。Docker 构建镜像时每条指令执行前会检查之前是否构建过完全相同的层如果命中缓存直接复用跳过执行。判断依据是“指令内容 父层 ID”父层一变后面所有层的缓存全部失效。这就解释了一个常见困惑为什么我只改了 Dockerfile 最后一行整个构建却从头跑了一遍因为你在前面某行改了东西导致那一层 ID 变了它之后的所有层父 ID 都跟着变缓存自然全废。所以 Dockerfile 的指令顺序是有讲究的。把变化频率低的指令放前面变化频率高的放后面。典型反例# 反例每次改代码都会让依赖安装层缓存失效 COPY . /app RUN pip install -r /app/requirements.txt正确写法是先拷依赖清单、装依赖再拷源码# 正例依赖不变时pip install 层始终命中缓存 COPY requirements.txt /app/ RUN pip install -r /app/requirements.txt COPY . /app/这样只要requirements.txt没动pip install那层就一直复用改业务代码只重新构建最后的拷贝层构建时间能从几分钟降到几秒。1.5 镜像瘦身的三条实操路径基于分层原理镜像瘦身有明确的操作方向我按效果从大到小排第一条多阶段构建把构建工具留在构建阶段。编译型语言尤其明显。Go 项目编译需要完整的 SDK但运行只需要一个二进制文件。多阶段构建让最终镜像只包含运行所需内容# 构建阶段 FROM golang:1.21 AS builder WORKDIR /src COPY . . RUN CGO_ENABLED0 go build -o /out/app . # 运行阶段只拷二进制不带 SDK FROM alpine:3.19 COPY --frombuilder /out/app /app CMD [/app]最终镜像从 800MB 级别降到 20MB 级别效果立竿见影。第二条合并 RUN 指令减少层数并清理临时文件。关键点是清理动作必须和产生垃圾的动作在同一条 RUN 里否则清理无效# 错误分两条 RUNapt 缓存留在上一层删不掉 RUN apt-get update apt-get install -y curl RUN rm -rf /var/lib/apt/lists/* # 正确同一条 RUN 内完成安装和清理 RUN apt-get update apt-get install -y curl \ rm -rf /var/lib/apt/lists/*第三条用.dockerignore挡住不该进镜像的文件。这是最容易被忽略、性价比最高的一招。在项目根目录建.dockerignore把.git、node_modules、target、日志、测试数据全挡在外面。COPY . .时这些文件根本不会进入构建上下文既减小镜像又加快构建。注意.dockerignore只影响构建上下文不影响已经构建好的镜像。改完要重新构建才生效。另外COPY . .这种写法在团队协作里风险很高建议尽量显式列出要拷贝的目录。1.6 分层排查的常用命令组合遇到镜像体积异常我一般按这个顺序排查命令作用关注点docker history --no-trunc 镜像看每层来源和大小哪层 SIZE 异常大docker image inspect 镜像看镜像元数据RootFS 层数、配置docker run --rm -it 镜像 du -sh /*进容器看目录占用哪个目录最占空间docker build --no-cache -t test .禁用缓存重建排除缓存干扰docker history里如果看到某层CREATED BY是COPY . .且 SIZE 很大基本就是构建上下文没清理干净。如果看到RUN层很大但命令里明明有rm那就是清理没和安装放在同一条 RUN 里。2. 容器数据卷容器删了数据为什么还在2.1 可写层的生命周期陷阱先讲一个我早期踩过的坑。当时跑一个测试数据库容器往里面灌了几万条数据测完觉得容器碍事顺手docker rm -f删了。第二天想接着测重新docker run一个同样的容器数据全没了。原因很简单容器的可写层和容器生命周期绑定容器一删可写层跟着销毁。这就是数据卷存在的根本理由。可写层适合放临时文件、运行时产生的缓存但任何需要跨容器生命周期存活的数据都必须放在数据卷或绑定挂载里。数据库文件、上传的用户文件、日志归档统统属于这一类。2.2 三种挂载方式的选择逻辑Docker 提供三种把数据“放到容器外”的方式选错了会带来一堆麻烦先把区别理清楚方式存储位置管理方典型场景匿名卷Docker 管理的目录Docker临时验证不推荐生产命名卷Docker 管理的目录Docker数据库、需要备份的持久数据绑定挂载宿主机任意路径用户开发时挂源码、挂配置文件匿名卷是VOLUME /data或-v /data不指定名字时自动创建的名字是一串随机哈希删容器时容易忘记清理时间长了docker volume ls里一堆孤儿卷。我一般只在快速验证时用。命名卷是生产环境的首选。用-v mydata:/var/lib/mysql这种形式卷有明确名字生命周期独立于容器删容器不删卷多个容器可以共享同一个卷。备份、迁移都方便。绑定挂载用-v /宿主机/绝对路径:/容器路径直接把宿主机目录映射进去。开发时挂源码最方便改完代码容器里立刻生效不用重新构建镜像。但它依赖宿主机目录结构换台机器路径可能不存在所以生产环境慎用。2.3 命名卷的完整操作流程以 MySQL 为例走一遍命名卷的标准用法# 1. 创建命名卷也可以不手动创建run 时自动建 docker volume create mysql_data # 2. 启动容器挂载命名卷 docker run -d \ --name mysql-test \ -e MYSQL_ROOT_PASSWORDtest123 \ -v mysql_data:/var/lib/mysql \ mysql:8.0 # 3. 查看卷信息确认挂载点 docker volume inspect mysql_data # 4. 删容器卷保留 docker rm -f mysql-test # 5. 用同一个卷启动新容器数据还在 docker run -d \ --name mysql-test2 \ -e MYSQL_ROOT_PASSWORDtest123 \ -v mysql_data:/var/lib/mysql \ mysql:8.0第 3 步的docker volume inspect会输出卷在宿主机上的实际路径通常在/var/lib/docker/volumes/下知道这个路径对备份很有用。第 5 步启动后连进去SELECT一下之前的数据完好无损这就是命名卷的价值。2.4 绑定挂载的权限坑与路径坑绑定挂载有两个高频坑我几乎每次带新人都要讲一遍。第一个是路径必须写绝对路径。-v ./data:/app/data这种相对路径在部分场景下会被当成命名卷处理结果数据跑到 Docker 管理目录里去了你以为挂在当前目录其实完全不是。养成习惯绑定挂载一律写绝对路径。第二个是权限问题。容器内进程以非 root 用户运行时访问绑定挂载的宿主机目录可能没权限。典型报错是Permission denied。原因是宿主机目录的属主 UID 和容器内用户 UID 对不上。解决办法有两个一是启动时用--user $(id -u):$(id -g)让容器用户和宿主机当前用户 UID 一致二是提前把宿主机目录权限调好。开发环境我一般用前者省事。注意绑定挂载会覆盖容器内目标路径原有的内容。如果你挂载一个空目录到/app而镜像里/app本来有代码挂载后代码就“看不见”了。这是很多人第一次挂载时“程序突然找不到文件”的原因。要么挂到空目录要么先把镜像里的内容拷出来。2.5 数据卷的备份与迁移命名卷的数据要备份标准做法是起一个临时容器把卷挂进去打包成 tar# 备份把 mysql_data 卷打包到当前目录 docker run --rm \ -v mysql_data:/source:ro \ -v $(pwd):/backup \ alpine tar czf /backup/mysql_data_backup.tar.gz -C /source . # 恢复把 tar 解压回卷 docker run --rm \ -v mysql_data:/target \ -v $(pwd):/backup \ alpine tar xzf /backup/mysql_data_backup.tar.gz -C /target这里:ro表示只读挂载备份时防止误写。-v $(pwd):/backup把当前目录挂进临时容器作为输出位置。这个套路适用于任何命名卷换成别的卷名和路径即可。迁移到另一台机器时把 tar 文件传过去在目标机器上先docker volume create建同名卷再执行恢复命令。注意卷名要一致否则容器配置里的挂载路径对不上。2.6 卷的清理与孤儿卷治理跑久了docker volume ls会积累一堆dangling状态的孤儿卷。清理命令# 查看未被任何容器使用的卷 docker volume ls -f danglingtrue # 清理所有未使用的卷谨慎确认没有要保留的数据 docker volume prunedocker volume prune是不可逆的执行前一定确认那些卷里没有还要用的数据。我的习惯是每月清一次清理前先ls -f danglingtrue看一眼有拿不准的就先inspect确认用途再决定。3. 网络通信架构容器之间到底怎么“说话”3.1 默认桥接网络的两个硬伤docker run不指定网络时容器默认接入bridge网络。这个默认网络有两个让人抓狂的问题。第一容器之间只能用 IP 互访不能用容器名。默认 bridge 网络不提供自动 DNS 解析你ping另一个容器的名字是 ping 不通的只能docker inspect查到 IP 再连。IP 在容器重启后还可能变写死在配置里迟早出事。第二默认 bridge 上的容器和宿主机网络隔离较严。宿主机访问容器要靠端口映射-p容器访问宿主机要走特殊地址。这套机制在单容器场景够用多容器协作就很别扭。所以只要涉及两个以上容器互相通信第一件事就是自建一个用户自定义 bridge 网络。自定义网络自带 DNS 解析容器之间直接用容器名互访这是 Docker 网络最实用的一条经验。3.2 自定义网络的搭建与验证# 1. 创建自定义 bridge 网络 docker network create mynet # 2. 启动两个容器接入同一网络 docker run -d --name web --network mynet nginx:alpine docker run -d --name client --network mynet alpine sleep 3600 # 3. 在 client 里用容器名访问 web docker exec client ping -c 2 web docker exec client wget -qO- http://web第 3 步能 ping 通、能拿到 nginx 默认页说明 DNS 解析和网络连通都正常。这套“自建网络 容器名互访”的模式是绝大多数多容器应用的基础比维护 IP 映射省心太多。3.3 端口映射的底层逻辑-p 8080:80这行参数左边是宿主机端口右边是容器端口中间是映射关系。它的底层是宿主机的 iptables 规则在做转发外部请求打到宿主机 8080被转发到容器的 80。几个容易混淆的点-p 80只写一个端口宿主机随机分配一个高位端口映射到容器 80用docker port查实际映射。-p 127.0.0.1:8080:80限定只监听宿主机本地回环外部访问不到适合只给本机用的服务。多个容器映射同一个宿主机端口会冲突报port is already allocated换端口或先停掉占用的容器。排查端口问题时docker port 容器名看映射关系ss -tlnp | grep 端口看宿主机端口实际被谁占用两步基本能定位。3.4 容器访问宿主机的正确姿势容器里访问宿主机服务不同平台地址不一样。Linux 上宿主机在容器视角的地址通常是172.17.0.1默认 bridge 的网关但更稳妥的做法是启动时加--add-hosthost.docker.internal:host-gateway然后用host.docker.internal这个域名访问。这样不依赖具体网关 IP换环境也不用改配置。docker run --rm -it \ --add-hosthost.docker.internal:host-gateway \ alpine sh -c ping -c 2 host.docker.internal这个参数在需要容器连宿主机上的数据库、缓存服务时特别有用比硬编码 IP 可靠得多。3.5 网络排查的四步定位法容器网络不通我按这个顺序排查基本四步内能定位第一步确认容器在哪个网络。docker inspect 容器 --format {{json .NetworkSettings.Networks}}看它接入的网络名和分配的 IP。第二步确认目标容器是否在同一网络。不在同一网络的两个容器除非走宿主机端口映射否则默认不通。这是最常见的“ping 不通”原因。第三步容器内测试 DNS 和连通性。docker exec 容器 ping 目标容器名能解析出 IP 说明 DNS 正常ping 不通说明网络层有问题解析失败说明不在同一自定义网络。第四步看宿主机防火墙和 iptables。如果容器间通但外部访问不通检查宿主机防火墙是否放行了映射端口iptables -L -n看转发规则是否正常。现象可能原因排查命令容器名 ping 不通不在同一自定义网络docker network inspect外部访问映射端口失败防火墙拦截或端口未映射docker port、ss -tlnp容器访问宿主机失败地址写错或未加 host-gateway--add-host参数检查间歇性连接超时网络拥塞或 DNS 抖动docker exec ... nslookup3.6 多容器协作的网络设计建议实际项目里我倾向于按“功能边界”划分网络。比如一个 Web 应用拆成前端、后端、数据库三层前端和后端放一个网络后端和数据库放另一个网络数据库不直接暴露给前端网络。这样即使前端容器被攻破也摸不到数据库。Docker 允许一个容器接入多个网络用docker network connect动态添加docker network connect dbnet backend这种“按层隔离”的设计比所有容器挤在一个大网络里安全得多排查问题时边界也清晰。代价是要多维护几个网络但对稍微复杂点的应用来说完全值得。4. 三个机制串起来看一次完整的排障复盘4.1 问题现场还原把前面三块知识串成一个真实案例。某次部署一个应用现象是容器重启后配置丢失、镜像体积异常大、前端容器连不上后端容器。三个问题分别对应三个机制逐个拆。配置丢失应用把配置文件写在了容器内的/app/config目录没做任何挂载。容器一重启可写层重建配置回到镜像初始状态。这是典型的“数据放错地方”解法是把配置目录挂成命名卷或绑定挂载。镜像体积异常docker history显示某层 600MB来源是COPY . .构建上下文里带了测试数据和依赖缓存。解法是补.dockerignore并把COPY拆成先依赖后源码。前端连不上后端两个容器都跑在默认 bridge 上前端配置里写的是后端容器 IP后端重启后 IP 变了连接自然失败。解法是自建网络前端配置改用后端容器名。4.2 修复方案的落地顺序修复时我按“先网络、再数据、最后镜像”的顺序因为网络问题影响面最大数据问题最怕丢镜像问题可以最后优化。网络部分建自定义网络两个容器重新接入前端配置从 IP 改成容器名重启验证连通。数据部分建命名卷挂到配置目录把当前配置先拷进卷里再重启确认配置持久化。镜像部分补.dockerignore调整 Dockerfile 指令顺序重新构建后docker history确认体积降下来。三步做完三个问题同时消失。这个过程让我意识到很多看似独立的 Docker 故障根子都在对这三个底层机制的理解上——知道数据该放哪、网络该怎么连、镜像层怎么叠大部分问题在设计和部署阶段就能规避。4.3 一份可复用的检查清单我把这套经验整理成部署前的自查清单每次上线前过一遍镜像docker history有没有异常大的层.dockerignore是否覆盖了.git、依赖目录、测试数据数据需要持久化的目录是否都挂了卷挂的是命名卷还是绑定挂载是否符合场景绑定挂载路径是否绝对路径、权限是否对网络多容器是否在同一自定义网络互访是否用容器名而非 IP需要外部访问的端口是否映射、防火墙是否放行清理是否有孤儿卷、悬空镜像需要定期清理这份清单不复杂但能挡住八成以上的常见故障。我自己的体会是Docker 的命令好学难的是建立“数据放哪、网络怎么连、层怎么叠”的底层直觉直觉建立起来之后排查问题就不再是碰运气而是有章法地逐层排除。后面如果还要往下深挖可以研究一下存储驱动的差异overlay2 和 btrfs 在 CoW 上的表现不同以及网络插件的扩展不过那是另一个话题了。