Docker搭建Jenkins+git+Maven/Gradle实现自动化部署(Jenkins系列二)
一、简介
1、CI/CD
CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案,CI/CD 主要针对在集成新代码时所引发的问题(亦称:“集成地狱”)。
CI 持续集成(Continuous Integration)
现代应用开发的目标是让多位开发人员同时处理同一应用的不同功能。但是,如果企业安排在一天内将所有分支源代码合并在一起(称为“合并日”),最终可能造成工作繁琐、耗时,而且需要手动完成。这是因为当一位独立工作的开发人员对应用进行更改时,有可能会与其他开发人员同时进行的更改发生冲突。如果每个开发人员都自定义自己的本地集成开发环境(IDE),而不是让团队就一个基于云的 IDE 达成一致,那么就会让问题更加雪上加霜。
持续集成(CI)可以帮助开发人员更加频繁地(有时甚至每天)将代码更改合并到共享分支或“主干”中。一旦开发人员对应用所做的更改被合并,系统就会通过自动构建应用并运行不同级别的自动化测试(通常是单元测试和集成测试)来验证这些更改,确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突,CI 可以更加轻松地快速修复这些错误。
CD 持续交付(Continuous Delivery)
完成 CI 中构建及单元测试和集成测试的自动化流程后,持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程,务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
在持续交付中,每个阶段(从代码更改的合并,到生产就绪型构建版本的交付)都涉及测试自动化和代码发布自动化。在流程结束时,运维团队可以快速、轻松地将应用部署到生产环境中。
CD 持续部署(Continuous Deployment)
对于一个成熟的 CI/CD 管道来说,最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸,持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控,因此持续部署在很大程度上都得依赖精心设计的测试自动化。
实际上,持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效(假设它通过了自动化测试)。这更加便于持续接收和整合用户反馈。总而言之,所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险,因此更便于以小件的方式(而非一次性)发布对应用的更改。不过,由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段,因此前期投资还是会很大。
2、Jenkins、Maven、Gradle
2.1 jenkins 概述: Jenkins是一个功能强大的应用程序,允许持续集成和持续交付项目,无论用的是什么平台。这是一个免费的源代码,可以处理任何类型的构建或持续集成。集成Jenkins可以用于一些测试和部署技术。Jenkins是一种软件允许持续集成。 目的: 持续、自动地构建/测试软件项目。 监控软件开放流程,快速问题定位及处理,提示开放效率。 特性: 开源的java语言开发的持续集成工具,支持CI,CD。 易于安装部署配置:可通过yum安装,或下载war包以及通过docker容器等快速实现安装部署,可方便web界面配置管理。 消息通知及测试报告:集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知,生成JUnit/TestNG测试报告。 分布式构建:支持Jenkins能够让多台计算机一起构建/测试。 文件识别:Jenkins能够跟踪哪次构建生成哪些jar,哪次构建使用哪个版本的jar等。 丰富的插件支持:支持扩展插件,你可以开发适合自己团队使用的工具,如git,svn,maven,docker等。 2.2 maven、gradle 概述: Maven 是一个项目管理工具,可以对 Java 项目进行构建、依赖管理,是一个自动化构建工具。Maven项目对象模型(POM),可以通过一小段描述信息来管理项目的构建,报告和文档的项目管理工具软件。 Gradle是一个基于Apache Ant和ApacheMaven概念的项目自动化构建工具。它使用一种基于Groovy的特定领域语言来声明项目设置,而不是传统的XML。 自动化构建工具:将原材料(java、js、css、html....)->产品(可发布项目)编译-打包-部署-测试 -> 自动构建 maven和gradle的比较:(具体的比较可以百度,这里没有详细介绍) 都是java程序的构建工具 1、可扩展性 gradle够灵活。一方面是因为gradle使用的是groovy或者kotlin语言作为脚本的编写语言,这样极大的提高了脚本的灵活性,但是其本质上的原因是gradle的基础架构能够支持这种灵活性。 相对而言,maven的灵活性就差一些,并且自定义起来也比较麻烦,但是maven的项目比较容易看懂,并且上手简单。 所以如果你的项目没有太多自定义构建需求的话还是推荐使用maven,但是如果有自定义的构建需求,那么还是投入gradle的怀抱吧。 2、性能 Gradle和Maven都支持并行的项目构建和依赖解析。但是gradle的三个特点让gradle可以跑的比maven快上一点: 增量构建 构建缓存 gradle守护进程
3、自动化部署流程(jenkins+gogs+maven/gradle)
我们的初衷:
就是要实现只要开发提交代码到git远程仓库,jenkins就会自动检测到并且自动进行构建(合并、打包),构建完成之后将打好的包(war、jar包都可以)通过jenkins的插件传到tomcat的webapps目录下,然后重启tomcat,实现自动打包部署。
其工作流程是:
开发提交代码到gogs远程仓库——>使用jenkins触发构建任务,git插件从gogs仓库上拉取代码——>maven/gradle将代码编译打包——>jenkins将war包部署到tomcat/将jar包放到服务器
4、项目构建前环境准备
1、docker环境,搭建jenkins 192.168.1.20
2、搭建gogs代码仓库,192.168.1.20
3、nginx服务器 192.168.1.10
4、应用程序服务器安装tomcat:192.168.1.30
二、Jenkins构建maven项目
1、新建maven项目
打开新建的test项目,进行配置
2、配置maven项目的构建操作
保存构建历史,可以方便查看构建历史所用分支等信息:
配置git parameter插件,选择指定分支进行构建的功能。后面的git参数名称可以自定义,参数类型选分支:
配置jdk parameter插件,如果有多个jdk版本,指定一组作为构建参数选取的JDK:
源码管理, 配置git远程仓库地址等信息:
指定分支,跟git参数的自定义名称对应:
maven工具 清理旧数据,解决依赖并打包:
maven命令:mvn clean install -Dmaven.test.skip=true clean 移除所有上一次构建生成的文件 install 将包安装至本地仓库,以让其它项目依赖 maven.test.skip 跳过测试
3、配置java程序包发送到应用服务器
情况一:构建jar包通过配置SSH发送文件到服务器:(Publish over SSH插件 使用ssh免密登录到目标服务器)
系统管理——>系统配置——>publish over ssh——>SSH Server——>添加目标服务器信息——>测试是否正确
在Post Steps配置里添加选项 Send files or execute commands over SSH,并配置图示信息:
Source files #jenkins项目工作区中jar包路径 eg:mall-admin/target/mall-admin-1.0-SNAPSHOT.jar Remove prefix #删除jar包路径的前缀 eg:mall-admin/target/ Remote directory #将jar包放到应用服务器的目录地址 Exec command #应用服务器执行命令。
可以在Exec conmand 执行命令,也可以添加Execute shell脚本执行,也可以在应用服务器写好shell脚本执行。
完整的程序运行脚本,只需修改变量值就可以为你所用:
#自定义变量 DATE=$(date +%Y%m%d%T) JAVADIR=/usr/local/jdk1.8.0_171 PROJECT=mall-admin DIR=/server/jenkins SOFTDIR=$DIR/soft TEMPDIR=$DIR/temp LOGSDIR=$DIR/logs BACKUPDIR=$DIR/backup JARFILE=$PROJECT-1.0-SNAPSHOT.jar PID=$LOGSDIR/$PROJECT/$PROJECT.pid LOGS=$LOGSDIR/$PROJECT/$PROJECT.log #创建应用服务器目录 mkdir -p $DIR/{logs,soft,backup} if [ ! -d $LOGSDIR/$PROJECT ];then mkdir -p $LOGSDIR/$PROJECT fi #程序启动、停止、备份 cd $SOFTDIR kill -9 `cat $PID` mv $JARFILE $BACKUPDIR/$JARFILE.$DATE mv $LOGS $LOGS.$DATE mv -f $TEMPDIR/$JARFILE . $JAVADIR/bin/java -jar -Dspring.profiles.active=test $JARFILE >$LOGS & echo $! > $PID if [ $? = 0 ];then sleep 30 tail -n 50 $LOGS fi #清理多余日志 cd $LOGSDIR/$PROJECT ls -lt|awk 'NR>5{print $NF}'|xargs rm -rf
情况二:构建war包放到tomcat中运行
#docker搭建tomcat
启动测试tomcat:
docker run -itd -p 8080:8080 --name=tomcat tomcat
拷贝配置文件到宿主机:
docker cp tomcat:/usr/local/tomcat /server/docker/
可以修改tomcat配置文件(server.xml): 自定义端口等
删除测试,启动正式tomcat:
docker rm -f tomcat
docker run --restart=always --name=tomcat -p 8080:8080 \ -v /server/docker/tomcat:/usr/local/tomcat \ -itd tomcat
在"构建后操作"添加Deploy war/ear to a container 选项,让war包放到tomcat的webapps目录下,程序就能运行起来了。
修改tomcat配置文件,允许jenkins访问:
vim /server/docker/tomcat/config/tomcat-users.xml #管理员密码为:tomcat/tomcat
<role rolename="admin-gui"/> <role rolename="admin-script"/> <role rolename="manager-gui"/> <role rolename="manager-script"/> <role rolename="manager-jmx"/> <role rolename="manager-status"/> <user username="tomcat" password="tomcat" roles="manager-gui,manager-script,manager-jmx,manager-status,admin-script,admin-gui"/>
vim /server/docker/tomcat/webapps/manager/META-INF/context.xml
如下图修改,将这段话注销,让所以ip都可以访问tomcat,修改完重启tomcat:docker restart tomcat
4、指定分支构建项目
上面所有配置完成后,指定代码分支构建项目
到应用服务器或者jenkins查看日志,是否构建成功,如果没有构建成功,可从日志里找问题并解决。
打开"控制台输出",就能看到构建项目输出的日志了。
三、Jenkins构建gradle项目
1、新建一个自由风格项目
注意:接下来的配置跟构建maven项目一样,不同是的maven项目需要配置maven工具操作,gradle项目需要配置gradle工具操作
2、配置gradle工具打包编译操作
只有这两步跟maven不一样,其他都参考 “二、jenkins构建maven项目” 来配置,这里就不多说了~
四、Jenkins其他功能
1、用户权限管理,实现不同用户拥有不同的项目增删改查权限
2、jenkins+docker 微服务部署到docker容器中
3、jenkins+Sonarqube 构建前审查代码
活着不为取悦任何人
作者:等风来~~
本博客所有文章仅用于学习、研究和交流目的,欢迎转载。
如果觉得文章写得不错,或者帮助到您了,请点个赞。
如果文章有写的不足的地方,请你一定要指出,因为这样不光是对我写文章的一种促进,也是一份对后面看此文章的人的责任。谢谢。