Docker Compose企业级镜像构建流水线的核心是声明化、可复现与CI集成：通过docker-compose.yml中精细的build配置（如context、dockerfile）、多环境分层文件（dev/prod等）、--build-arg/--no-cache/--pull等参数控制构建行为，并对接Harbor实现构建即推送与安全扫描。
用 Docker Compose 定义企业级镜像构建流水线，核心不是“写一堆脚本”，而是把构建逻辑声明化、可复现、可协同——关键在 docker-compose.yml 中的 build 配置 + 多环境分层 + CI 可集成。
明确服务与构建上下文分离
每个服务对应一个独立构建单元，避免“所有代码塞进一个镜像”。例如 ERP 系统中，后端、前端、数据库初始化脚本应各自构建：
- backend 服务指向 ./backend/Dockerfile，上下文为 ./backend/
- frontend 服务指向 ./frontend/Dockerfile，上下文为 ./frontend/
- db-init 服务可基于官方 mariadb 镜像，仅 COPY 初始化 SQL 并 RUN 执行
这样既符合微服务边界，也便于单服务迭代构建，不触发无关镜像重建。
用 build 参数控制构建行为
docker compose build 不是黑盒命令，它支持精细化干预：
- --build-arg ENV=prod：向 Dockerfile 传递环境变量（如 JDK 版本、配置文件路径）
- --no-cache：生产发布时强制全量重建，规避缓存导致的旧依赖残留
- --pull：确保基础镜像（如 centos:7.9）拉取最新版，修复已知 CVE
- --parallel：多服务并行构建，缩短整体流水线耗时（需宿主机资源充足）
这些参数可直接写入 CI 脚本，比如 Jenkins Pipeline 中：docker compose build --build-arg ENV=prod --no-cache --pull backend frontend。
分环境配置，避免硬编码
开发、测试、生产不应共用同一份 docker-compose.yml。推荐采用多文件组合：
-
docker-compose.yml：定义通用服务结构、网络、卷，不含构建细节 -
docker-compose.dev.yml：启用 build.context + volumes 挂载源码，支持热重载 -
docker-compose.prod.yml：关闭调试端口、启用 --no-cache、设置资源限制（cpus/memory）
启动时按需叠加：docker compose -f docker-compose.yml -f docker-compose.prod.yml build，语义清晰且无冲突。
对接私有仓库，实现构建即推送
构建完成不等于交付完成。企业级流水线必须闭环：
- 在 docker-compose.yml 的 service 下增加
image: harbor.example.com/erp/backend:v2.3.0 - 构建后执行
docker compose push backend，自动推送到私有 Harbor 仓库 - 配合镜像签名和策略扫描（如 Trivy），确保上线镜像通过安全基线
这一步让镜像具备唯一标识、版本追溯、权限管控能力，是 DevOps 流水线可信交付的基石。
