1. 程式人生 > 其它 >Jenkins獲取gitlab原始碼

Jenkins獲取gitlab原始碼

Jenkins獲取gitlab原始碼

Jenkins許可權獲取

在日常工作做由於Jenkins啟動使用者是Jenkins,在執行指令碼時系統命令是無法讓Jenkins執行的,如果需要Jenkins許可權有兩種辦法:
1. sudo授權
2. 啟動使用者改為root [這裡就使用這個辦法了,因為做sudo授權太浪費時間了,其次gitlab都是內網使用沒有什麼安全威脅]

由於sudo授權比較繁瑣,這裡直接將啟動使用者改為root即可,大家可能說這個會不會不安全,其實不會
因為Jenkins是在內網部署,自己使用的. 無法唄外部使用者訪問,所以我們只需要配置為root使用者啟動即可

JENKINS_USER="jenkins" 

# 修改之前檢視啟動使用者:
[root@node1 freestyle-job]# lsof  -i:8080
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java    12742 jenkins  162u  IPv6 331298      0t0  TCP *:webcache (LISTEN)
#目前啟動使用者是Jenkins,我們需要改為root使用者來執行

# sed來替換啟動使用者改為root
sed -i  "29s#JENKINS_USER\=\"jenkins\"#JENKINS_USER\=\"root\"#g" /etc/sysconfig/jenkins

# 修改完成重啟Jenkins
 systemctl restart jenkins.service
 
 
# 檢視重啟狀態和啟動使用者
[root@node1 freestyle-job]# lsof  -i:8080
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java    12594 root  162u  IPv6 330233      0t0  TCP *:webcache (LISTEN)

可以看到使用者已經改為了root

上面這些更改只為做一件事,讓大家理解.許可權的作用,如果我執行構建裡面有 建立使用者等這些敏感資訊的時候非root使用者許可權是不允許做這些操作的. 看下面的案例:

Jenkins許可權案例:

建立一個新的構建

檢查當前Jenkins與執行使用者:

[root@node1 plugins]# lsof -i:8080
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java    13892 jenkins  162u  IPv6 338577      0t0  TCP *:webcache (LISTEN)
java    13892 jenkins  590u  IPv6 341276      0t0  TCP node1:webcache->10.0.0.1:58342 (ESTABLISHED)
目前我們使用的是Jenkins使用者,按理來說Jenkins是不可以越權建立使用者的,下面來看實際情況,以便於我們理解Jenkins許可權.

我們看到了一條紅色資訊:

看到 Permission denied 我們就可以得出結論了, Jenkins是無法建立使用者的沒有許可權,所以報錯,許可權不足

修改Jenkins執行使用者,來重新執行構建.

# sed來替換啟動使用者改為root
sed -i  "29s#JENKINS_USER\=\"jenkins\"#JENKINS_USER\=\"root\"#g" /etc/sysconfig/jenkins

# 修改完成重啟Jenkins
systemctl restart jenkins.service

重新構建截圖:

Linux下檢查使用者是否被建立:

[root@node1 plugins]# id chenleilei
uid=1001(chenleilei) gid=1001(chenleilei) groups=1001(chenleilei)

chenleilei使用者已經被建立,說明我們的理解是正確的,Jenkins是無法處理超越本身許可權之外的工作的.

許可權獲取還有第二種方法 ,就是使用sudo授權來配置讓Jenkins能夠有許可權執行,但是配置sudo授權.太浪費時間,這種策略是最好的辦法.
但是其實我感覺..專案目錄的許可權也至關重要,這裡聽老師講課改為了Jenkins使用者執行報錯,其實原因就出現在 專案目錄是root許可權,Jenkins是無權訪問的.如果需要訪問或者建立檔案許可權就必須將:
/var/lib/jenkins/workspace/my-freestyle-job/ 這個目錄許可權改為 Jenkins,否則他無法越權在這個目錄建立和修改檔案.

檢測我的理解是否正確:

修改目錄 /var/lib/jenkins/workspace/my-freestyle-job/ 許可權為Jenkins :
 chown -R jenkins.jenkins  /var/lib/jenkins/workspace/my-freestyle-job
 
修改啟動使用者為Jenkins:
sed -i  "29s#JENKINS_USER\=\"root\"#JENKINS_USER\=\"jenkins\"#g" /etc/sysconfig/jenkins

#重啟Jenkins
[root@node1 my-freestyle-job]# systemctl restart jenkins.service 
[root@node1 my-freestyle-job]# systemctl status jenkins.service 
● jenkins.service - LSB: Jenkins Automation Server
   Loaded: loaded (/etc/rc.d/init.d/jenkins; bad; vendor preset: disabled)
   Active: active (running) since Fri 2019-12-27 14:32:41 CST; 6s ago  ##-- 狀態正常

#重新執行構建任務

注意點:

我們執行任何任務都是從任務的資料夾下開始的: 
/var/lib/jenkins/workspace/my-freestyle-job/

如果我們任務中有建立檔案但是沒寫絕對路徑,它只會在 /var/lib/jenkins/workspace/my-freestyle-job/ 下面建立.
這些在控制檯是看不到的.但是可以看到構建目錄

Jenkins故障:

構建過程中重啟了Jenkins就會出現啟動無法開啟網頁:
解決: rm -f /var/lib/jenkins/jobs/my-freestyle-job/nextBuildNumber

Jenkins配置git拉取gitlab倉庫程式碼自動釋出:

點選 test 後點擊 push events 測試,然後再Jenkins中檢視是否觸發了任務.

Jenkins中看到的:

這次我們沒有主動點選 "立即構建" 他自己就 主動push了一次,再上面的圖中也可以清楚的看到: "Started by GitLab push by Administrator" 他是又gitlab自動觸發的立即構建.

回到gitlab檢視我們剛才的構建日誌:


還記得我們Jenkins中的shell執行了什麼嗎?

檢查是否建立:

這樣就完成了 git+gitlab+Jenkins實現自動構建自動整合的過程.
在企業中同樣的做法. 只不過 主動觸發事件 會變成shell 的方式,一旦提交就會編譯並立即釋出.

自動釋出:

測試 push檔案,然後自動釋出:
回到一臺綁定了 gitlab的伺服器 克隆程式碼:

安裝一個nginx 檢視頁面效果:

curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
yum install -y wget
wget -P /etc/yum.repos.d/ http://mirrors.aliyun.com/repo/epel-7.repo
yum clean all
yum install -y nginx

頁面效果:

修改構建任務:

目的是讓 修改後的檔案拷貝到html,或者也可以做ln -s 的軟連線,這裡演示就做拷貝了

執行push:

[root@node1 leilei_test]# echo  "<h1>chenleilei _ auto test </h1>" >>index.html[root@node1 leilei_test]# git add *[root@node1 leilei_test]# git commit -m "midify index.html"[root@node1 leilei_test]# git push -u origin master

檢查網頁狀態:

到這裡 自動化釋出已經完成!!

微信讚賞

支付寶讚賞