Jenkins详细实践:SpringBoot+Jenkins+Gitlab+Docker-Maven插件

本文使用SpringBoot项目完成一个简单的Jenkins实践,利用docker-maven插件实现Docker从build到run再到push的完整流程,大大简化了Jenkins相关工作,不必再为Jenkins配置证书和编写额外的脚本.

写在前面

简化的关键在于fabric8io的docker-maven-plugin插件,利用它可以实现用maven指令对docker远程控制,网上其他文章的思路大多是利用spotify的maven插件完成docker镜像的build和push,再编写脚本文件,让Jenkins通过SSL在docker主机上远程执行脚本,达到在远程主机运行docker容器的目的.
这种做法第一是太麻烦,远程执行脚本需要配置SSL免密码访问,第二是SpringBoot项目和脚本耦合度高,由于镜像是在SpringBoot的插件完成相关构造的,而脚本其实就是死代码,必须人为地保证两者的统一协调.
而使用fabric8io的docker-maven-plugin则可以完整地控制docker镜像/容器的生命流程,从而避开这些问题.当然,用脚本自由度会比较高,可以做其他的事情,这个见仁见智.

以下是关于docker远程控制和插件使用的两篇文章:
Docker 守护进程+远程连接+安全访问
最强大的Docker插件 fabric8io/docker-maven-plugin

另外,Jenkins跑起来是比较耗资源的,如果Jenkins运行时突然挂掉,那多半是因为内存不足.我是使用docker来运行Jenkins的,有时候它还会把别的docker容器给挤挂了,无奈下只能另买一台阿里的学生机供Jenkins使用

如下图,是对Jenkins容器的单独监控,可以看到工作时运行内存占用在1.2G左右,这还只是在Docker内部,如果docker还有其他的容器在运行,再加上linux其他的服务,其实内存很容易就不够用的,另外,即使不挂,内存不够的情况下也可能导致Jenkins内部的任务执行出错,这种错误往往来得很莫名其妙,下文遇到的时候再介绍.

一 部署Jenkins

我使用的是docker部署,指令如下

docker run -p 9003:8080 -p 9004:50000 -v /opt/docker-volume/jenkins2:/var/jenkins_home -u root  --name lin_jenkins -d  jenkins/jenkins:lts

这里需要注意的是,jenkins/jenkins:lts并不是默认的官方镜像,官方镜像已经被废弃(deprecated )了,jenkins在Docker Hub的镜像首页推荐使用jenkins/jenkins:lts.

另外,因为Jenkins会产生比较多的文件(比方说一些插件和运行环境)在/var/jenkins_home目录下,所以建议将这个目录挂载出来

接下来登录 IP:9003 就可以访问Jenkins了

二 配置Jenkins环境

1 初次登录

1. 使用管理员密码
   初次访问Jenkins需要使用管理员密码,密码在”/var/jenkins_home/secrets/initialAdminPassword”下.
   由于我们已经把/var/jenkins_home挂载到/opt/docker-volume/jenkins2了,所以直接运行cat /opt/docker-volume/jenkins2/secrets/initialAdminPassword就可以获取密码,复制粘贴点继续
2. 安装推荐的插件
3. 创建第一个管理员用户,如果只是想尝试的话也可以直接点下面小字的”使用admin账户继续”
4. 一直按下一步指定进入Jenkins

2 全局工具配置

“系统管理”->”全局工具配置”

因为是在docker内,使用外部系统的JDK和Maven等工具比较麻烦,所以我这里直接使用自动下载,这里需要自己选定配置的工具有JDK,Git,Maven

注意,全局工具只有在第一次用到的时候才会去下载,以Maven为例,如果含”mvn”命令的shell脚本在第一次”调用顶层Maven目标”之前执行,则会报“sh: mvn: not