jenkins 入门教程(下)

上回继续学习jenkins,这次主要来看一些疑难杂症:

一、yum install安装方式

除了直接java -jar jenkins.war方式,还可以用yum安装,这种方式下提供了更多的可配置选项,更适合生产环境控制jenkins的行为。

1
2
3
4
5
sudo yum update -y (可选)
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
yum install deltarpm (可选)
sudo yum install jenkins

安装完成后,可用

1
sudo service jenkins start/stop/restart

不过,我在centos 7环境上测试下来,/etc/rc.d/init.d/jenkins这个脚本写得有点小问题,如果java不在默认目录下,会导致启动失败

1
sudo vi /etc/rc.d/init.d/jenkins

定位到67行,会发现该脚本会从以下位置找java可执行文件

1
2
3
4
5
6
7
8
9
10
candidates="
/etc/alternatives/java
/usr/lib/jvm/java-1.6.0/bin/java
/usr/lib/jvm/jre-1.6.0/bin/java
/usr/lib/jvm/java-1.7.0/bin/java
/usr/lib/jvm/jre-1.7.0/bin/java
/usr/lib/jvm/java-1.8.0/bin/java
/usr/lib/jvm/jre-1.8.0/bin/java
/usr/bin/java
"

如果java没安装在这些目录下,启动就会失败,解决办法:把java所在的正确位置加入其中即可,比如:

1
2
3
candidates="
/opt/app/jdk1.8.0_65/bin/java
"

注:这样处理后,还要执行一下sudo systemctl daemon-reload,然后就可以service jenkins start了,如果还出错,尝试 cd /etc/rc.d/init.d,然后sudo ./jenkins start 进一步排查。建议同学们把这个启动脚本仔细阅读一下,可以发现很多有用的信息,比如:

1
2
3
4
5
JENKINS_WAR="/usr/lib/jenkins/jenkins.war"
JENKINS_CONFIG=/etc/sysconfig/jenkins
JENKINS_PID_FILE="/var/run/jenkins.pid"
PARAMS="--logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --daemon"
--simpleAccessLogger.file=/var/log/jenkins/access_log

上面这些参数定义了配置文件、war包、pid文件、日志的位置,出问题时,我们可以直接到这些位置去查看详情。

比如:端口8080被占用了,需要更改启动端口,直接查看/etc/sysconfig/jenkins这个文件,找到

1
JENKINS_PORT="8080"

修改一下即可。

/etc/sysconfig/jenkins这个文件也建议通篇阅读,里面有一些很关键的信息,比如:

1
2
3
4
5
JENKINS_HOME="/var/lib/jenkins"
JENKINS_USER="jenkins"
JENKINS_AJP_PORT="8009"
JENKINS_DEBUG_LEVEL="5"
JENKINS_ENABLE_ACCESS_LOG="no"

 

二、jenkins的启动身份问题

以 java -jar jenkins.war 这种方式启动时,默认会在当前用户根目录下,创建.jenkins目录,所有与jenkins相关的内容,包括配置文件,用户创建的数据都在该目录下,如果你切换另一个账号登录linux,然后重新启动,会发现之前所有创建的项目包括用户全没了,因为此时jenkins的工作目录切换到新用户的~/.jenkins下了,所以一般情况下,不要随意切换启动身份。

以 yum install安装的jenkins,由于工作目录是在/etc/sysconfig/jenkins里写死的,所以不存在这个问题,但是这种方式下,很多目录都是放在/var打头的位置,权限较少,如果出现无法写文件之类的错误,注意调整jenkins用户或目录的权限。

 

三、安全策略配置错误,导致无法使用jenkins的问题

有时候自己瞎折腾,把匿名用户的管理权禁止了,然后能登录的用户又忘记了勾选管理权限,这时就懵了,不要着急,进入~/.jenkins或/var/lib/jenkins,编辑config.xml 找到

1
<useSecurity>true</useSecurity>

大致是第7行,然后把下面的二个节点改成:

1
2
<authorizationStrategy class="hudson.security.AuthorizationStrategy$Unsecured"/>
<securityRealm class="hudson.security.SecurityRealm$None" />

保存,然后重启jenkins,就ok了。

如果没有什么重要数据的话,也可以更暴力一点,把~/.jenkins或/var/lib/jenkins下把除plugins之外的目录全干掉即可,相当于除插件之外,所有内容全初始化。

 

四、代码提交后,jenkins如何自动构建?

有二种做法,以bitbucket这一类git代码托管的项目为例:

a)Trigger Builds remotely

这种方式适合jenkins系统能公网访问的场景,大致原理是jenkins的每个项目,都有一个对外公开的url,然后在bitbucket的项目里配置一个所谓的webHook勾子,勾子里填写的url就是jenkins的这个url,每次有代码提交到bitbucket时,bitbucket会回调整这个url,通知jenkins触发build

27612-20160121142014656-935924758

参考上图,在jenkins中填写一个token(最好是一个唯一随机字符串),然后到bitbucket上进入项目的setting

27612-20160121143503234-447584166

添加一个Webhooks,如下图,URL填写的就是jenkins对外公开的回调url

27612-20160121143541734-1259957972

这种方式是实时的,一旦有代码push到bitbucket上,就会触发jenkins发布。

b) Poll SCM

如果没有公网URL,就只能用下面这种方式了,大概意思是,每隔固定的时间去主动拉取代码,如果有变化,则触发build

27612-20160121143637859-528693394

图中的*/1 * * * * 表示每分钟拉一次代码

 

五、如何与bitbucket账号集成

jenkins可以与bitbucket上的某个账号认证集成,这样就省去了登录的过程,操作步骤:

a)bitbucket中生成key/screct,参考下图

27612-20160121151251593-1938094987

b)jenkins中修改认证方式

27612-20160121151358031-959569762

几个关键地方,ClientId即为bitbucket中的Key, Client Screct即为bitbucket中的Screct,然后在下面的User/Group中切记要添加一条记录,用户名为bitbucket里的用户名,然后勾选Administer框(或其它你希望的权限),否则登录后没有任何权限。

这样设置后,不用输入用户名、密码就能直接进入jenkins了,但这种认证方式只能绑定一个bitbucket账号,个人感觉在公司里用处不大,除非整个开发团队共用一个bitbucket账号,然后每个人负责独立的一个项目,这显然不太现实。

(作者/菩提树下的杨过)

来源出处:http://yjmyzz.cnblogs.com


如果给你带来帮助,欢迎微信或支付宝扫一扫,赞一下。