用 Docker 给个人服务器上的服务做隔离：新手最容易踩的三个坑

很多人第一次在自己的服务器上部署服务时，习惯把所有东西直接装在宿主机上：数据库装一个、Web 服务装一个、脚本再塞几个。刚开始确实省事，但时间一长就会发现，卸载卸不干净、版本互相打架、某个服务出问题时很难判断到底是哪一层坏了。Docker 的价值不在于“把命令包起来”，而在于给每个服务划出一块边界清晰、可重建的运行空间。下面结合在 Debian 服务器上长期运行小服务的经验，聊聊新手最容易踩的三个坑。

坑一：把容器当虚拟机用，数据全写在容器层里

容器本身是临时的。镜像更新、容器重建之后，写在容器可写层里的数据会直接消失。正确的做法是把需要长期保存的东西分开：配置文件用只读挂载，数据目录用命名卷或宿主机目录挂载，日志则交给 Docker 的日志驱动或挂到专门目录。

一个实用的判断标准是：删掉这个容器重新 docker run 一次，服务能不能原样回来？如果不能，说明还有状态藏在容器内部，需要把它挪到卷里。这样做之后，升级镜像就变成一件很平常的事：拉新镜像、重建容器、数据还在，失败了还能换回旧镜像。

坑二：端口全部绑到 0.0.0.0，等于把内网服务开到公网

本地调试时图方便，很多人会把数据库、缓存、管理面板的端口全部映射到所有网卡。服务器一旦有公网 IP，这些端口就直接暴露在互联网上，每天都会被扫描。

更稳妥的做法是分清服务的受众：只有真正要对外提供的 Web 服务才绑公网端口；只给本机其他服务用的，绑 127.0.0.1 再通过反向代理统一对外；只在容器网络内部通信的，干脆不做端口映射，让它们通过容器名互相访问。反向代理还可以顺手处理 HTTPS 和统一的访问日志，结构反而更简单。

坑三：不设资源限制，一个服务吃光整台机器

个人服务器配置通常不高，内存可能只有 2GB 到 4GB。如果某个服务出现内存泄漏或突然跑满 CPU，它会拖垮同机所有服务，排查时还很难第一时间定位。

在 docker run 或 Compose 里给每个服务加上 --memory 和 --cpus 限制，并不影响正常运行，却能在出问题时把影响控制在单个容器内。再配合 docker stats 定期看一眼各容器的占用，基本就能提前发现异常增长的服务。对长期运行的服务，还可以配上 restart: unless-stopped 和健康检查，让服务挂掉后能自动恢复，而不是等访问失败了才发现。

小结

Docker 隔离的核心其实只有三件事：状态外置、网络分界、资源设限。把这三点做扎实，个人服务器会从“能跑就行”变成“出问题可定位、升级可回滚、服务互不干扰”的状态。工具本身不复杂，难的是从第一天就养成把边界划清楚的习惯。