一千萬個為什麽

搜索

詹金斯重新開始管理服務器池



我有一個服務器池來測試我的團隊擁有的供應過程。每個分支或PR需要一臺服務器。該過程需要重新啟動。一旦這個過程運行,我們運行一些測試。 Jenkins管道自動執行配置過程和測試。

所以我的問題是如何管理服務器池,以便

  1. 可為構建選擇任何可用的池服務器
  2. 聲明構建的服務器不適用於其他構建
  3. 成功構建後,服務器再次可用
  4. 失敗的版本無法使用,因此它們保留失敗的狀態以進行調查(手動返回到版本庫後)

我不能只在從節點上使用執行程序,因為我們重啟了服務器並且會終止該作業。

我目前的解決方案是:

  1. 池服務器被設置為Jenkins從屬服務器,每個執行器和一個通用標簽
  2. 一個流水線階段被分配到公共​​標簽,從一個自由執行者中選擇一個從屬 - 這個階段移動 slave.jar 以防止Jenkins重新啟動分配的從屬(它令人討厭做)
  3. 下一個管道階段使用 node.getComputer()。disconnect()來禁用slave - 看起來這必須在master上運行,所以必須處於不同的階段
  4. post {success {...}} 使用ssh將 slave.jar 移回到服務器和 node.getComputer()上。連接(true)以允許再次選擇

This mostly works and is kinda cool, but it adds a ton of noise to the pipeline and worse, suffers from a race condition between steps 2 & 3. When jobs queue up for the pool, a new one can be assigned to the same node just before a prior jobs disconnects the slave. When this happens, things break badly.

其他人是否使用Jenkins來管理需要支持池中重新啟動的服務器池,以及您如何執行此操作?

任何有關如何管理Jenkins外部池的想法,但以某種方式將分配的節點分配給Jenkins進行測試運行?我錯過的插件等

我已經檢查了Google為奴隸斷開連接問題返回的一些結果,最有前途的結果是 https://groups.google.com/forum/#!topic/jenkinsci-dev/ch2lQZvZdkw - 我的建議失敗了,因為 OfflineCause.UserCause 類可以沒有在我的管道中解決。我只知道足夠多的Java和Groovy是危險的!

轉載註明原文: 詹金斯重新開始管理服務器池

一共有 2 個回答:

對我來說,但如果我錯了,糾正我的錯誤,Jenkins服務器不應該重新啟動,但他們應該創建虛擬機並重新啟動它們。當我讀到這個問題時,我得到的印象是從機重新啟動,即我不能只使用從機節點上的執行程序,因為我們重啟了服務器,並且會終止該作業。詹金斯奴隸應該創建一個虛擬機,運行測試,重啟系統,運行一些額外的測試,並最終刪除虛擬機。

從生產的角度來看,如果我錯了,請再次糾正我的團隊沒有使用Jenkins來配置系統並隨後重新啟動節點?他們可能會使用Jenkins開始供應步驟,但他們不會重新啟動Jenkins系統?

我建議先從Production視角開始,例如目前團隊如何配置系統?例如。廚師?如果是這樣的話,他們如何運行?如果他們運行廚師申請,那麽這可以由詹金斯奴隸運行,但我不會重新啟動jenkins奴隸,但自動創建虛擬機,配置它,重新啟動並殺死它的過程。後者僅適用於測試目的。

我在可鎖定資源插件中找到了缺失的部分。

lock(label: 'server-pool', quantity: 1) {
   ...
}

現在,用於測試的服務器根本不需要作為從服務器來管理,這大大簡化了事情。