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

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

《利用Jenkins生成maven项目镜像及容器.docx》由会员分享，可在线阅读，更多相关《利用Jenkins生成maven项目镜像及容器.docx（14页珍藏版）》请在冰豆网上搜索。

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

利用Jenkins生成maven工程镜像及容器

导读：

本文根据天云软件研发工程师12月28日在Dockone技术社区的分享整理而成，文章结尾处有社区问答具体容。

以下是分享详情：

一、Jenkins是什么

目前持续集成（CI）已成为当前许多软件开发团队在整个软件开发生命周期侧重于保证代码质量的常见做法。

它是一种实践，旨在缓和和稳固软件的构建过程。

并且能够帮助您的开发团队应对如下挑战：

1、软件构建自动化：

配置完成后，CI系统会依照预先制定的时间表，或者针对某一特定事件，对目标软件进展构建。

2、构建可持续的自动化检查：

CI系统能持续地获取新增或修改后签入的源代码，也就是说，当软件开发团队需要周期性的检查新增或修改后的代码时，CI系统会不断确认这些新代码是否破坏了原有软件的成功构建。

这减少了开发者们在检查彼此相互依存的代码中变化情况需要花费的时间和精力。

3、构建可持续的自动化测试：

构建检查的扩展局部，构建后执行预先制定的一套测试规那么，完成后触发通知（Email,RSS等等）给相关的当事人。

4、生成后后续过程的自动化:

当自动化检查和测试成功完成，软件构建的周期中可能也需要一些额外的任务，诸如生成文档、打包软件、部署构件到一个运行环境或者软件仓库。

这样，构件才能更迅速地提供给用户使用。

Jenkins是一个可扩展的持续集成引擎。

主要用于：

持续、自动地构建/测试软件工程以及监控一些定时执行的任务。

其拥有的特性包括：

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

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

3、集成RSS/通过RSS发布构建结果或当构建完成时通过通知。

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

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

6、文件识别:

Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。

7、插件支持:

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

CI系统根本构造图

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

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

2. CI系统会为每一个工程创立了一个单独的工作区。

当预设或请求一次新的构建时，它将把源代码仓库的源码存放到对应的工作区。

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

4. 〔配置如果存在〕构建完成后，CI系统会在一个新的构件中执行定义的一套测试。

完成后触发通知（Email,RSS等等）给相关的当事人。

5. 〔配置如果存在〕如果构建成功，这个构件会被打包并转移到一个部署目标（如应用效劳器）或存储为软件仓库中的一个新版本。

软件仓库可以是CI系统的一局部，也可以是一个外部的仓库，诸如一个文件效劳器或者像J、 SourceForge之类的。

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

二、Jenkins的安装与部署

1、下载yum源：

sudowget-O/etc/yum.repos.d/jenkins.repo\s:

//pkg.jenkins.io/redhat-stable/jenkins.repo

2、导入密钥：

sudorpm--imports:

//pkg.jenkins.io/redhat-stable/jenkins.io.key

3、安装Jenkins：

yuminstalljenkins

4、启动前检查是否安装jdk：

java-version〔最好是1.8以上的〕

5、修改配置文件：

sudovim/etc/init.d/jenkins

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

vi/etc/sysconfig/jenkins

找到JENKINS_PORT=“8080〞〔8080是Jenkins默认端口，假设被占用课修改为其他空闲端口〕

6、关闭防火墙

7、启动应用：

sudoservicejenkinsstart

三、Jenkins构建maven工程

1、插件安装

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

--?

点击系统管理

--?

点击管理插件

（以下图换为Jenkins5和Jenkins6〕

在可选插件中找到Gitplugin和MavenIntegrationplugin插件并安装

插件安装完毕后重启Jenkins

2、新建maven工程

新建一个job

〔以下图换为Jenkins7〕

输入名称和工程类型

源码管理

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

构建触发器

根据实际要求构建符合要求的触发器，此图中触发器PollSCM的功能是每个一定时间便检查源码是否有更新，假设有那么自动构建。

〔*/60****含义是每隔60分钟检查一次git源码〕

构建选项

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

此时maven工程构建根本就完成，进入将maven工程生成docker镜像的步骤。

四、Docker镜像构建

1、docker配置

在Jenkins中安装相应的docker插件〔docker-build-step〕

在Host效劳器上安装docker〔1.12.6版本慎用〕

配置docker的远程访问：

1、centos下修改docker的配置文件/usr/lib/systemd/system/docker.service

2、在[Service]的局部添加〔此处是暴露的6732端口〕

ExecStart=

ExecStart=/usr/bin/dockerd-Htcp:

//0.0.0.0:

6732-Hunix:

//var/run/docker.sock

3、docker重新读取配置文件并重启docker效劳

#systemctldaemon-reload

#systemctlrestartdocker

进入Jenkins，选择系统管理--?

系统设置--?

DockerBuilder

在DockerURL处填写暴露的端口tcp:

//10.10.184.150:

6732然后保存

这样Jenkins便可调用host效劳器中的docker功能

2、创立Docker镜像

执行脚本构建容器和镜像：

在上一步构建war包之后继续选择POSTSteps，执行我们放在Jenkins宿主机上/home/skyform/目录下的构建脚本

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

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

构建完毕后点击构建编号，进入结果查看界面，点击ConsoleOutput查看构建过程

这样就完成了利用Jenkins来够构建一个maven工程并将其制作成Docker镜像的工作。

这个构建过程会根据你的触发器设置来不断实施，从而到达监控软件开发流程，快速显示问题与部署的目的。

保证开发人员以及相关人员省时省力提高开发效率。

五、案例

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

SkyForm产品中间件docker化：

SkyForm产品微效劳docker化〔19个〕：

SkyForm5.0微效劳通过Jenkins实现持续集成及构建架构:

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

六、疑问及解答

Q：

工程不同的git分支是怎么打包镜像了？

比方测试分支和开发，生产分支。

A：

在源码管理那块可以设置不同的分支，需要创立管理不同分支的Jenkins工程。

Q：

通过pose启动的效劳在3以后依赖不起作用了，那如何做前置依赖安康的检测呢，再就是启动的效劳如果效劳失败后会自动重启，这样会造成很多失败的实例，如何清楚这些大量的失败实例，还有通过swarm做的集群在做效劳发布的时候会没有tag这是是哪里的问题〔私有仓库〕？

A：

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

Q：

.持续集成和持续发布这块如何衔接？

A：

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

Q:

gitlab+jenkins和gitlab+gitlabrunner怎么选择？

A：

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

Q：

生产和测试网络是隔离的吗？

Jenkins是部署在哪个网络区域主机上？

Jenkins自身是run在容器里吗？

有没有遇到Jenkins压力？

A：

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

Q：

脚本中生成的war包是固定的？

如果工程生成不同的war包，每次都需要改脚本吗？

A：

每个效劳都会对应一个部署脚本，脚本里的信息要根据部署的效劳来更改。

Q：

.屡次发布工程生成镜像，镜像版本怎么控制？

历史镜像版本如何管理？

A：

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