Docker镜像体积太大，真正有效的瘦身思路 Docker镜像变大，一般不是某个单点问题，而是构建习惯、基础镜像、依赖管理、缓存文件、编译产物一起堆出来的。实际使用中发现，很多业务镜像从2GB压到300MB，并不是靠什么复杂工具，更多是把构建过程拆清楚：运行时到底需要什么，不需要什么。 镜像体积大带来的问题很直接。CI/CD拉取慢，节点扩容慢，Kubernetes滚动发布慢，跨地域分发更慢。尤其是

Docker跑多个PHP项目，共享一个MySQL容器，连接池到底够不够用 多个PHP项目放在同一台Docker宿主机上，MySQL也跑一个容器，这种部署在中小业务里很常见。比如一个官网、一个后台、几个API服务、一个定时任务项目，全都通过Docker network访问同一个mysql:8.0容器。刚开始访问量不大，看起来没问题；业务跑一段时间后，偶尔出现Too many connections、

Docker跨主机容器通信，Overlay和打通物理网络的差距到底在哪 容器跨主机通信这件事，很多人一开始会直接上 Docker Overlay，原因很简单：配置快，节点加进去就能跑，Swarm、Kubernetes 里也都有成熟实现。真正跑到线上，尤其是东西向流量比较大的业务，才会开始关心一个问题：Overlay 到底比直接打通物理网络慢多少。 这里说的 Overlay，典型就是 VXLAN，把

Docker网络模式怎么选才不影响性能 Docker网络模式选错，性能问题通常不是一上来就爆。更常见的情况是：压测看着还行，业务跑一段时间后，连接数上来了，iptables规则多了，conntrack表开始抖，延迟偶发尖刺，排查时又很容易把锅甩给应用、数据库或者公网线路。 实际使用中发现，Docker网络性能主要卡在三个位置：NAT、conntrack、跨主机封装。CPU不是唯一指标，包量、连接数

Docker 网络模式 host 和 bridge 在服务器上怎么选 Docker 在服务器上跑业务，网络模式最常见就是 bridge 和 host。很多线上问题不是容器本身的问题，而是网络模式选错后带来的排查成本，比如端口映射绕了一层、源 IP 丢了、iptables 规则被改乱、UDP 转发抖动、监控里看不到真实连接来源。 实际使用中发现，bridge 更像是“标准容器玩法”，隔离清楚、可控性

Docker磁盘占用越来越大怎么清理 Docker跑久了，磁盘变大是很正常的事。镜像一层层叠，容器日志一直写，CI/CD频繁构建还会留下 build cache，业务容器如果挂了 volume，数据也会越积越多。实际使用中发现，很多机器不是业务数据把盘打满，而是 Docker 自己的缓存、日志、旧镜像把系统盘吃完。 先别急着删 /var/lib/docker，尤其不要直接 rm -rf overl

Docker 服务器内存占用太高，先别急着加机器 线上 Docker 主机内存打满，很多时候不是业务真的需要那么多内存，而是容器限制没做、日志没管、缓存没看清、JVM/Node.js 这类运行时参数没调，最后表现出来就是 free -h 一看 available 很低，监控一直报警。 实际使用中发现，Docker 内存问题最容易误判。Linux 会把空闲内存拿去做 page cache，看起来 u

Docker容器重启宿主机后数据丢了，问题通常不在“重启”本身 线上经常能遇到这种情况：Docker容器跑得好好的，应用也能写文件，宿主机一重启，容器重新拉起来之后发现数据没了。MySQL库空了，Redis持久化文件不见了，上传目录没了，甚至Nginx配置也回到了镜像里的默认状态。 这个问题表面看像是“Docker不可靠”，实际多数是容器数据没有做持久化。容器里的文件系统默认是跟容器生命周期绑定的

Docker容器部署后端服务，坑往往不在Docker命令本身 后端服务容器化之后，表面看是把jar包、Node进程、Go二进制文件塞进镜像，再用docker run或者docker compose拉起来。实际使用中发现，真正出问题的地方通常不是“容器能不能启动”，而是网络、文件、时区、日志、资源限制、发布回滚这些细节。 容器启动成功，不代表服务可用；服务端口监听了，也不代表链路正常；镜像构建通过了

Docker容器部署后服务器磁盘IO被打满该怎么查 Docker容器上线后，服务器突然变卡，top里CPU不一定高，load average却一路往上飙，接口响应从几十毫秒变成几秒，SSH敲命令都有延迟。这种场景里，很多人第一反应是看CPU和内存，但实际使用中发现，问题经常卡在磁盘IO上。 尤其是把应用从裸机迁到Docker之后，磁盘写入路径变了，日志方式变了，overlay2也参与进来了。以前看