jenkins+docker实现可连续自动化摆设springboot项目

[复制链接]
发表于 2026-10-3 15:31:11 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?立即注册

×

用 Jenkins + Docker 给 Spring Boot 搭一条持续集成部署流水线

一个 Spring Boot 微服务项目在多环境切换时,最消耗时间的往往不是写代码,而是"把代码搬到服务器上跑起来"这一步。传统做法是人工打 jar 包、传服务器、改配置、重启进程,几台机器就要重复几遍。把 Jenkins 和 Docker 放在一起用,可以让这套动作变成一条可重复执行的流水线。

为什么微服务项目需要自动化部署

单体应用时代,一次发布的范围可控,人工操作尚且能兜住。拆成微服务之后事情变了:

  • 服务数量变多,一个业务动作可能牵动七八个镜像的先后更新。
  • 环境差异压在本地能跑、预发跑不通,根因常是依赖库版本被偷偷改过。
  • 回滚成本高,人工操作一旦记错步骤,恢复到上一个版本可能要半小时。

把构建、打包、镜像生成、容器启动这四步固化成流水线, releasing 的次数越多,单次耗时反而越短。

先理清 CI 和 CD 的分工

很多人把这两个词混着说,实际职责不同:

  • CI(持续集成):团队每次提交代码后自动触发,完成编译、单元测试、静态检查,产出可交付物。目标是"让集成这件事不再靠人记得做"。
  • CD(持续交付 / 持续部署):把 CI 产出的可交付物自动发布到测试环境乃至生产环境。持续交付是"随时可发布但需要人点一下",持续部署是"通过后直接发布"。

Jenkins 负责编排整条链,Docker 负责把运行环境和代码打包成一个整体,两者互补:Jenkins 解决"什么时候做、怎么做",Docker 解决"在哪儿跑都一样"。

环境准备

需要准备的东西不多:

  • 一台装好 jdk、maven 的构建机,Jenkins 通常就跑在这台机器上。
  • 一台(或多台)运行 Docker 的应用服务器,开放 Jenkins 可访问的端口。
  • 一个 Git 仓库,代码里带上 Dockerfile 与 jenkinsfile。

Docker 镜像准备可以先本地验证一遍,确保 Dockerfile 本身没写错:

# 拉取基础镜像
docker pull openjdk:8-jdk-alpine

# 构建业务镜像
docker build -t myapp:latest .

# 本地起一下看能不能跑
docker run -d -p 8080:8080 myapp:latest

Jenkins 侧的关键配置

在 Jenkins 里安装 Pipeline 插件后,新建一个 Pipeline 任务,把下面这段写进 jenkinsfile:

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        sh 'mvn clean package -DskipTests'
      }
    }
    stage('Docker Build') {
      steps {
        sh 'docker build -t myapp{BUILD_NUMBER} .'
      }
    }
    stage('Deploy') {
      steps {
        sh 'docker stop myapp || true'
        sh 'docker rm myapp || true'
        sh 'docker run -d --name myapp -p 8080:8080 myapp{BUILD_NUMBER}'
      }
    }
  }
}

注意 ${BUILD_NUMBER} 的用法——用构建号做镜像标签,回滚时直接指定上一个 tag 重新拉起即可,比覆盖 latest 稳妥得多。

几个容易踩的点

  • Jenkins 里的 docker 命令执行失败:多数是 Jenkins 用户不在 docker 用户组,把 Jenkins 进程用户加进组后重启 Jenkins 服务即可。
  • 容器起来了但接口不通:常见是 Spring Boot 里配了写死的 IP,容器网络环境一换就不通,应改用服务名或环境变量注入。
  • 磁盘被镜像吃满:流水线跑久了会留下大量 <none> 镜像,定期执行 docker image prune 清理。

小结

Jenkins 加 Docker 的组合,本质是把"发布"这个动作从一次性手工操作,变成一条可重跑的脚本。一次配置好,后面每次提交代码都能顺带完成编译、镜像构建和容器更新,回滚也只是重新拉起上一个标签的镜像。对还在用人工上传 jar 包的项目来说,这是投入产出比最高的一次改造。

qidao123.com企服评测-应用市场 编辑提示

回复

使用道具 举报

登录后关闭弹窗

登录参与点评抽奖  加入IT实名职场社区
去登录
快速回复 返回顶部 返回列表