利用Jenkins生成maven项目镜像及容器

导读:本文根据天云软件研发工程师12月28日在DockOne技术社区的分享整理而成,文章结尾处有社区问答具体内容。以下是分享详情:

一、Jenkins是什么?

目前持续集成(CI)已成为当前许多软件开发团队在整个软件开发生命周期内侧重于保证代码质量的常见做法。它是一种实践,旨在缓和和稳固软件的构建过程。并且能够帮助您的开发团队应对如下挑战

  • 软件构建自动化:配置完成后,CI系统会依照预先制定的时间表,或者针对某一特定事件,对目标软件进行构建。
  • 构建可持续的自动化检查:CI系统能持续地获取新增或修改后签入的源代码,也就是说,当软件开发团队需要周期性的检查新增或修改后的代码时,CI系统会不断确认这些新代码是否破坏了原有软件的成功构建。这减少了开发者们在检查彼此相互依存的代码中变化情况需要花费的时间和精力。
  • 构建可持续的自动化测试:构建检查的扩展部分,构建后执行预先制定的一套测试规则,完成后触发通知(Email,RSS等等)给相关的当事人。
  • 生成后后续过程的自动化:当自动化检查和测试成功完成,软件构建的周期中可能也需要一些额外的任务,诸如生成文档、打包软件、部署构件到一个运行环境或者软件仓库。这样,构件才能更迅速地提供给用户使用。

Jenkins是一个可扩展的持续集成引擎。主要用于:持续、自动地构建/测试软件项目以及监控一些定时执行的任务。其拥有的特性包括:

1 . 易于安装-只要把jenkins.war部署到servlet容器,不需要数据库支持。

2 . 易于配置-所有配置都是通过其提供的web界面实现。

3 . 集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知。

4 . 生成JUnit/TestNG测试报告。

5 . 分布式构建支持Jenkins能够让多台计算机一起构建/测试。

6 . 文件识别:Jenkins能够跟踪哪次构建生成哪些jar,哪次构建使用哪个版本的jar等。

7 . 插件支持:支持扩展插件,你可以开发适合自己团队使用的工具。

jenkins结构图

CI系统基本结构图

该系统的各个组成部分是按如下顺序来发挥作用的:

1 . 开发者检入代码到源代码仓库。

2 . CI系统会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时,它将把源代码仓库的源码存放到对应的工作区。

3 . CI系统会在对应的工作区内执行构建过程。

4 . (配置如果存在)构建完成后,CI系统会在一个新的构件中执行定义的一套测试。完成后触发通知(Email,RSS等等)给相关的当事人。

5 . (配置如果存在)如果构建成功,这个构件会被打包并转移到一个部署目标(如应用服务器)或存储为软件仓库中的一个新版本。软件仓库可以是CI系统的一部分,也可以是一个外部的仓库,诸如一个文件服务器或者像Java.net、 SourceForge之类的网站。

6 . CI系统通常会根据请求发起相应的操作,诸如即时构建、生成报告,或者检索一些构建好的构件。

二、Jenkins的安装与部署

1 . 下载yum源

sudo wget -O/etc/yum.repos.d/jenkins.repo \https://pkg.jenkins.io/redhat-stable/jenkins.repo

2 . 导入密钥:sudo rpm –importhttps://pkg.jenkins.io/redhat-stable/jenkins.io.key

3 . 安装Jenkins:yum install jenkins

4 . 启动前检查是否安装jdk:java -version(最好是1.8以上的)

5 .修改配置文件:sudo vim /etc/init.d/jenkins

在candidates=”路径后添加java路径/usr/java/jdk1.8.0_144/bin/java.(根据个人Java安装地址)

jenkins安装

vi /etc/sysconfig/jenkins

找到JENKINS_PORT=“8080”(8080是Jenkins默认端口,若被占用课修改为其他空闲端口)

jenkins安装2

6 . 关闭防火墙

7 . 启动应用:sudo service jenkins start

三、Jenkins构建maven项目

1、插件安装

  • 启动Jenkins服务以后便可登录浏览器访问,因为我们需要从git上拉取源码,所以要在Jenkins上安装相应的git插件,同时我们也需要安装maven类的插件来支持构建maven项目。

jenkins3

  • –》点击系统管理

jenkins4

  • –》点击管理插件

jenkins5

jenkins6

  • 在可选插件中找到Git plugin和Maven Integration plugin相关插件并安装插件安装完毕后重启Jenkins

2、新建maven项目

  • 新建一个job

jenkins7

  • 输入名称和项目类型

jenkins8

  • 源码管理

在源码管理项中选择git并输入git地址并在Credentials中Add仓库登录账号密码,在下方分支选择中选择需要构建的项目分支。

jenkins9

 

  • 构建触发器

根据实际要求构建符合要求的触发器,此图中触发器Poll SCM的功能是每个一定时间便检查源码是否有更新,若有则自动构建。(*/60****含义是每隔60分钟检查一次git源码)

jenkins10

 

  • 构建选项

第一行选项是默认的pom文件在git的root目录下,如果pom文件在其他路径下,则需要输入相应的路径/pom.xml;第二行执行的maven命令。

jenkins11

此时maven项目构建基本就完成,进入将maven项目生成docker镜像的步骤。

四、Docker镜像构建

1、docker配置

在Jenkins中安装相应的docker插件(docker-build-step)

在Host服务器上安装docker(1.12.6版本慎用)

配置docker的远程访问:

  • centos下修改docker的配置文件/usr/lib/systemd/system/docker.service
  • 在[Service]的部分添加(此处是暴露的6732端口)

ExecStart=

ExecStart=/usr/bin/dockerd -Htcp://0.0.0.0:6732 -H unix://var/run/docker.sock

Jenkins12

  • docker重新读取配置文件并重启docker服务

# systemct ldaemon-reload

# systemctl restartdocker

  • 进入Jenkins,选择系统管理–》系统设置–》Docker Builder

jenkins13

  • 在Docker URL处填写暴露的端口tcp://10.10.184.150:6732然后保存

jenkins15 jenkins14

这样Jenkins便可调用host服务器中的docker功能

2、创建Docker镜像

  • 执行脚本构建容器和镜像:在上一步构建war包之后继续选择POSTSteps,执行我们放在Jenkins宿主机上/home/skyform/目录下的构建脚本

jenkinsPostSteps

rollingupdateNew1

rollingupdateNew2

  • 保存后进入操作页面并点击立即构建

jenkins15

  • 此时左下角会出现构建进度条,蓝色表示构建成功,红色表示构建失败,灰色表示构建未完成

jenkins16

  • 构建结束后点击构建编号,进入结果查看界面,点击Console Output查看构建过程

jenkins17

这样就完成了利用Jenkins来够构建一个maven项目并将其制作成Docker镜像的工作。这个构建过程会根据你的触发器设置来不断实施,从而达到监控软件开发流程,快速显示问题与部署的目的。保证开发人员以及相关人员省时省力提高开发效率。

五、案例

目前SkyForm产品在进行微服务化改造,我们采用jenkins+docker支撑了SkyForm产品各个微服务的开发、部署、测试的整个过程

SkyForm产品中间件docker化:

jenkins微服务1

Jenkins微服务2

Jenkins微服务3

SkyForm产品微服务docker化(19个):

产品19个

产品19个2

SkyForm 5.0微服务通过Jenkins实现持续集成及构建架构:

 

大图

研发人员将自己的代码提交至git仓库,Jenkins响应设定的触发器,将提交后的代码拉取、编译、打包至Jenkins宿主机上,然后执行脚本,通过Docker命令在开发环境(或测试环境)生成响应镜像并启动容器,研发人员此时即可在开发环境(或测试环境)下进行联调。

 

Q&A板块

(由社区分享问答环节整理而成)

Q:项目不同的git分支是怎么打包镜像了?比如测试分支和开发,生产分支。    

A:在源码管理那块可以设置不同的分支,需要创建管理不同分支的Jenkins项目。

Q:通过compose启动的服务在3以后依赖不起作用了,那如何做前置依赖健康的检测呢,再就是启动的服务如果服务失败后会自动重启,这样会造成很多失败的实例,如何清楚这些大量的失败实例,还有通过swarm做的集群在做服务发布的时候会没有tag这是是哪里的问题(私有仓库)?

A:健康检测目前是通过人工手动检查dubbo服务注册的情况,以后可以将这一功能写到脚本里,例如探测前一服务一个功能是否能正常提供作为服务健康状况的评定标准,服务失败自动重启的只是那个失败的容器不会导致有大量的失败容器。

Q:持续集成和持续发布这块如何衔接?

A:持续集成与持续发布这一块主要是通过自动化部署脚本去完成,通过将测试通过的镜像保存下来与自动化部署脚本一起打包做成安装包,某一服务的升级也只需将容器镜像替换重新启动一个实例即可。

Q:gitlab+jenkins 和gitlab+gitlab runner怎么选择?

A:我们主要是基于将代码管理与持续集成分割开的理念,加上之前也有jenkins项目经验来选择的,基于求稳的心态没有尝试gitlab runner而且gitlab runner是每次只要有人push代码就会触发脚本而这不是我们所期望的,我们是期望定期检查是否执行迭代或者定期的执行迭代,runner的权限管理也不如jenkins的更符合我们的诉求。

Q:生产和测试网络是隔离的吗?Jenkins是部署在哪个网络区域主机上?Jenkins自身是run在容器里吗?有没有遇到Jenkins压力?

A:是网络隔离的,jenkins是运行在单独的虚拟机中,jenkins压力主要是长久的构建导致磁盘压力的问题。

Q:脚本中生成的war包是固定的?如果项目生成不同的war包,每次都需要改脚本吗?

A:每个服务都会对应一个部署脚本,脚本里的信息要根据部署的服务来更改。

Q:多次发布项目生成镜像,镜像版本怎么控制?历史镜像版本如何管理?

A:版本控制是由git去做,我们在镜像这一部分不去做重复的功能。