接上回继续学习jenkins，这次主要来看一些疑难杂症：

一、yum install安装方式

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

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

安装完成后，可用

sudo service jenkins start/stop/restart

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

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

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

  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所在的正确位置加入其中即可，比如：

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 进一步排查。建议同学们把这个启动脚本仔细阅读一下，可以发现很多有用的信息，比如：

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这个文件,找到

JENKINS_PORT="8080"

修改一下即可。

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

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 找到

<useSecurity>true</useSecurity>

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

<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账号，然后每个人负责独立的一个项目，这显然不太现实。