尽可能通用的运维CMDB的设计与实践
CMDB是配置管理数据库的简称，本文所阐述的CMDB只专注于存储运维相关的资源数据，有别于应用系统的配置管理。实际上企业一般都是自己内部的运维团队按照公司的运维场景需求设计和构建的CMDB，因为很少能有开源产品能满足他们的需求，或者是个性化的需求二次开发比较难易实现，所以他们都选择了自主研发，而不是使用开源！
因此，要实现一个尽可能通用、灵活、可扩展的运维资源数据的配置和管理系统，系统必须要满足:
运维人员能根据企业的应用场景和需求，自己去构建存储的数据模型，以及模型之间的关系
提供丰富的API，尤其是在数据和关系检索要做到通用，便于二次开发
用户可以方便的订阅自己关心的数据
基于上述理念，设计并实现了一个CMDB，并开源出来，希望能得到大家的积极反馈，系统将持续不断的改进，UI上还有大量工作需要去完成。
在线Demo: http://121.42.12.46:8000 用户名: demo 密码: 123456
具体安装和使用见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使用说明见：
图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使用说明见：
图10. 关系查询
关系视图是由管理员根据需求来进行定义，然后授权给不同的角色来使用。举个例子: 事业部 -> 产品线 -> 应用 定义这样的一个关系视图,我们命名为服务树, 树的节点是这3层CI, 具体的数据展示是应用下面的所有资源，可以是物理机，也可以是docker，如图11所示。
图11. 关系视图
权限管理
权限管理：系统提供了基于角色的访问权限控制，支持角色继承，其设计也是比较灵活，可以按需实现比较细粒度的权限控制，目前可以按照CIType和关系视图来进行权限控制，主要包括增、删、改、查的权限控制。
图12. 权限管理
