Docker Compose 本地开发环境编排

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

这时候 Docker Compose 的价值就很直接: 把一组开发依赖收成一份团队共识。

Compose 解决的不是“能不能启动”，而是“能不能统一”

本地环境最常见的问题不是组件装不上，而是每个人装出来都不一样：

• 端口占用不同
• 数据库版本不同
• 初始化方式不同
• 某些环境变量忘了配

Compose 的意义，就是把这些差异收进一份可执行配置里。

version: '3.8'

services:
  api:
    build: .
    ports:
      - '3000:3000'
    environment:
      NODE_ENV: development
      REDIS_HOST: redis
      MONGO_URL: mongodb://mongo:27017/blog
    depends_on:
      - redis
      - mongo

  redis:
    image: redis:6
    ports:
      - '6379:6379'

  mongo:
    image: mongo:4.4
    ports:
      - '27017:27017'

对 Node.js 项目尤其友好的地方

Node.js 服务很多时候是轻业务层，真正复杂的是依赖项。把 Redis、Mongo、消息队列这类外围服务编排起来，本地开发体验会稳定很多。

我觉得 Compose 最适合的场景包括：

• 新同学快速拉起项目
• 多服务本地联调
• 模拟接近线上的一组依赖环境

不要一开始就把 Compose 写成生产编排

很多人刚接触时会把本地 Compose 配得过于复杂，试图一步到位模拟生产。其实没必要。

本地开发版本更应该关注：

• 能快速启动
• 配置足够透明
• 数据可重置

只要满足这三点，它就是合格的。

一个很实用的约定

我建议把下面几类信息明确下来：

• 对外暴露哪些端口
• 哪些卷需要持久化
• 哪些变量必须走 .env

这会让整个团队后续少很多“我本地可以、你本地不行”的沟通成本。

小结

Docker Compose 对 2021 年的 Node.js 团队来说，很像一块工程化地基。它不一定最炫，但特别实用。把本地依赖环境收成一套标准后，协作效率会提升得很明显。