接上回继续学习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
参考上图,在jenkins中填写一个token(最好是一个唯一随机字符串),然后到bitbucket上进入项目的setting
添加一个Webhooks,如下图,URL填写的就是jenkins对外公开的回调url
这种方式是实时的,一旦有代码push到bitbucket上,就会触发jenkins发布。
b) Poll SCM
如果没有公网URL,就只能用下面这种方式了,大概意思是,每隔固定的时间去主动拉取代码,如果有变化,则触发build
图中的*/1 * * * * 表示每分钟拉一次代码
五、如何与bitbucket账号集成
jenkins可以与bitbucket上的某个账号认证集成,这样就省去了登录的过程,操作步骤:
a)bitbucket中生成key/screct,参考下图
b)jenkins中修改认证方式
几个关键地方,ClientId即为bitbucket中的Key, Client Screct即为bitbucket中的Screct,然后在下面的User/Group中切记要添加一条记录,用户名为bitbucket里的用户名,然后勾选Administer框(或其它你希望的权限),否则登录后没有任何权限。
这样设置后,不用输入用户名、密码就能直接进入jenkins了,但这种认证方式只能绑定一个bitbucket账号,个人感觉在公司里用处不大,除非整个开发团队共用一个bitbucket账号,然后每个人负责独立的一个项目,这显然不太现实。
(作者/菩提树下的杨过)
来源出处:http://yjmyzz.cnblogs.com
如果给你带来帮助,欢迎微信或支付宝扫一扫,赞一下。