Java之Jenkins工具【轉】

時間 2019-11-25

標籤 java jenkins 工具欄目 Java 简体版

原文原文鏈接

1.1 前言

Jenkins是一個用Java編寫的開源的持續集成工具。在與Oracle發生爭執後，項目從Hudson項目獨立。php

Jenkins提供了軟件開發的持續集成服務。它運行在Servlet容器中（例如Apache Tomcat）。它支持軟件配置管理（SCM）工具（包括AccuRev SCM、CVS、Subversion、Git、Perforce、Clearcase和RTC），能夠執行基於Apache Ant和Apache Maven的項目，以及任意的Shell腳本和Windows批處理命令。Jenkins的主要開發者是川口耕介。Jenkins是在MIT許可證下發布的自由軟件。html

1.1.1 Jenkins功能

一、持續的軟件版本發佈/測試項目。前端

二、監控外部調用執行的工做。java

1.2 怎麼理解持續集成、持續交付、持續部署呢？

1.2.1 持續集成

持續集成（英語：Continuous integration，縮寫爲 CI），一種軟件工程流程，將全部工程師對於軟件的工做複本，天天集成數次到共用主線（mainline）上。git

這個名稱最先由葛來迪·布區（Grady Booch）在他的布區方法中提出，可是他並無提到要天天集成數次。以後成爲極限編程（extreme programming，縮寫爲XP）的一部分。在測試驅動開發（TDD）的做法中，一般還會搭配自動單元測試。web

持續集成的提出，主要是爲了解決軟件進行系統集成時面臨的各項問題，極限編程稱這些問題爲集成地獄（integration hell）。docker

持續集成主要是強調開發人員提交了新代碼以後，馬上進行構建、（單元）測試。根據測試結果，咱們能夠肯定新代碼和原有代碼可否正確地集成在一塊兒。簡單來說就是：頻繁地（一天屢次）將代碼集成到主幹。shell

持續集成目的在產生如下效益如：數據庫

ü 及早發現集成錯誤且因爲修訂的內容較小因此易於追蹤，這能夠節省項目的時間與成本。編程

ü 避免發佈日期的前一分鐘發生混亂，當每一個人都會嘗試爲他們所形成的那一點點不兼容的版本作檢查。

ü 當單元測試失敗或發生錯誤，若開發人員須要在不除錯的狀況下還原代碼庫到一個沒有問題的狀態，只須要放棄一小部分的更改 (由於集成的次數頻繁)。

ü 讓 "最新" 的程序可保持可用的狀態供測試、展現或發佈用。

ü 頻繁的提交代碼會促使開發人員建立模塊化，低複雜性的代碼。

ü 防止分支大幅偏離主幹。若是不是常常集成，主幹又在不斷更新，會致使之後集成的難度變大，甚至難以集成。

1.2.2 持續交付

持續交付（英語：Continuous delivery，縮寫爲 CD），是一種軟件工程手法，讓軟件產品的產出過程在一個短週期內完成，以保證軟件能夠穩定、持續的保持在隨時能夠釋出的情況。

它的目標在於讓軟件的建置、測試與釋出變得更快以及更頻繁。這種方式能夠減小軟件開發的成本與時間，減小風險。

持續交付在持續集成的基礎上，將集成後的代碼部署到更貼近真實運行環境的「類生產環境」（production-like environments）中。好比，咱們完成單元測試後，能夠把代碼部署到鏈接數據庫的 Staging 環境中更多的測試。若是代碼沒有問題，能夠繼續手動部署到生產環境中。

1.2.3 持續部署

持續部署（英語：Continuous Deployment，縮寫爲 CD），是持續交付的下一步，指的是代碼經過評審之後，自動部署到生產環境。

有時候，持續部署也與持續交付混淆。持續部署意味着全部的變動都會被自動部署到生產環境中。持續交付意味着全部的變動均可以被部署到生產環境中，可是出於業務考慮，能夠選擇不部署。若是要實施持續部署，必須先實施持續交付。

持續部署即在持續交付的基礎上，把部署到生產環境的過程自動化。

關鍵字： CI/CD 持續集成/持續交付/持續部署

1.3 安裝配置JENKINS

瞭解網Jenkins後，如今進行Jenkins的安裝

1.3.1 環境說明

推薦的硬件配置

1 GB的RAM

50 GB的驅動器空間

系統環境

[root@Jenkins ~]# cat /etc/redhat-release 
CentOS Linux release 7.4.1708 (Core) 
[root@Jenkins ~]# uname -r
3.10.0-693.el7.x86_64
[root@Jenkins ~]# getenforce 
Disabled
[root@Jenkins ~]# systemctl status firewalld.service 
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)

軟件要求

Java 8--不管是Java運行時環境（JRE）仍是Java開發工具包（JDK）均可以。

# 可使用open jdk
[root@Jenkins ~]# yum -y install java-1.8.0-openjdk java-1.8.0-openjdk-devel
[root@Jenkins ~]# java -version
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

1.3.2 安裝Jenkins

軟件下載

官方倉庫  https://pkg.jenkins.io/redhat-stable/
清華大學開源軟件鏡像站  https://mirrors.tuna.tsinghua.edu.cn/jenkins/redhat/

下載相應的數據包便可，我這裏使用的是jenkins-2.73.1-1.1.noarch.rpm

安裝jenkins

rpm -ivh jenkins-2.73.1-1.1.noarch.rpm

啓動jenkins

/etc/init.d/jenkins start

檢查端口信息

[root@Jenkins ~]# netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1213/sshd           
tcp6       0      0 :::8080                 :::*                    LISTEN      1672/java           
tcp6       0      0 :::22                   :::*                    LISTEN      1213/sshd

RPM包安裝的內容

[root@Jenkins ~]# rpm -ql jenkins
/etc/init.d/jenkins         # 啓動文件
/etc/logrotate.d/jenkins    # 日誌分割配置文件
/etc/sysconfig/jenkins      # jenkins主配置文件
/usr/lib/jenkins            # 存放war包目錄
/usr/lib/jenkins/jenkins.war   # war 包 
/usr/sbin/rcjenkins         # 命令
/var/cache/jenkins          # war包解壓目錄 jenkins網頁代碼目錄
/var/lib/jenkins            # jenkins 工做目錄
/var/log/jenkins             # 日誌

配置文件說明

[root@Jenkins ~]# grep "^[a-Z]" /etc/sysconfig/jenkins
JENKINS_HOME="/var/lib/jenkins"    #jenkins工做目錄
JENKINS_JAVA_CMD=""
JENKINS_USER="jenkins"       # jenkinx啓動用戶
JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true"
JENKINS_PORT="8080"          # 端口
JENKINS_LISTEN_ADDRESS=""
JENKINS_HTTPS_PORT=""
JENKINS_HTTPS_KEYSTORE=""
JENKINS_HTTPS_KEYSTORE_PASSWORD=""
JENKINS_HTTPS_LISTEN_ADDRESS=""
JENKINS_DEBUG_LEVEL="5"
JENKINS_ENABLE_ACCESS_LOG="no"
JENKINS_HANDLER_MAX="100"     # 最大鏈接
JENKINS_HANDLER_IDLE="20"
JENKINS_ARGS=""

1.3.3 web界面安裝

瀏覽器訪問: http://10.0.0.64:8080

解鎖Jenkins，密碼從命令行中獲取

[root@Jenkins ~]# cat /var/lib/jenkins/secrets/initialAdminPassword
3afe5ad49a794ac2b1a72811f5eb3c9b

輸入受權密碼，而後點擊下一步

稍等一會來導安裝插件選擇的頁面，將此頁面關閉，在安裝完成Jenkins後安裝插件。

關閉安裝插件選擇後，選擇開始使用Jenkins

安裝完成，顯示界面

安裝Jenkins插件

系統管理 >> 管理插件

選擇本身須要的插件進行安裝便可，也可選擇所有安裝。

插件安裝完成後插件安裝目錄的內容

至此Jenkins安裝完成

1.3.4 Jenkins配置

1. 配置jenkins併發執行數量，提升執行效率

系統管理 >> 系統設置 >> Maven項目配置

2. 設置郵件，可以在測試完成後，主動發郵件告知測試狀況

系統管理 >> 系統設置 >> Jenkins Location

向下拉，找到郵件通知，配置郵件的smtp信息

配置完成後點擊 Test configuration 進行測試，測試成功後，點擊保存

1.4 Jenkins使用

1.4.1 建立一個新的任務

建立一個新的任務

輸入項目的名稱，選擇構建只有分風格的軟件

1.4.2 將Jenkins與gitlab聯合

gitlab的詳細安裝方法參照： http://www.cnblogs.com/clsn/p/7929958.html

建立公鑰和私鑰

[root@Jenkins ~]# ssh-keygen 
Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:5SGYye8oxCKFJjddb4W8JC0RAQhBWCvuG8aZL8eMJs4 root@Jenkins
The key's randomart image is:
+---[RSA 2048]----+
|==....=* ..      |
|...o oo==.       |
|+.= . =++.o      |
|++ o   o.+ .     |
|... o   S .      |
|o.oo   o         |
| B+ . . .        |
|++++ .           |
|+Eo.             |
+----[SHA256]-----+
[root@Jenkins ~]# cat .ssh/id_rsa.pub 
[root@Jenkins ~]# cat .ssh/id_rsa

在gitlab中添加公鑰id_rsa.pub

在jenkins中添加私鑰id_rsa

在首頁中，點擊項目名稱的下拉監聽

選擇源碼管理，先將gitlab的項目地址複製過來

選擇SSH密鑰和證書，而後選擇直接輸入，將私鑰複製到下框中便可

添加完成後，點擊保存

選擇剛纔建立的證書，完成後，選擇構建

選擇構建

拉到最底部，選擇使用shell腳本

腳本內容

建立測試環境

[root@Jenkins ~]# mkdir  -p /data/www
[root@Jenkins ~]# chown -R jenkins.jenkins /data/

選擇構建後的操做，讓每次構建完成後都將結果發送給管理員

1.4.3 測試手動集成

回到主頁，點擊右側的按鈕進行測試

部署完成

查看部署日誌

查看部署結果

[root@Jenkins ~]# ll /data/www/
總用量 4
-rw-r--r-- 1 jenkins jenkins 4 11月 30 21:22 flag
-rw-r--r-- 1 jenkins jenkins 0 11月 30 21:22 README.md

1.4.4 自動測試（gitlab主動通知Jenkins測試）

該功能會使用到一個插件 gitlab plugin

配置gitlab認證

添加一個新的憑證

從gitlab的設置中將 token複製過來

將複製的token粘貼到api token中，點ok

在系統配置中找到Gitlab 將信息進行填寫，Credentials 選擇剛剛建立對的便可

打開項目，編輯項目的構建觸發器

在gitlab上配置鏈接jenkins ，將Jenkins的Secret token 與Build URL 複製到gitlab中

保存以前先進程測試，測試成功後進行保存

在gitlab進行上傳文件，能夠測試。

在日誌中顯示是 Started by GitLab push by Administrator 即表示自動集成成功

1.5 代碼上線方案

1.5.1 早期手動部署代碼

純手動scp上傳代碼。

純手動登錄，Git pull 或者SVN update。

純手動xftp上傳代碼。

開發發送壓縮包，rz上傳，解壓部署代碼。

缺點：

全程運維參與，佔用大量時間。

若是節點多，上線速度慢。

人爲失誤多，目錄管理混亂。

回滾不及時，或者難以回退。

上線方案示意圖：

1.5.2 合理化上線方案

一、開發人員需在我的電腦搭建LAMP環境測試開發好的網站代碼，而且在辦公室或 IDC機房的測試環境測試經過，最好有專職測試人員。

二、程序代碼上線要規定時間，例如：三天上線一次，如網站需常常更新可天天下午 17點上線，這個看網站業務性質而定，原則就是影響用戶體驗最小。

三、代碼上線以前需備份，網站程序出了問題方便回退，另外，從上線技巧上講，上傳代碼時儘量先傳到服務器網站臨時目錄，傳完整後一步mv過去，或者經過In作軟連接— 線上更新代碼的思路。若是嚴格更新，把應用服務器從集羣節點平滑下線，而後更新。

四、儘可能由運維人員管理上線，對於代碼的功能性，開發人員更在乎，而對於代碼的性能優化和上線後服務器的穩定，運維更在乎服務器的穩定，所以，若是網站宕機問題歸運維管，就要讓運維上線，這樣更規範科學。不然，開發隨意更新，出了問題運維負責，這樣就錯了，運維永遠沒法擡頭。

圖·web代碼規範化上線流程圖

1.5.3 大型企業上線制度和流程

JAVA代碼環境，上線時，有數臺機器同時須要更新或者分批更新 ↓

1).本地開發人員取svn代碼。當天上線提交到trunk，不然，長期項目單開分支開發，而後在合併主線(trunk)
2).辦公內網開發測試時，由開發人員或配置管理員經過部署平臺jenkins實現統一部署，（即在部署平臺上控制開發機器從svn取代碼，編譯，打包，發佈到開發機，包名如idc_dep.war）.
3).開發人員通知或和測試人員一塊兒測試程序，沒有問題後，由配置管理員打上新的tag標記。這裏要注意，不一樣環境的配置文件是隨代碼同時發佈的。
4).配置管理員，根據上一步的tag標記，checkout出上線代碼，並配置好IDC測試環境的全部配置，執行編譯，打包(mvn,ant)(php不須要打包)，而後發佈到IDC內的統一分發服務器。
5).配置管理員或SA上線人員，把分發的程序代碼內容推送到相關測試服務器（包名如idc_test.war），而後通知開發及測試人員進行測試。若是有問題向上回退，繼續修改。
6).若是IDC測試沒有問題，繼續打好tag標記，此時，配置管理員，根據上步的tag標記，checkout出測試好的代碼，並配置好IDC正式環境的全部配置，執行編譯，打包(mvn,ant)(php不須要打包)，而後發佈到IDC內的統一分發服務器主機，準備批量發佈。
7).配置管理員或SA上線人員，把分發的內容推送到相關正式服務器（包名如idc_product.war）,而後通知開發及測試人員進行測試。若是有問題直接發佈回滾指令。

　　 IDC正式上線的過程對於JAVA程序，能夠是AB組分組上線的思路，即平滑下線一半的服務器，而後發佈更新代碼，重啓測試，無問題後，掛上更新後的服務器，同時再平滑下線另外一半的服務器，而後發佈更新代碼測試（或者直接發佈後，重啓，掛上線）

1.5.4 php程序代碼上線的具體方案

　　對於PHP上線方法：發佈代碼時（也須要測試流程）能夠直接發佈到正式線臨時目錄，而後mv或更改link的方式發佈到正式上線目錄，不須要重啓http服務。這是新朗，趕集的上線方案。

1.5.5 JAVA程序代碼上線的具體方案

對於java上線方法:較大公司須要分組平滑上線（如從負載均衡器上摘掉一半的服務器），發佈代碼後，重啓服務器測試，沒問題後，掛上上好線的一半，再下另一半。若是前端有DNS智能解析，上線還能夠分地區上線若干服務器，逐漸普及到全國的服務器，這個被稱爲「灰度發佈」，在後面門戶網站上線的知識裏咱們在講解。

1.5.6 代碼上線解決方案注意事項

 
          1).上線的流程裏，辦公室測試環境-->IDC測試環境-->正式生產環境，全部環境中的全部軟件均應版本統一，其次儘可能單一，不然將後患無窮，開發測試成功，IDC測試就可能有問題（如:操做系統，web服務器，jdk,php,tomcat,resin等版本） 
         
          2).開發團隊小組辦公內部測試環境測試（該測試環境屬於開發小組維護，或定時自動更新代碼），代碼有問題返回給某開發人員從新開發。 
         
          3).有專門的測試工程師，程序有問題直接返回給開發人員（此時返回的通常爲程序的BUG，稱爲BUG庫），無問題進行IDC測試 
         
          4).IDC測試由測試人員和運維人員參與，叫IDCtest,進行程序的壓力測試，有問題直接返回給開發人員，無問題進行線上環境上線。 
         
          5).數臺服務器代碼分發上線方案舉例（JAVA程序） 
         
          　　 A:假設同業務服務器有6臺，將服務器分爲A,B兩組，A組三臺，B組三臺，先對A組進行從負載均衡器上平滑下線，B組正常提供服務，避免服務器因上線影響業務。 
         
          　　 B:下線過程是經過腳本將A組服務器從RS池（LVS,NGINX,HAPROXY,F5等均有平滑方案）中踢出，避免負裁均衡器將請求發送給A組服務器（此時的時間應該爲網站流量少時，通常爲晚上） 
         
          　　 C:將代碼分發到A組服務器的站點目錄下，對A組服務器上線並重啓服務，並由專業的測試人員進行訪問測試，測試成功後，掛上A組的服務器，同時下線B組服務器，B組代碼上線操做測試等和A組相同，期間也要觀察上線提供服務的服務器情況，有問題及時回滾。 
         
          6).特別說明：若是是PHP程序，則上線能夠簡單化，直接將上線代碼（最好全量）發佈到全部上線服務器的特定目錄後，分發完成後，一次性mv或ln到站點目錄，固然測試也是少不了的。測試除了人員測試外，還有各類測試腳本測試各個相關業務接口。 
         
          7).大多數門戶公司的前端頁面都已經靜態化或者cache了，所以，動態的部分訪問平時就不會特別多，流量低谷時就更少了。再加上是平滑上下線，所以基本上

1.6 參考文獻

1. https://zh.wikipedia.org/wiki/持續整合

2. https://www.zhihu.com/question/23444990/answer/89426003

3. https://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/

4. http://t.cn/RYKgMtc

5. http://www.cnblogs.com/can-H/articles/7346724.html

6. https://www.abcdocker.com/abcdocker/2041

本博文中2017年11月11日以前使用的系統版本爲: CentOS release 6.9 (Final) 內核版本爲： 2.6.32-696.10.1.el6.x86_64 在2017年11月11日以後發佈的博文使用的系統版本爲: CentOS Linux release 7.4.1708 (Core) 內核版本爲： 3.10.0-693.el7.x86_64