Docker 工程化实践系列 · 第 6 篇引言一个后端项目从来不止一个服务前面五篇文章我们构建和优化的都是一个独立的 Fastify API 容器。但在真实的后端项目中你的架构大概率是这样的Nginx反向代理 │ Fastify API / \ PostgreSQL Redis即使只是一个中等复杂度的项目也至少涉及 API 服务、数据库和缓存三个组件。如果手动管理这些容器你需要执行dockerrun-d--namepostgres-ePOSTGRES_PASSWORD...-vpostgres-data:/var/lib/postgresql/data postgres:17dockerrun-d--nameredis redis:8dockerrun-d--nameapi-p3000:3000-eDATABASE_URL...-eREDIS_HOST...--linkpostgres--linkredis fastify-apidockerrun-d--namenginx-p80:80 nginx每次启动都要记住一长串参数服务之间的网络连通需要手动配置环境变量散落在各处新人入职想跑起项目得先背诵这些命令。Docker Compose 正是为解决这个问题而生的——用一个声明式 YAML 文件描述整个应用栈然后一条命令启动所有服务。一、Docker Compose 是什么Docker Compose 是 Docker 官方提供的多容器编排工具。核心用法很简单在项目根目录下创建一个docker-compose.yml文件描述项目需要哪些服务、每个服务用什么镜像、端口怎么映射、数据怎么持久化、服务之间怎么通信。之后用docker compose up一键启动所有服务用docker compose down一键停止并清理。一个最简单的 Compose 文件长这样services:api:build:.ports:-3000:3000postgres:image:postgres:17environment:POSTGRES_PASSWORD:passwordvolumes:-postgres-data:/var/lib/postgresql/dataredis:image:redis:8volumes:postgres-data:这个文件定义了三个服务——api、postgres、redis——以及一个数据卷用于持久化数据库文件。不需要记命令参数不需要手动创建网络所有配置都在文件中可以直接提交到 Git 仓库和团队共享。二、Compose 的四个核心概念在讲核心概念前先看一张核心该您总览表1. Service服务Service 是 Compose 中最基本的概念每个 service 对应一个容器。比如上面的例子中定义了 api、postgres、redis 三个 service。对于自定义镜像的服务用build指定 Dockerfile 的位置对于使用官方镜像的服务直接用image指定镜像名称和版本。2. Network网络Compose 默认会创建一个独立的网络所有服务自动加入这个网络。在这个网络内部容器之间可以直接通过服务名互相通信而不需要使用 IP 地址或--link。这意味着你的 Fastify API 可以这样配置数据库连接DATABASE_URLpostgres://postgres:passwordpostgres:5432/app REDIS_HOSTredis注意主机名是postgres和redis——就是 Compose 文件中定义的服务名——而不是localhost。这是很多初学者第一次部署踩坑的地方在容器内部localhost指向容器自己而数据库运行在另一个容器中必须用服务名来访问。Compose 内置的 DNS 会自动将服务名解析为对应容器的内部 IP。3. Volume数据卷默认情况下容器删除后容器内的所有数据都会丢失。对于数据库容器而言这意味着删除 Postgres 容器 → 所有数据消失——这在生产环境中是完全不可接受的。Volume 用于将容器内的目录映射到宿主机上持久化的存储空间postgres:image:postgres:17volumes:-postgres-data:/var/lib/postgresql/data即使容器被删除重建只要 Volume 还在数据就不会丢失。4. Environment环境变量Compose 支持多种方式配置环境变量。可以直接在文件中用environment声明也可以通过env_file引用外部.env文件api:environment:NODE_ENV:productionDATABASE_URL:postgres://postgres:passwordpostgres:5432/app# 或者env_file:-.env推荐把非敏感配置写在 Compose 文件中敏感信息如数据库密码通过外部.env文件注入并确保.env在.gitignore中。三、一个完整的 Fastify PostgreSQL Redis 项目下面是一个接近真实项目的 Compose 配置services:api:build:context:.dockerfile:Dockerfileports:-3000:3000env_file:-.envdepends_on:postgres:condition:service_healthyredis:condition:service_startedpostgres:image:postgres:17env_file:-.envvolumes:-postgres-data:/var/lib/postgresql/datahealthcheck:test:[CMD-SHELL,pg_isready -U ${POSTGRES_USER:-appuser} -d ${POSTGRES_DB:-appdb}]interval:10stimeout:5sretries:5redis:image:redis:8volumes:-redis-data:/datavolumes:postgres-data:redis-data:对应的.env文件POSTGRES_USERappuser POSTGRES_PASSWORDapppassword POSTGRES_DBappdb DATABASE_URLpostgres://appuser:apppasswordpostgres:5432/appdb REDIS_HOSTredis REDIS_PORT6379注意几个细节数据库密码等敏感信息没有直接写在docker-compose.yml中而是通过env_file引用外部.env文件——和第五篇不要把密钥写进镜像的原则保持一致.env文件需要加入.gitignore避免提交到 Git 仓库。几个值得注意的细节。depends_on控制的是服务之间的启动依赖顺序——普通depends_on只保证先启动 Postgres再启动 API但不保证 Postgres 已经准备好接受连接数据库进程启动了不等于初始化完成了。加上condition: service_healthy配合healthcheck才能让 Compose 等待 Postgres 达到 healthy 状态后再启动 API避免 API 启动时连不上数据库。Postgres 服务通过pg_isready命令检测自身是否准备好接受连接这是 Compose 中推荐的等待数据库就绪的方式。四、常用命令# 启动所有服务dockercompose up# 后台运行dockercompose up-d# 后台运行并在代码变更后重新构建 API 镜像dockercompose up-d--build# 查看所有服务运行状态dockercomposeps# 查看所有服务日志dockercompose logs# 只看 API 服务的日志并持续跟踪dockercompose logs-fapi# 进入 API 容器dockercomposeexecapish# 停止所有服务并删除容器和网络保留数据卷dockercompose down# 停止并同时删除数据卷dockercompose down-v其中docker compose down和docker compose down -v的区别非常关键。docker compose down停止并删除所有容器和 Compose 自动创建的网络但保留数据卷——数据库数据不会丢失下次docker compose up时数据还在。docker compose down -v则会在删除容器和网络的同时删除所有声明的 Volume这意味着 Postgres 中的数据库数据、Redis 中的数据都会被清空。在生产环境或任何需要保留数据的场景中使用-v之前一定要确认数据已经备份。如果不确定先用不带-v的命令。看完这个图片你就会对上面的代码更理解了五、Compose 与手动 docker run 的对比维度docker runDocker Compose管理对象单个容器多个服务配置方式命令行参数YAML 文件网络配置手动创建和连接自动创建服务名直连配置复用靠脚本或文档YAML 文件直接共享团队协作新人需背诵命令clone 后一行docker compose up版本控制无法追溯随代码一起进入 Git本质区别在于docker run是命令式的——你告诉 Docker做什么参数散落在命令行中Compose 是声明式的——你告诉 Docker我想要什么状态然后 Docker 去达成它。声明式配置天然更适合团队协作和版本管理。六、总结Docker Compose 让多容器应用的管理从一个手动的、易出错的过程变成了一个可版本控制、可一键启动的配置文件。核心概念只有四个——Service 定义容器、Network 处理通信、Volume 持久化数据、Environment 注入配置——但它们组合起来可以描述任意复杂的应用栈。完成本篇文章后你应该能够做到在项目根目录下放一份docker-compose.yml新成员 clone 代码后只需执行docker compose up就能跑起完整的开发环境——API、数据库、缓存全部就绪。至此Docker 工程化实践系列的Docker 核心能力部分已经完成。我们从理解 Docker 的基本原理出发逐步掌握了镜像分层、Build Cache、多阶段构建、生产镜像优化最后用 Compose 把多个容器编排成一个完整应用。这些知识覆盖了从本地开发到生产部署的完整链路——接下来可以进一步探索 CI/CD 自动构建部署、Kubernetes 容器编排等更高级的工程化实践。上一篇Docker 工程化实践五Docker 镜像优化最佳实践