接上回繼續學習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賬號，然后每個人負責獨立的一個項目，這顯然不太現實。