一、什么是Docker Compose？
Docker Compose 是 Docker 官方推出的一个多容器应用编排工具。它的核心作用是帮助开发者通过一个命令，就能启动、停止和管理一组相互关联的Docker容器。
可以把Docker Compose理解成一个“容器乐队指挥”。当你的应用包含多个服务（如前端、后端、数据库、缓存等）时，逐个手动启动和管理它们会非常繁琐。Docker Compose 能让你用一个统一的“乐谱”（即配置文件）来指挥所有“乐手”（即容器）协同工作。
二、为什么需要 Docker Compose？
小白理解：告别繁琐的命令，直接用一个yaml文件就可以一键启动。
三、既然这么方便在绿联上怎么用？
1、进入应用中心，先要安装docker，然后打开docker；
2、选择项目-点击创建；
3、打开文件管理器-共享文件夹-docker-创建项目名称的文件夹，如test；
4、然后把项目的docker compose粘贴到下方compose配置，点击立即部署就会开始，然后如果是勾选了创建完成后立即运行，就会直接启动；
5、基础的Docker compose搭建项目教程就结束了。
四、基础的语法解读
1、挂载路径解析（Volumes）
在 compose.yaml 中，volumes 的写法分为三种类型，路径解析规则如下：
| 写法格式 | 类型 | 路径解析规则 | 示例 |
|---|---|---|---|
相对路径./local:/container |
绑定挂载（Bind Mount） | 相对于 Compose 文件所在目录解析。./data 指项目目录下的 data 文件夹。 |
- ./logs:/var/log/nginx |
绝对路径/home/user/data:/container |
绑定挂载（Bind Mount） | 按 Linux 系统绝对路径解析，Windows 下需改为盘符路径（如 C:/data）。 |
- /mnt/backup:/backup |
命名卷volume_name:/container |
卷挂载（Volume） | 由 Docker 引擎管理，路径存储在 Docker 的专属目录（/var/lib/docker/volumes/），不需要在宿主机手动创建。 |
- db_data:/var/lib/mysql |
匿名卷/container |
卷挂载（Volume） | 只写容器路径，Docker 自动生成随机卷名，一般用于临时存储。 | - /tmp/cache |
关键注意点（易错）：
-
宿主机路径不存在：如果使用相对/绝对路径（绑定挂载），且宿主机目录不存在，Docker 会自动创建该目录（但如果是文件，则会报错）。
-
权限问题：宿主机目录的 UID/GID 会映射到容器内。若容器内进程（如 Nginx 以
www-data用户运行）无权限读写，需确保宿主机目录权限或使用:z/:Z（SELinux）或:c（Windows）标志。 -
只读挂载：在路径末尾加
:ro，容器内将无法修改该目录。- ./config:/app/config:ro
2、重启方法（Restart）
这里需要严格区分 “重启策略”（配置） 和 “手动重启命令”（操作）。
A、重启策略（restart 字段）
写在 Compose 文件中，定义容器异常退出后的行为：
| 策略值 | 行为 |
|---|---|
no |
不自动重启（默认值） |
always |
无论退出码是多少，总是重启。除非手动停止（docker compose stop），否则会无限重启 |
on-failure |
仅当退出码非 0（表示出错）时才重启 |
unless-stopped |
类似于 always，但除非用户手动停止或 Docker 自身被停止，否则始终重启（最常用） |
services:
app:
image: nginx
restart: unless-stoppedB、手动重启命令（操作）
在终端执行，用于立即生效配置变更或重置容器状态：
| 命令 | 作用 | 适用场景 |
|---|---|---|
docker compose restart |
重启所有服务（不重新创建容器，不重新读取镜像变更） | 只想重置进程状态，或修改了环境变量（部分变量需重建才生效） |
docker compose restart web |
仅重启名为 web 的单个服务 |
只调试某个微服务 |
docker compose up -d |
若容器存在则重新创建（如有镜像/配置变更），不存在则创建；若无变化则静默忽略 | 推荐：修改了镜像、Dockerfile、ports、volumes 等配置后使用 |
docker compose down && docker compose up -d |
完全销毁并重建所有容器 | 需要彻底清空网络/卷（不带 -v 不会删命名卷）或遇到缓存问题 |
最佳实践：日常改代码或配置后，直接用
docker compose up -d（它会自动重建变动过的服务），比restart更可靠。
3、镜像（Image）
Docker Compose 中，image 字段的写法决定了从哪里拉取或如何命名：
| 写法示例 | 说明 |
|---|---|
image: nginx:1.25 |
官方镜像，从 Docker Hub 拉取 |
image: myrepo/myapp:latest |
私有仓库镜像（需 docker login） |
image: myapp:v1.0 |
本地已有镜像，或通过 build 构建后生成的标签 |
image: alpine@sha256:abc123... |
使用镜像的 摘要（Digest） 锁定版本，最安全可靠 |
A、与 build 联动（重要）：
如果同时写了 image 和 build：
services:
app:
build: . # 构建上下文
image: myapp:dev # 构建完成后，将此镜像命名为 myapp:dev-
含义：
docker compose build会构建镜像并打上myapp:dev标签。 -
若 只写
build不写image，Compose 会自动生成一个随机镜像名（如project_app）。 -
若 只写
image不写build，直接拉取该镜像。
B、拉取策略（pull_policy）：
-
always：每次都尝试拉取最新镜像。 -
missing：本地没有时才拉取（默认）。 -
never：强制使用本地，存在则用，不存在则报错。
4、环境变量（Environment Variables）
Docker Compose 里有两种截然不同的环境变量，最容易混淆：
A、容器内环境变量（给应用读的）
- 使用
environment或env_file，写入容器的系统环境变量中（如process.env或$_ENV）。
| 写法 | 示例 | 特点 |
|---|---|---|
直接写 environment |
environment: <br> - NODE_ENV=production |
明文写在 yaml 中，适合非敏感配置 |
| 引用本地 Shell 变量 | environment: <br> - PASSWORD=${MY_SECRET} |
取值来自执行 docker compose 时的终端环境变量 |
加载 .env 文件 |
env_file: <br> - .env.production |
从文件中读取大量变量，适合敏感信息（但文件需 .gitignore） |
B、Compose 文件自身的变量替换（给 Compose 读的）
- 在 yaml 文件的 值中 使用
${VARIABLE}，让 Compose 在解析文件时进行文本替换。
services:
db:
image: postgres:${POSTGRES_VERSION} # 替换 Compose 自身的值
ports:
- "${HOST_PORT}:5432"- 这种变量默认从
.env文件（项目根目录）或 当前 Shell 环境 中读取。
C、优先级顺序（由高到低）：
docker compose命令行设置：docker compose run -e VAR=value ...- Shell 环境变量：
export VAR=value && docker compose up - Compose 文件内的
environment字段 env_file指定的文件- 镜像自带的默认环境变量（如
MYSQL_ROOT_PASSWORD默认空）
安全提醒：environment 字段明文显示在 yaml 中，绝对不要写数据库密码等敏感信息。建议使用 env_file + .env（并加入 .gitignore），或使用 Docker Secrets（生产环境）。
5、最终总结
-
挂载：牢记
./是相对项目目录，命名卷不带点；权限不够就改宿主机目录权限。 -
重启：改配置用
up -d（重建），只重置进程用restart。 -
镜像：和
build配合可以打标签；生产环境强烈建议用@sha256锁定版本。 -
环境变量：区分“给容器用的”和“给 Compose 文件用的”，密码千万别写死在
environment里。
