Docker Compose核心是通过声明式docker-compose.yml文件实现多容器协同运行：明确服务职责、分离内外网络、显式挂载volume持久化数据、用healthcheck+depends_on保障启动顺序、主动定义网络确保DNS解析与隔离，一条docker compose up即可启动整套环境。
Docker 容器编排管理，核心是用声明式配置代替手动操作，让多个容器像一个整体一样启动、通信、伸缩和恢复。它不是“多开几个 docker run”，而是有结构、有依赖、有网络、有数据持久化的协同运行。
关键不在于命令多，而在于设计清、配置准、启动稳。
用 Docker Compose 做轻量级编排（开发/测试/中小生产场景）
这是最常用、上手最快的方式。一句话：写好 docker-compose.yml，一条命令启动整套服务。
服务定义要明确角色
每个service对应一个职责清晰的组件：比如web（Nginx 或应用前端）、app（后端服务）、db（MySQL）、cache（Redis）。不要把多个进程塞进一个容器。-
端口映射与内部通信分开处理
- 对外暴露用
ports（如80:80），仅限需要被宿主机或外部访问的服务。 - 服务间调用走内部网络，直接用服务名当 hostname（如
app连db:3306），不需要ports也不用127.0.0.1。
- 对外暴露用
-
数据必须持久化，别存在容器里
使用volumes显式声明挂载点：volumes: mysql_data: redis_data: services: db: volumes: - mysql_data:/var/lib/mysql -
控制启动顺序，避免“连接拒绝”错误
单靠depends_on不够（它只等容器启动，不等服务就绪）。正确做法是：- 给数据库加
healthcheck - 在应用服务里用
depends_on+condition: service_healthy
示例：db: image: mysql:8.0 healthcheck: test: ["CMD", "mysqladmin", "ping", "-u", "root", "--password=pass"] interval: 30s timeout: 10s retries: 3 app: depends_on: db: condition: service_healthy
- 给数据库加
网络与隔离要主动规划
默认 Compose 创建的 bridge 网络够用，但建议显式定义：
networks:
app_net:
driver: bridge
ipam:
config:
- subnet: 172.20.0.0/24
然后所有服务都加入这个网络：
Docker Hub
下载
Docker Hub (hub.docker.com)。此技能适用于所有 Docker Hub 操作，包括读取、创建、更新和删除数据。只要任务涉及 Docker Hub，就使用此技能。
services:
web:
networks:
- app_net
app:
networks:
- app_net
好处是：IP 可预测、DNS 自动解析（app 能直接 ping 通 db）、避免和其他项目网络冲突。
启动、调试与日常运维
- 启动整个栈：
docker compose up -d（注意：新版命令是docker compose，不是docker-compose） - 查看日志：
docker compose logs -f app（加-f实时跟踪） - 进入容器调试：
docker compose exec app sh - 重启单个服务：
docker compose restart app - 停止全部：
docker compose down（自动清理网络和临时卷；加-v才删命名卷）
⚠️ 注意：
down不会删你用volumes:声明的命名卷（如mysql_data），但会删匿名卷。数据安全靠的是显式 volume 定义，不是靠“没删掉”。
什么时候该换 Kubernetes？
当出现以下情况之一，说明 Compose 开始力不从心：
- 需要跨多台机器部署（Compose 默认只在单机）
- 要求自动扩缩容（比如按 CPU 使用率增减副本）
- 必须做滚动更新且零停机（
up --scale是硬重启，K8s 支持优雅替换） - 有复杂调度需求（比如某服务必须跑在 SSD 机器上）
中小团队用 Compose 完全能覆盖 80% 场景，不必一上来就上 K8s。
不复杂但容易忽略。
