马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?立即注册
×
用 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企服评测-应用市场 编辑提示 |