隨著京東雲業務規模、管理機器規模的擴大，各類agent也在逐漸增多，如日誌agent、監控agent、控制系統agent等。這對agent的部署、公升級、狀態維護提出了很高的要求，一旦某個全域性agent進行了錯誤地部署、公升級，可能會導致agent的資源使用率過高，進而會對全公司的業務產生影響。在此背景下需要有乙個統一管理系統來對全網agent的部署、公升級進行管控，可以靈活的指定不同的發布策略進行灰度更新，如按照pin層面公升級、按照集群層面等等。基於此，京東雲自研了ifrit系統用於全網agent的部署、公升級和狀態維護。
ifrit是阿拉伯神話中一種遇火而生，浴火重生的精靈，只有英雄才有駕馭它的能力。這裡的「火」可以指代全網每乙個節點，「英雄」則可以指代管理員。此外，阿拉丁神話中的「燈神」就是一種ifrit，燈神可以幫阿拉丁實現願望，京東雲ifrit系統也可以幫助我們管理節點。ifrit 架構自上而下分為ifrit-manage、ifrit-master、ifrit-agent三大模組，如下圖所示：
ifrit-agent：負責本機所需業務agent以及ifrit-agent本身的部署、公升級、狀態維護，定期從ifrit-master中拉取本機agent配置用以管理本機所有agent。配置完成後向ifrit-master匯報本機的agent狀態資訊。
ifrit-master：每個集群內部署一套master，向上提供ifrit-manage發布部署、更新指令和agent狀態查詢介面；向下為本集群內所有ifrit-agent提供agent配置資訊查詢和agent狀態回傳介面。
ifrit-manage：向使用者提供web介面，在該頁面可以對指定agent進行灰度更新和全量更新、檢視操作記錄等。
ifrit-agent
ifrit-agent設計目標：
• 定期獲取agent配置資訊並向master匯報agent狀態資訊
• 安裝
• 解除安裝
• 公升級
• 安裝包完整性檢測
• 例項存活檢測
• 自公升級
• 自守護
由於幾乎所有部署、監控等相關功能都依賴於agent，ifrit-agent在機器中以服務形式存在並且開機自啟動。若ifrit-agent啟動時網路服務未啟動。則會導致機器在數分鐘內無法使用部署、監控、日誌服務等功能，同時也無法採集到docker容器類應用的初始化日誌，因此ifrit-agent啟動時配備重試機制，以確保網路服務已經啟動。
ifrit-agent在訪問master介面獲取期望agent狀態資訊時，需要帶上機器型別和機器uuid(例如內網中的ip、雲主機上的instance-id等)。其中機器型別(主要是作業系統、cpu架構)可通過初始化時執行命令獲取，或使用golang中的條件編譯將機器型別直接寫在程式中。
ifrit-master
ifrit-master負責agent管理工作，全網部署agent的增刪查改都是通過ifirt-manage呼叫ifrit-master介面完成的。當集群規模增大時，直接讀取mysql獲取agent版本資訊會對資料庫造成很大壓力，為了避免這類問題，ifrit-master中採用redis快取，以固定時間間隔讀取mysql中agent版本資訊，並合成為ifrit-agent可直接讀取的資料快取到redis，如下圖所示：
為了減少因agent公升級導致的全網業務故障，ifrit-master提供了灰度發布機制，即指定一批機器更新agent到指定版本灰度執行。待灰度驗證通過後，在集群內全量部署該agent。同時，ifrit系統可以根據不同機器型別部署不同的業務agent，目前京東雲內支援了容器、linux物理機、arm64架構機器和windows系統機器。
ifrit-manage
ifrit-manage統一管理多個集群的master，主要功能如下：
• 使用者許可權管理
• 分級發布（集群粒度）
• agent狀態查詢
• 操作審計
ifrit-manage本身作為運營後台的一部分，可讀許可權由運營後台統一管理。ifrit寫操作是高危操作，預設只有超級管理員（一般為公司運維人員）有寫許可權，其他人員可以通過在配置檔案中新增寫許可權。
根據業務需要，可以將機器劃分到不同集群中，當有agent需要變更時，運維人員在灰度驗證通過後，按照給定的集群順序分集群進行部署。運維完成乙個集群的agent部署後，15分鐘內（ifrit-agent主迴圈週期+ifrit-master redis快取週期）該集群內所有指定型別機器應當變更生效，運維驗證部署生效後方可對下乙個集群進行部署。
以上的ifrit系統已經具備了集群粒度的分級發布功能，但是隨著集群規模越來越大，集群粒度的agent上線仍然有很大風險，因此需要一套更細粒度的分級發布機制，以便於降低agent上線事故帶來的影響。
ifrit中根據集群規模大小，使用一致性hash演算法將集群中的機器均勻分成若干批，並分批上線。一致性hash演算法是hash演算法的改進，和普通hash演算法的關鍵區別是，對於節點和資料(ifrit中使用機器uuid)都做一次hash運算，並比較節點和資料的hash值，順時針方向取距離資料點的節點。若hash後的節點分布不均勻，可通過引入虛擬節點增大節點數目，從而使得散落在hash環上的節點更加均勻，如下圖。
集群分批完成後，集群內進行agent全量上線時首先進行小流量驗證，驗證通過後按照一定時間間隔更新redis快取資訊，新增鍵值expect_default_hash1_container等。此時ifrit-agent獲取agent版本資訊的優先順序為：灰度資料》hash資料》全量資料（時間戳相同的情況）。還可以通過暫停更新/刪除redis中hash型別的資料，實現agent上線的暫停與回滾(操作mysql資料間接實現)。
自此，ifrit實現了單集群內的agent上線分級發布。
DevOps學習一 基礎概念
從事軟體開發不少年頭，從15年開始逐漸轉管理，很少實際程式設計，也極少動手寫心得體會了。最近的閱讀有所感慨，光讀不寫實際上並不知道自己是否理解，是否有所提高，計畫慢慢講最近的學習和心得通過文章做個記錄。1 藍綠部署 正常的程式更新上線，需要暫停原有伺服器端服務，上傳部署包再重新啟動服務，這期間服務都...
DevOps基礎之持續改善
在devops中，我們喜歡日語單詞。主要是因為精益在日本得到了如此強烈的採用，我們從他們那裡得到了大量的借鑑。像andencord和kaizen。kaizen是乙個受歡迎的開發者文化實踐。kaizen字面意思是變得更好。我們可能會將其粗略地翻譯為持續改進。kaizen是豐田汽車生產系統著名的精益模型...
DevOps專題 大型企業級監控系統設計
10月30日，全球權威資料調研機構idc正式發布 idcmarketscape 中國devops雲市場2019，廠商評估 報告。京東雲憑藉豐富的場景和實踐能力，以及高質量的服務交付和平台穩定性，取得優異出成績，躋身 major players 核心廠商 位置。京東雲devops能力起源於自身的業務實...