22 篇博文 含有标签「DevOps」

Docker 在 2021 年已经不再只是“服务器上部署用一下”了，越来越多团队开始把它往本地开发环境里推进。尤其是 Node.js 项目一旦依赖 Redis、MongoDB、MySQL 这些组件，大家机器上的环境差异会很快变成协作成本。

Docker 用到一定阶段后，几乎都会碰到一个问题：容器里的数据到底是保存在 volume，还是直接绑定宿主机目录。这个选择看起来像是命令层面的细节，实际上很影响本地开发效率。因为它决定了你改代码是否能实时生效、数据库数据是否好迁移、环境重建时会不会把重要内容一起清掉。

很多人第一次写 Dockerfile 时，只关心“能不能构建成功”。等到项目稍微变大一点，就会开始抱怨镜像构建太慢。这个时候常见的反应是去找加速源、换基础镜像、甚至怀疑 Docker 本身不稳定。但经验告诉我，真正拖慢本地构建速度的，很多时候不是网络，而是你自己把缓存层次和构建上下文写得太随意了。

很多人刚在 Mac 上装好 Docker Desktop，第一反应都是先拉镜像、起容器、跑服务。等到容器越来越多，才开始发现编译慢、数据库启动慢、桌面风扇狂转、系统内存被吃掉一大块。这个时候再怀疑镜像源、怀疑命令写法，往往已经偏题了。对 Mac 环境来说，资源限制配置本身就是本地开发体验的一部分。

很多人第一次排查 Docker 容器问题，都会先看日志。这一步当然没错，但如果只停在日志层，很容易卡住。因为容器问题经常不是单点故障，它可能同时涉及启动参数、挂载路径、网络配置、环境变量以及容器内部运行状态。

第一次写 Dockerfile 时，很容易把它理解成“按步骤把环境搭起来”就好。
可 2017 年我在反复构建 Node 项目镜像时，越来越明显地感觉到：Dockerfile 里的 COPY 顺序不只是可读性问题，它会直接决定构建缓存是不是容易失效。

现在大家一提 Docker 镜像优化，很容易先想到多阶段构建。但 2017 年那会儿，很多团队日常还没有把这套玩法完全用顺。想让镜像体积别太夸张，往往还是靠一些更基础、也更朴素的习惯。