CMDB是配置管理數據庫的簡稱，本文所闡述的CMDB只專注於存儲運維相關的資源數據，有別於應用系統的配置管理。實際上企業一般都是自己內部的運維團隊按照公司的運維場景需求設計和構建的CMDB，因為很少能有開源產品能滿足他們的需求，或者是個性化的需求二次開發比較難易實現，所以他們都選擇了自主研發，而不是使用開源！
因此，要實現一個儘可能通用、靈活、可擴展的運維資源數據的配置和管理系統，系統必須要滿足:
1. 運維人員能根據企業的應用場景和需求，自己去構建存儲的數據模型，以及模型之間的關係
2. 提供豐富的API，尤其是在數據和關係檢索要做到通用，便於二次開發
3. 用戶可以方便的訂閱自己關心的數據
基於上述理念，設計並實現了一個CMDB，並開源出來，希望能得到大家的積極反饋，系統將持續不斷的改進，UI上還有大量工作需要去完成。
源碼: https://github.com/pycook/cmdb
具體安裝和使用見README
總體架構
圖1. CMDB總體架構
如圖1，CMDB自下而上被劃分為4層: 存儲層、數據層、API、UI，圖中的CIType可以理解為數據模型，例如物理機、虛擬機、應用、網卡、軟件等。CI是配置項，即CIType的實例, 例如具體的1臺物理機就是1個CI。下面概要介紹一下這4層。
存儲層：主要用來存儲CIType和CI，以及它們之間的關係。
· Mysql: 所有數據的持久化存儲
· Redis: 數據緩存，主要是用戶、屬性、CIType、權限等的數據緩存，減少Mysql訪問壓力，提升API的響應速度
· Elasticsearch: 主要存儲CI的實例數據，用來檢索CI。實際上ES是一個可選的方案，CI數據的檢索默認是通過Mysql+Redis來實現的，當然CI的實例數若超過一定數量級，考慮到查詢效率，建議使用ES。
數據層：描述了模型數據和實例數據，以及它們之間的關係。在這一層首先需要運維按照具體的應用場景來完成模型的構建。模型包括屬性，屬性有不同的值的類型，且有一些檢驗規則，比如唯一、必須等的校驗，在系統層面避免髒數據的錄入。總結下來，運維CMDB實際上主要包括下面4種類型的數據：
1. 硬件數據：物理機、宿主機、機櫃、網絡設備、網卡、硬盤、內存等等
2. 軟件數據：docker、mysql、redis、tomcat等等
3. 業務數據：應用、產品線、事業部等等
4. 關係數據：上面3種類型數據之間的關係
當然，每個公司的運維場景各異，用戶都可以按照自己的需求來設計數據模型。
API層: 對UI提供一套統一、透明的調用接口，對下層各數據模塊實行接口抽象與封裝。要儘可能實現通用，要求CI和CI relation的查詢API必須做到通用和靈活，要考慮到用戶各種各樣的查詢需求，本系統實現了對應的2個API，基本上滿足了前端對數據查詢的所有需求。
UI層: 實際上就是web portal，用戶直接訪問CMDB的門戶。核心功能主要包括：模型配置、資源視圖、關係視圖、樹形視圖和權限管理這5個核心模塊。下面將對這5個功能模塊進行闡述。
模型配置
圖2. 動態建模
除非是大型的成熟的企業，否則很難在開始就完全能夠定義清楚運維的數據模型。因為企業在不斷成長和發展的過程中，運維的場景和需求也是在不斷的變化的，所以，通用的CMDB一定要能夠讓管理員方便對CIType進行動態的修改。如圖2所示, 要完成動態建模，至少要能增刪改CIType，給CIType定義屬性，也可以從屬性庫直接複用已存在的屬性，屬性可以有校驗規則，以便儘可能保證數據的準確性。屬性值的類型支持以下5種：
1）整數類型
2）浮點數
3）日期類型: date, datetime, time
4）文本類型
5）json類型
此外，還可以構建CIType之間的關係，比如事業部包含產品線，產品線包含應用，應用部署在物理機，應用部署在docker上。
圖3. 模型增刪改
圖4. 模型屬性的定義
上圖3和圖4分別是對CIType的增刪改和CIType的屬性進行定義。下圖5則是對關係視圖進行定義，比如構建服務樹，這個將在下面關係視圖進行詳細的闡述。
圖5. 關係視圖的定義面板
資源視圖
資源視圖即CI數據的檢索。為了保證系統的通用、靈活，CI數據檢索的API要能按照CI的屬性進行各種條件過濾查詢，而且這個API要儘可能覆蓋用戶不同的查詢需求。CI的通用查詢API實現了搜索表達式的查詢，表達式支持AND、OR、NOT、IN、RANGE、COMPARISON的組合查詢，如圖6所示。具體的CI查詢API使用說明見：
https://github.com/pycook/cmdb/blob/master/docs/cmdb_query_api.md
圖6. CI通用搜索
如圖7，用戶能夠訂閱自己關心的資源視圖，比如物理機、應用等。圖8則是用戶訂閱的資源視圖的數據展示，我們可以根據屬性字段查詢，另外也提供了批量修改、下載、刪除等操作，也可以查看CI的生命週期，以及它的關聯CI。
圖7. 用戶訂閱關心的資源視圖
圖8. 資源視圖
樹形視圖
樹形視圖實際上是資源視圖按照樹形目錄的方式來進行展示。 用戶可以訂閱某一個CIType按照不同屬性分level來展示，比如物理機，我們可以定義: IDC -> 環境 -> 狀態 3個屬性分層的視圖，如圖9所示，用樹形展示。這樣方便了不同角色的用戶可以按需來設計資源的統計展示方式，樹形視圖是單類CI實例數據的展示，不涉及到CI之間關係。
圖9. 樹形視圖
關係視圖
關係視圖是CI之間的關係，並用樹形的方式來進行呈現。同樣為了保證系統的通用性，CI關係查詢和CI實例的查詢API一樣要靈活且通用，本系統實現的CI關係查詢API是使用方法類似於上文提到的CI的查詢API，只不過多了2個參數：root_id 搜索的根節點的ci_id和level搜索的層級，也就是說可以從某一個CI出發，去查詢離該CI任一level的CI，如圖10所示。從根節點root出發可以搜索level=1的關係節點，也可以直接搜索level=2或者n的任一一層節點。具體的API使用說明見：
https://github.com/pycook/cmdb/blob/master/docs/cmdb_query_api.md
圖10. 關係查詢
關係視圖是由管理員根據需求來進行定義，然後授權給不同的角色來使用。舉個例子: 事業部 -> 產品線 -> 應用 定義這樣的一個關係視圖,我們命名為服務樹, 樹的節點是這3層CI, 具體的數據展示是應用下面的所有資源，可以是物理機，也可以是docker，如圖11所示。
圖11. 關係視圖
權限管理
權限管理：系統提供了基於角色的訪問權限控制，支持角色繼承，其設計也是比較靈活，可以按需實現比較細粒度的權限控制，目前可以按照CIType和關係視圖來進行權限控制，主要包括增、刪、改、查的權限控制。
圖12. 權限管理
閱讀更多 運維雜談 的文章
