DevOps專題|基礎Agent部署系統
隨著京東雲業務規模、管理機器規模的擴大，各類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上線分級釋出。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69912185/viewspace-2670878/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- devops系統自動化部署流程dev
- IDEA + maven 零基礎構建 java agent 專案IdeaMavenJava
- DevOps專題 | 大型企業級監控系統設計dev
- OCSInventoryNG使用之在windows系統下AGENT的批量部署（二）Windows
- Python在Windows系統下基於Scrapyd部署爬蟲專案(本地部署)PythonWindows爬蟲
- 【IOS開發基礎系列】Cocoa基礎專題iOS
- Azure Terraform（五）利用Azure DevOps 實現自動化部署基礎資源ORMdev
- 分散式系統基礎分散式
- Linux系統基礎Linux
- JavaWeb基礎總結：Servlet專題JavaWebServlet
- 專題十二 基礎DP1 題集
- DevOps專題|Packer使用教程dev
- 基於OT開發系統的專利問題
- windows下部署12c oms agent 及清除agentWindows
- 基於AWS-ELK部署系統日誌告警系統
- Azure Terraform（七）利用Azure DevOps 實現自動化部署基礎資源（補充）ORMdev
- Centos7系統部署django專案CentOSDjango
- Dart基礎系統學習Dart
- 作業系統基礎配置作業系統
- 本地部署modelscope-agent
- TensorFlow系列專題（二）：機器學習基礎機器學習
- TensorFlow系列專題（一）：機器學習基礎機器學習
- 機器學習基礎專題：支援向量機SVM機器學習
- ?【Java技術專區】「探針Agent專題」Java Agent探針的技術介紹（1）Java
- 基礎的學生成績查詢系統製作問題
- zabbix agent 3.0部署文件 安裝部署
- Linux系統（三）系統基礎掃盲大全Linux
- 基礎夯實：作業系統作業系統
- Linux作業系統基礎Linux作業系統
- Python基礎：常用系統模組Python
- 面試CS基礎之作業系統面試作業系統
- linux檔案系統基礎Linux
- 2018年智慧機器人技術綜合實訓專題一系統基礎機器人
- Linux詳解（基礎、環境配置、專案部署入門）Linux
- 《資訊保安系統設計基礎》第二週問題總結
- 基礎題
- Devops 開發運維基礎篇之Jenkins部署與使用dev運維Jenkins
- FineUI經典專案展示（2）基礎管理系統（附線上演示）UI