1. 程式人生 > >從無到有:熊貓直播 Rancho 釋出系統構建之路

從無到有:熊貓直播 Rancho 釋出系統構建之路

本文由高效運維社群熱心群友投稿整理髮布,高效運維社群致力於陪伴您的職業生涯,與您一起愉快的成長。

作者介紹:

符傑超
熊貓直播 基礎架構部高階運維開發工程師
主要負責熊貓直播運維自動化架構平臺建設和開發

前言:

隨著熊貓直播的業務發展越來越快,業務需求的迭代和版本更新需求越來越多,對開發和運維面臨以下4個痛點:

  1. 專案需求上線越來越多。
  2. 釋出週期比較長,需要人工操作比較繁瑣。
  3. 釋出專案效率和風險的問題,比如平滑釋出,切換負載均衡。
  4. 釋出過程沒有詳細的審計功能。

由此,團隊內部決定在現有的釋出過程上實現開發統一的釋出系統平臺,實現熊貓直播的運維釋出流程化、標準化、自動化為一體的統一發布要求,下面圍繞整個 Rancho 釋出系統做總結梳理,總共分為9個方面:

  1. 實現的最終目的
  2. 使用者登陸(釋出系統的第一道安全牆)
  3. 使用者許可權(釋出系統的第二道安全牆)
  4. 專案許可權(釋出系統的第三道安全牆)
  5. 程式碼釋出前臺
  6. 程式碼釋出後臺
  7. 釋出過程/結果
  8. 標準的 wiki 文件建立
  9. 小結

Rancho 釋出系統流程概述架構圖:

Rancho

Rancho 釋出系統流程完整架構圖:

架構

一、實現的最終目的

隨著熊貓直播業務的迅猛發展,專案、產品的需求規模和版本迭代頻次是無法預估的。傳統的運維支援方式已漸漸無法滿足這種工程應用現狀。但是如果把釋出權利交付到開發人員手裡控制,運維安全是比較大的隱患。當2者都無法平衡的時候,利用高效的標準化,自動化體系將2個無法逾越的問題優化結合起來,我們結合了上述問題,實現了內部的釋出系統,對於釋出系統,實現了2個核心目標,如下:

  1. 釋出專案統一接入
    在新專案接入平臺的第一次起,運維只需要把專案新增上,給對應的開發開放相對應的釋出許可權,專案接入+許可權都是正常狀態下,運維需要做的事情就完成了。
  2. 一鍵自動釋出
    開發可以根據自己所擁有的專案釋出許可權,進行任何時間段的釋出,同時釋出系統會對使用者,釋出專案,釋出操作,結果做到全方位的記錄。

總結:讓研發自助運維。

二、使用者登陸(釋出系統的第一道安全牆)

對於釋出系統的登陸,我們結合了內部開發的一套 SSO 系統+Rancho 系統並加了一層白名單策略,有以下3個方面考慮:

  1. 安全性:
    平臺登陸安全性,SSO 採用統一認證+MD5 演算法+Hash演算法+靜態系統唯一標識。
  2. 連線:
    統一的 Session/Cookie 允許連線,保持會話,過期,刪除由SSO管理。
  3. 雙權驗證:
    假如使用者在 SSO 可以正常登陸,但是在 Rancho 釋出平臺沒有登陸許可權,就是禁止登陸。原因很簡單,因為全公司每個人都擁有自己的統一登陸賬戶,防止有人試探登陸/誤操作登陸。

三、 使用者許可權(釋出系統的第二道安全牆)

使用者許可權,我們分為2類角色:

  1. 管理員:
    具有釋出系統超級許可權,可以對所有專案/使用者進行操作。
  2. 普通使用者:
    只能看到運維授權的專案,釋出,釋出詳情,檢視釋出歷史,查詢,但是不可編輯,更新專案。

四、專案許可權(釋出系統的第三道安全牆)

專案許可權設計,我們當時也花很多時間去討論,最終擬定方案,專案不首先對應使用者,而是在使用者和專案中間建立一個橋樑,我們命名為專案組。

原因:當多個使用者同時去擁有一個專案許可權的時候,這個時候要全部使用者都要增加到這個專案體系中去。

如果這樣做的問題是:增加繁瑣,當專案刪除改使用者許可權/或者使用者不再擁有該專案許可權,還要精確的刪除,否則刪除錯了,後果很嚴重,邏輯同時還要對使用者和專案,做雙層處理操作。

解決方案:

使用者—-專案組——專案

方案優點:

  1. 專案組方便了運維管理,如果沒有專案組,一個專案對應的許可權使用者比較多的話,需要管理員分別的去增加/更新編輯比較繁瑣。
  2. 系統根據專案組有效控制不同使用者之間對應專案的許可權隔離釋出。

專案組圖例:

五、程式碼釋出前臺

前臺用於開發人員進行釋出所操作的頁面,其中功能包含:

  • 釋出頁面
  • 釋出tag種類選擇
  • 釋出環境/機器列表選擇

當用戶進來某個專案的時候,Rancho 釋出系統會同時非同步獲取該專案所有的環境/主機列表,對使用者而言無需任何操作處理。

①. 釋出頁面

支援機器單選,多選,全選,臨時主機新增等:

②. 釋出tag種類

釋出 tag 種類選擇如下:

  • 開發tag(可測試)
  • 線上tag(灰度/線上)
  • 其他tag(代表開發/線上 tag 未顯示你要釋出的 tag,釋出人員可以根據 tag號輸入,如果 git 庫裡存在,可以正常釋出,如果不存在,使用者也可以接收到對應的錯誤結果)
  • 線上/開發tag,Rancho 釋出系統會自動實時更新git庫前10個最新的tag,供使用者選擇。

③. tag 版本選擇頁面

如下:

tag

④. tag 比對圖

使用者選擇的 tag 和主幹,和最後一次釋出 tag 比對如下:

⑤. 釋出環境/機器列表選擇:

對於釋出環境我們有自己的一套命名擴充套件規則,有3種類型:

  • 型別一:根據專案功能服務來命名
  • 型別二:根據釋出環境來命名
  • 型別三:前2者整合

比如某個專案命名情況:

  • 專案功能服務拆分,包含:crontab,sdk,console,front等,
  • 專案釋出環境拆分,包含:online,beta,gray等

獨立情況/整合情況,如下說明:

  • beta環境可以獨立的命名
  • beta環境有sdk服務,命名為:sdk_beta
  • beta環境有console,命名為:beta_console

PS:環境命名,細化,拆解,開發人員根據專案功能型別,自定義,
Rancho自動識別和拆解命名體系。

每個釋出環境對應釋出的機器,其中一個專案頁面如下展示:

⑥. 前臺首頁圖

使用者登陸進來看到的所擁有專案的頁面,功能有釋出,檢視,釋出歷史,需說明(只有管理員才有展示啟用/禁用許可權)

啟用:代表這個專案是正常執行釋出
禁用:可以看作刪除,但是我們不作為真正刪除,臨時遷入回收站,如果哪天這個專案需要啟用釋出了,我們再開啟進行該專案釋出。

⑦. 前臺釋出確認清單

釋出前讓釋出使用者再次確認上線的專案,tag,釋出環境,是否重啟,機器(現有的和臨時新增的主機):

⑧. 釋出清單提交請求

避免髒資料的方法:

  • 程式監控對釋出佇列是否正常服務檢測,並且自動做干預。
  • 程式監控對資料庫/快取正常服務檢測,並且自動做干預。
  • 程式監控對生成的task_ID是否存在,並且自動做干預。
  • 程式監控對生成的釋出指令做嚴格的判斷,是否為不正確指令,並且自動做出干預。

六、程式碼釋出後臺

  1. 後臺專案管理的成功/失敗,對整個前臺釋出起到至關重要的。
  2. 後臺操作許可權為管理員:一般是指定對應的運維人員。
  3. 操作程度:簡單、易用,所有處理邏輯都交給Rancho去搞定。

①. 後臺操作新專案流程頁面

新建欄位說明:

名稱:代表專案的主名稱(唯一,如果重複則提示錯誤詳情),別名:代表專案的描述,可以是中文/英文,名稱可以重複。

git clone url地址:
開發提供,這個地址Rancho在處理的過程中,會對本身專案許可權,該專案型別標識進行判斷和提取,比如我們有2種功能釋出:rigger和ansible,而釋出語言有:golang,php,nodejs,python,lua,c++等多種混合語言,排名不分先後。

專案組許可權:
新增該專案允許哪些專案組成員進行釋出。

備註:可寫/可不寫

至此,運維管理員需要做的事情已經完成,剩下的點選提交,剩下的事情交給 Rancho 去處理了。

②. 後臺新建頁面

③. Rancho底層基本處理流程

流程

④. 專案失敗手動觸發 Rancho 處理恢復流程

Rancho

七、釋出過程/結果

前期的工作:後臺新建專案完成,到釋出提交申請,最後檢視釋出過程/結果的驗證。

①. 釋出過程的處理流程概述和原理圖例展示:

描述,釋出過程有3種場景負載均衡四/七層策略和無負載均衡策略/專案服務是否重啟。針對以上3種場景,分別作了不同的處理規則:

  1. 負載均衡場景:
    有白名單策略代表該專案擁有負載均衡策略(至於掛了多少負載均衡節點在釋出的時候,Rancho 釋出系統會自動的計算,並且做相對應的平滑策略切換).
  2. 無負載均衡策略:
    走正常的釋出流程。
  3. 專案服務釋出是否重啟
    (Rancho 支援重啟專案服務/支援不重啟專案服務)需求描述:
    熊貓直播發布專案的時候,有2種情況:
  • 專案釋出更新,但是不重啟服務,看下專案程式碼釋出過程是否成功/失敗。(這點對於釋出專案業務正常執行不會出現有損情況)
  • 專案釋出更新,重啟服務(專案釋出程式碼完成,自動重啟專案服務)

釋出速度:無負載均衡策略專案相對於比有LB策略的專案快2ms-30ms,根據專案繫結的LB有關聯。

②. 專案釋出鎖圖例展現

釋出鎖作用:防止同項目同釋出環境多工一起釋出,會有覆蓋,衝突。

③. 專案釋出歷史統計圖例展現

狀態:正在釋出,觸發失敗,釋出成功

④. 專案釋出手工終止圖例展現

⑤. 釋出結果成功圖例展現

⑥. 釋出結果失敗/終止圖例展現

失敗單臺,未執行的機器程式自動干預停止釋出例項子

⑦. 釋出過程中,手工可以終止釋出功能,說明

  1. 防止釋出過程中有未知的原因或長時間緩慢/卡頓等,釋出人員可以根據業務重要評估,進行降級釋出過程停止操作,並且系統會把操作使用者,時間,專案,降級操作等做詳細記錄)。
  2. 正常釋出完成後,終止釋出按鈕功能會自動消失.
    下面截圖所示:

⑧. 專案回滾策略

當某個專案釋出失敗或者異常,想回滾到上個正常版本,可以以對應的 tag 號來進行重新發布.

⑨. 釋出結果日誌截圖展現

(自動按天生成日誌,並且按天做釋出日誌全量彙總)

日誌

八、完善的Wiki文件建立

Rancho 釋出系統在熊貓直播循序漸進的優化功能/需求,bug修復等,wiki文件的規範化也要隨之建立起來,以下是wiki文件建立的圖例:

Wiki

九、小結

Rancho 釋出系統已經在線上運行了將近5個月的時間,目前 Rancho 系統功能包含了:

  • 專案建立
  • 使用者登陸許可權嚴格的隔離
  • 專案鎖機制
  • 專案前臺
  • 專案後臺
  • LB 4/7層和 Nginx upstream 白名單策略
  • 平滑摘取/繫結主機
  • 支援Rigger釋出功能和Ansible釋出功能
  • 多語言混合並行釋出(Golang,PHP,Nodejs,C++,Lua,Python,Shell等,語言排名不分先後)
  • 非同步實時處理髮布任務
  • 實時視覺化展現釋出結果
  • 多環境釋出
  • 跨多機房釋出
  • 手工/自動干預終止釋出
  • 避免嚴重的錯誤影響到正常業務
  • 詳細的釋出操作記錄:使用者操作,時間,釋出環境,釋出tag,釋出主機成功次數統計,釋出主機失敗次數統計,釋出主機程式自動干預終止次數統計,釋出主機手工干預終止次數統計,釋出主機正在釋出中次數統計等。

目前熊貓直播 Rancho 釋出系統解決的痛點:

  1. 研發自助運維:熊貓直播產品業務線的釋出更新/回滾變更等操作,都由各自的專案線開發人員操作釋出/回滾,運維不直接參與整個釋出/回滾流程,遇到釋出錯誤/異常,運維才介入和開發一起排查相關問題。
  2. 釋出時間週期長:目前釋出系統非同步處理整個釋出流程,點擊發布提交之後,頁面關閉都可以,釋出人員想看結果的時候,才登陸系統檢視即可。
  3. 平滑切換負載均衡:釋出系統增加了白名單策略,釋出專案上線前,Rancho釋出系統會自動判斷白名單策略專案,如果該專案存在白名單策略,Rancho釋出系統會自動做整個負載均衡下線—上線—繫結上線流程操作。
  4. 釋出系統詳細的審計功能:從使用者登陸-建立釋出清單-點擊發布-釋出過程-釋出結果都做了詳細的記錄,記錄緯度:登陸時間,釋出起始時間,釋出完成時間,使用者,釋出環境,釋出專案(平滑,服務是否重啟,tag,主機數量,主機資訊清單),釋出結果(成功,失敗,終止)等。

目前釋出次數/專案總數統計: 2017年2月16日上線到目前,累計釋出工單12000次,最多單次工單釋出主機100臺+,成功96%,失敗3%,終止1%,接入釋出專案將近100+

Rancho 釋出系統未來優化的路還有很多,優化方向分為以下3點:

  1. 接入釋出預警平臺:
    當某個專案出現異常的時候,運維能及時收到簡訊/郵件的提示。
  2. 定時作業釋出:
    可以按照使用者自定義的釋出時間,定時釋出程式碼。
  3. 釋出錯誤/異常自動修復:
    目前Rancho釋出系統,已經可以收集到全部錯誤釋出型別,但是真正修復還需人工,以後當錯誤出現了,自動上報到修復庫裡進行存檔,在下一次同樣錯誤出現的時候,Rancho 自動修復,並優雅提示使用者釋出錯誤修復完成,請重新發布。

文章來自微信公眾號:高效運維