Docker 容器化部署：如何让 CI/CD 流水线融入 Docker 环境

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 推送

保持环境一致性：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 依赖或敏感文件