【08】Jenkins：關於發佈

寫在前面的話

 

Jenkins 對於咱們用戶而言，可能中間會有不一樣的需求，好比自動構建，接口測試，代碼質量檢測。但其實咱們的最終目的仍是打包上線。固然，各個公司的項目開發語言會不同，可是整體而言發佈方式是幾乎一致的，無論不是前端仍是後端。

 

 

插件：Publish Over SSH

 

簡單說下該插件的做用：該插件能耐容許咱們向配置好密鑰驗證的服務器發送文件，而且在遠程 Shell 的狀況下執行命令。

這就至關於該插件同時具備 scp 和 ssh 的功能。咱們能夠去插件中心搜索：

 

插件安裝完成之後，打開：系統管理 --> 系統設置

會多出 Publish over ssh 的選項：

此時咱們點擊新增，就能夠增長服務器認證，好比咱們新增一臺測試：

 

打開咱們的任務，增長髮送和包的操做，在 構建後操做 中有這樣一項：

配置說明：

 

 此時咱們點擊觸發構建：

在構建的控制檯輸出的最後，咱們能夠看到 ssh 操做，同時也能夠發現，在 ssh 以後，使用 ls -h . 命令的時候，咱們的目錄是當前用戶的家目錄。

而使用 ip 命令的時候卻發現未找到命令，這就是在這裏使用命令的一個值得注意的地方。

建議命令都寫絕對路徑，如 /usr/sbin/ip，不然可能出現找不到命令的狀況。

在執行 shell 腳本的時候，也建議在腳本前面添加 /bin/sh。

鏈接服務器查看發送狀況：

能夠看到文件成功發送到了遠程服務器。

 

 

關於後續更新

 

在將更新包發送到遠程服務器之後，接下來的操做即是更新，這裏就不給具體的腳本了，只給一些本身在使用過程當中的以及設計的建議：

假如在遠程服務器上面存在 Tomcat 應用服務地址：/data/service/tomcat-8080

1. 咱們在設計目錄結構的時候，建議設計三個目錄：

目錄	做用
/data/service/tomcat-8080	應用目錄
/data/deploy/tomcat-8080	更新包傳輸臨時存放目錄
/data/backup/tomcat-8080	舊版包歸檔目錄

 

2. 更新過程大體以下：

發送更新包到臨時目錄 --> 解壓更新包到指定的名稱 --> 中止應用服務 --> 備份舊版包到備份目錄 --> 解壓的新版包移動到應用目錄  --> 啓動服務 --> 發送更新信息

簡單說明：

發送更新包到臨時目錄：就是以前咱們使用的 Publish Over SSH 發送文件。

後續的步驟都是在 Publish Over SSH 中執行命令時候執行遠程服務器上面的腳本實現，該腳本的功能包括解壓包，停服務，備份，更新，啓動，發送通知。

對於發送通知，咱們這裏依然採用釘釘機器人 webhook 的方式：

對於通知消息，建議設置兩個機器人，一個用於通知成功，一個用於通知失敗以及失敗緣由。

這樣是爲了當項目多了起來，一次可能得更新多個項目，爲了更好的就行區分通知類型。

 

3. 規範化管理服務器。

咱們在設計服務器的時候就要求服務器設計目錄的一致性，這樣可以減小咱們不少沒必要要的操做，好比我第一條中的目錄結構設計。這樣的好處在於，我當前公司的發佈腳本一共只有 4 個，這仍是爲了維護方便的狀況分紅的 4 個：

一個是傳統 NG 代理的前端靜態發佈腳本，一個是 nodejs 啓動的前端服務發佈腳本。

一個是傳統 Tomcat 服務更新發布腳本，一個是 Springboot 微服務啓動發佈腳本。

這其中又涉及多項服務，可是腳本至始至終就這幾個，每一個構建咱們經過傳遞兩到三個不一樣參數用於區分不一樣項目。

由於目錄結構，設計都相似，因此參數也很是簡單。

 

4. 腳本集中管理。

當咱們又不少機器的時候，咱們不能將腳本存儲在服務器本地。不然咱們修改腳本就意味着須要修改每臺機器上面的腳本，這樣工程量很大。個人建議是在發佈傳輸更新包以前多一步操做，就是傳輸更新腳本。這樣可以時刻保持腳本是最新狀態。且腳本都在 Jenkins 服務器上面保存，集中管理。

 

5. 關於回滾操做。

對於回滾操做，因爲咱們每次都有對服務包作備份，並將備份按照指定 tag 進行了歸檔，因此咱們依然能夠採用腳本的形式，將舊版本重新從備份目錄更新到應用目錄下面。而且咱們能夠經過指定 tag 傳參的形式回滾到指定版本。

 

 

小結

 

整個發佈流程大體如此，固然咱們可能在不少地方看到 Deloy to container 這個插件，其實它沒用 Publish 那麼好用。

至於我的本身公司的發佈方式到底怎麼取捨仍是看我的，我這裏就是一些建議。