Docker CI/CD集成核心是让构建、测试、部署全程运行在一致容器环境中：通过Docker启动Jenkins（挂载docker.sock和jenkins_home卷），在流水线中用Dockerfile构建带版本标签的镜像，推送至仓库后，按场景选择SSH部署、docker stack或K8s对接，并统一基础镜像、构建参数与.dockerignore确保环境一致性。
把 CI/CD 流水线集成进 Docker 环境，核心不是“加个容器”，而是让构建、测试、部署每个环节都运行在一致、可复现的容器上下文中。关键在于用 Docker 统一环境，再通过触发机制把代码变更自动带入这个闭环。
用容器跑 CI 工具本身（比如 Jenkins）
不推荐在宿主机直接装 Jenkins，容易和系统环境冲突。更稳妥的做法是用 Docker 启动 Jenkins：
- 拉取官方或 LTS 版镜像：
docker run -d -p 8080:8080 -p 50000:50000 -v jenkins_home:/var/jenkins_home -v /var/run/docker.sock:/var/run/docker.sock --name jenkins jenkins/jenkins:lts - 必须挂载宿主机的 docker.sock——否则 Jenkins 容器内部无法调用 docker 命令构建镜像
- 把 Jenkins Home 目录映射为卷，避免重启后配置丢失
- 首次启动后按提示解锁并安装常用插件：Docker Pipeline、Git、Publish Over SSH 等
构建阶段：在流水线里用 Docker 构建应用镜像
别在 Jenkins 节点上手动执行 docker build，而是写进 Jenkinsfile 或 GitHub Actions workflow 中，由 CI 工具调度执行：
- 确保源码根目录下有有效的
Dockerfile，且能独立构建出可运行镜像 - Jenkins Pipeline 示例中，用
sh 'docker build -t myapp:${BUILD_ID} .'构建带版本标签的镜像 - GitHub Actions 可直接用
docker/build-push-action插件，自动缓存、多平台构建、推送到仓库 - 构建过程全程在容器内完成，开发机装什么系统、什么版本 Node/PHP/Java 都不影响结果
推送与部署：镜像落地到目标环境
构建完只是第一步，得让镜像真正跑起来：
- 推送前先登录镜像仓库：
docker login -u $DOCKER_USER -p $DOCKER_PASS（凭据建议用 Jenkins 凭据管理或 GitHub Secrets） - 推送到 Docker Hub 或私有仓库（如 Harbor），供生产服务器拉取
- 部署方式按场景选：
- 单机简单服务：SSH 连上目标机，执行
docker pull && docker stop && docker run - 编排场景：用
docker stack deploy或docker-compose up -d更新服务 - 对接 Swarm/K8s：生成对应 manifest，用 kubectl 或 docker stack apply 推送
- 单机简单服务：SSH 连上目标机，执行
保持环境一致性：CI 和运行时用同一套镜像逻辑
很多问题出在“CI 里构建的镜像，上线后行为不一样”——根源常是基础镜像或构建参数不统一：
- Dockerfile 里固定基础镜像 tag，例如
FROM node:18.17-slim，别用latest - 构建参数（如
--build-arg NODE_ENV=production）在 CI 和本地构建时保持一致 - 测试阶段也应在容器中运行：用
docker run --rm myapp:${BUILD_ID} npm test，而非在 Jenkins 节点上直接跑 npm - 所有环节共享同一个
.dockerignore，避免误打包 dev 依赖或敏感文件
