Day 15 Docker Compose入门：一个命令启动全栈应用

guozi

Docker 30天实战系列 · Day 15

你有没有经历过这样的场景：项目需要同时运行数据库、缓存、后端 API、前端应用，每次启动要敲五六条

1. docker run

复制代码

命令，参数一长串，漏一个端口映射整个系统就跑不通？

Docker Compose 就是来终结这种痛苦的。一个 YAML 文件定义所有服务，一条命令全部拉起。

什么是 Docker Compose

Docker Compose 是 Docker 官方提供的多容器编排工具。它的核心思想很简单：用一个

1. docker-compose.yml

复制代码

文件，声明式地描述应用所需的所有服务、网络和存储卷，然后通过

1. docker compose up

复制代码

一键启动整个应用栈。

你可以把它理解为一份"应用部署说明书"。以前这份说明书在你脑子里，现在它变成了一个可版本控制、可复现、可分享的文件。

核心原理

Docker Compose 的工作流程分三步：

第一步：解析。 Compose 读取

1. docker-compose.yml

复制代码

，解析出每个服务的镜像、端口、环境变量、依赖关系等配置。

第二步：构建基础设施。 自动创建一个专属的 bridge 网络（默认以项目目录名为前缀），所有服务加入同一网络。同时创建声明的数据卷。

第三步：按依赖顺序启动容器。 根据

1. depends_on

复制代码

声明的依赖关系，决定启动顺序。每个服务名自动注册为 DNS 名称——在容器内部，你可以直接用服务名当主机名访问其他服务。

这意味着：你再也不需要手动查容器 IP，也不需要

1. --link

复制代码

做容器互联。Compose 内置的 DNS 解析帮你搞定一切。

YAML 配置详解

一个标准的

1. docker-compose.yml

复制代码

长这样：

1. version: "3.8"
3. services:
4.   # 后端 API 服务
5.   backend:
6.     build: ./backend          # 从 Dockerfile 构建
7.     ports:
8.       - "8080:8080"           # 宿主机端口:容器端口
9.     environment:
10.       - DB_HOST=db            # 直接用服务名作为主机名
11.       - DB_PORT=5432
12.       - REDIS_HOST=cache
13.     depends_on:
14.       - db
15.       - cache
16.     restart: unless-stopped
18.   # 前端服务
19.   frontend:
20.     build: ./frontend
21.     ports:
22.       - "3000:3000"
23.     depends_on:
24.       - backend
26.   # PostgreSQL 数据库
27.   db:
28.     image: postgres:16-alpine
29.     environment:
30.       POSTGRES_DB: myapp
31.       POSTGRES_USER: admin
32.       POSTGRES_PASSWORD: secret123
33.     volumes:
34.       - db_data:/var/lib/postgresql/data  # 持久化存储
35.     ports:
36.       - "5432:5432"
38.   # Redis 缓存
39.   cache:
40.     image: redis:7-alpine
41.     ports:
42.       - "6379:6379"
44. volumes:
45.   db_data:                    # 声明命名卷

复制代码

几个关键配置项拆解说明：

| 配置项 | 作用 | 注意事项 |
|--------|------|----------|
|

1. build

复制代码

| 指定 Dockerfile 路径并构建镜像 | 与

1. image

复制代码

二选一，也可同时使用 |
|

1. image

复制代码

| 直接拉取已有镜像 | 指定版本号，避免用

1. latest

复制代码

|
|

1. ports

复制代码

| 端口映射 | 格式为

1. 宿主机:容器

复制代码

，注意端口冲突 |
|

1. volumes

复制代码

| 数据持久化 | 命名卷需要在顶层

1. volumes

复制代码

声明 |
|

1. depends_on

复制代码

| 启动顺序控制 | 只保证启动顺序，不保证服务就绪 |
|

1. environment

复制代码

| 环境变量注入 | 敏感信息建议使用

1. .env

复制代码

文件 |
|

1. restart

复制代码

| 重启策略 | 生产环境推荐

1. unless-stopped

复制代码

|

常用命令速查

掌握以下 8 个命令，日常使用基本够了：

1. # 启动所有服务（后台运行）
2. docker compose up -d
4. # 查看运行状态
5. docker compose ps
7. # 查看日志（实时跟踪）
8. docker compose logs -f backend
10. # 停止所有服务
11. docker compose stop
13. # 停止并删除容器、网络（保留数据卷）
14. docker compose down
16. # 停止并删除一切（包括数据卷）——慎用
17. docker compose down -v
19. # 重新构建镜像并启动
20. docker compose up -d --build
22. # 进入某个服务的容器
23. docker compose exec backend sh

复制代码

实战案例：全栈博客系统

假设我们要搭建一个博客系统：React 前端 + Node.js API + MongoDB 数据库 + Nginx 反向代理。

1. version: "3.8"
3. services:
4.   nginx:
5.     image: nginx:alpine
6.     ports:
7.       - "80:80"
8.     volumes:
9.       - ./nginx/default.conf:/etc/nginx/conf.d/default.conf
10.     depends_on:
11.       - frontend
12.       - api
14.   frontend:
15.     build: ./frontend
16.     expose:
17.       - "3000"               # 只在内部网络暴露，不映射到宿主机
19.   api:
20.     build: ./api
21.     expose:
22.       - "4000"
23.     environment:
24.       - MONGO_URI=mongodb://mongo:27017/blog
25.     depends_on:
26.       - mongo
28.   mongo:
29.     image: mongo:7
30.     volumes:
31.       - mongo_data:/data/db
32.     # 不映射端口到宿主机，只允许内部访问——更安全
34. volumes:
35.   mongo_data:

复制代码

这个配置有三个设计要点值得注意：

第一，Nginx 统一入口。 所有外部流量只通过 80 端口进入，由 Nginx 分发到前端或 API，减少暴露面。

第二，

1. expose

复制代码

代替

1. ports

复制代码

。 前端和 API 使用

1. expose

复制代码

仅在 Compose 内部网络可达，外部无法直接访问。

第三，数据库不暴露端口。 MongoDB 没有映射到宿主机，只有同网络的 API 服务能连接，安全性大幅提升。

环境变量管理

硬编码密码在 YAML 里是大忌。推荐使用

1. .env

复制代码

文件：

1. # .env（必须加入 .gitignore）
2. POSTGRES_PASSWORD=my_secure_password
3. API_SECRET_KEY=a1b2c3d4e5

复制代码

1. # docker-compose.yml 中引用
2. services:
3.   db:
4.     image: postgres:16-alpine
5.     environment:
6.       POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}

复制代码

Compose 会自动读取同目录下的

1. .env

复制代码

文件，将变量注入配置中。

常见问题与排坑

Q1：

1. depends_on

复制代码

设置了，但后端连不上数据库？

1. depends_on

复制代码

只保证容器启动顺序，不保证服务就绪。PostgreSQL 容器启动后还需要几秒初始化。解决方案有两种：在应用代码中加入重连机制（推荐），或使用

1. healthcheck

复制代码

配合

1. depends_on.condition

复制代码

：

1. services:
2.   db:
3.     image: postgres:16-alpine
4.     healthcheck:
5.       test: ["CMD-SHELL", "pg_isready -U admin"]
6.       interval: 5s
7.       timeout: 3s
8.       retries: 5
10.   backend:
11.     depends_on:
12.       db:
13.         condition: service_healthy

复制代码

Q2：修改了代码，

1. docker compose up -d

复制代码

没生效？

Compose 会复用已有镜像。代码变更后需要重新构建：

1. docker compose up -d --build

复制代码

。

Q3：数据怎么没了？

如果你用了

1. docker compose down -v

复制代码

，数据卷会被一起删除。日常停止服务用

1. docker compose stop

复制代码

或

1. docker compose down

复制代码

（不带

1. -v

复制代码

）。

Q4：多个项目端口冲突怎么办？

两个项目都映射了

1. 5432:5432

复制代码

就会冲突。解决方法：修改宿主机端口（如

1. 5433:5432

复制代码

），或者不映射到宿主机——只要同一 Compose 网络内的服务能互相访问就够了。

Compose 与生产环境

Docker Compose 非常适合以下场景：本地开发、CI/CD 测试环境、个人或小团队的单机部署。

但它不适合大规模生产环境。原因很直接：Compose 只能管理单台主机上的容器，没有跨节点调度、自动扩缩容、滚动更新等能力。当你需要管理多台服务器上的容器集群时，应该考虑 Kubernetes 或 Docker Swarm。

一个务实的路径是：用 Compose 把开发环境跑通，验证架构可行性，再迁移到 K8s 做生产编排。 两者的 YAML 配置思路相通，迁移成本并不高。

小结

Docker Compose 的价值可以用一句话概括：把"一堆容器的启动方式"变成"一个可版本管理的配置文件"。

你需要记住的核心操作就三步：写好

1. docker-compose.yml

复制代码

，执行

1. docker compose up -d

复制代码

，然后专注于写业务代码。

明天 Day 16，我们聊 Docker 网络模型——理解了网络，你才能真正掌控容器之间的通信。

━━━━━━━━━━━━━━━━━━━━

如果这篇文章对你有帮助，欢迎点赞、在看、转发，这是我持续更新的最大动力。