由于企业运维场景各异，开源CMDB要能满足运维的需求，通用灵活、简单易用是必要条件。
因此，要实现一个尽可能通用、灵活、可扩展的运维资源数据的配置和管理系统，系统至少要满足:
- 运维人员能根据企业的运维场景和需求，自己去构建存储的数据模型，以及模型之间的关系
- 提供极简API，尤其是在数据和关系检索要做到通用，便于数据消费
- 有丰富的图表展示，满足个性化的定制需求
- 数据的自动发现，确保数据权威性
- 细粒度的权限控制，满足安全合规的要求
以下从总体架构、模型配置、数据可视化、自动发现、权限管理这5个方面来介绍。
01总体架构
CMDB总体架构
如图可见CMDB的总体架构，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个核心模块。 02 模型配置
动态建模
除非是大型的成熟的企业，否则很难在开始就完全能够定义清楚运维的数据模型。因为企业在不断成长和发展的过程中，运维的场景和需求也是在不断的变化的，所以，通用的CMDB一定要能够让管理员方便对CIType进行动态的修改。如图2所示, 要完成动态建模，至少要能增删改CIType，给CIType定义属性，也可以从属性库直接复用已存在的属性，属性可以有校验规则，以便尽可能保证数据的准确性。属性值的类型支持以下5种：
- 整数类型
- 浮点数
- 日期类型: date, datetime, time
- 文本类型
- JSON类型
此外，还可以构建CIType之间的关系，比如事业部包含产品线，产品线包含应用，应用部署在物理机，应用部署在docker上。
模型增删改
模型属性的定义
图3和图4分别是对CIType的增删改和CIType的属性进行定义。下图5则是对关系视图进行定义，比如构建服务树，这个将在下面关系视图进行详细的阐述。
图5. 关系视图的定义面板
03数据可视化
3.1 资源视图
资源视图即CI数据的检索。为了保证系统的通用、灵活，CI数据检索的API要能按照CI的属性进行各种条件过滤查询，而且这个API要尽可能覆盖用户不同的查询需求。CI的通用查询API实现了搜索表达式的查询，表达式支持AND、OR、NOT、IN、RANGE、COMPARISON的组合查询，如图6所示。
图6. CI通用搜索
如图7，用户能够订阅自己关心的资源视图，比如物理机、应用等。图8则是用户订阅的资源视图的数据展示，我们可以根据属性字段查询，另外也提供了批量修改、下载、删除等操作，也可以查看CI的生命周期，以及它的关联CI。
图7. 用户订阅关心的资源视图
图8. 资源视图
3.2 资源层级
资源层级视图实际上是资源视图按照树形目录的方式来进行展示。用户可以订阅某一个CIType按照不同属性分level来展示，比如物理机，我们可以定义: IDC -> 环境 -> 状态 3个属性分层的视图，如图9所示，用树形展示。这样方便了不同角色的用户可以按需来设计资源的统计展示方式，树形视图是单类CI实例数据的展示，不涉及到CI之间关系。
图9. 资源层级视图
3.3 关系视图
关系视图是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的任一一层节点。
图10. 关系查询
关系视图是由管理员根据需求来进行定义，然后授权给不同的角色来使用。举个例子: 事业部 -> 产品线 -> 应用 定义这样的一个关系视图,我们命名为服务树, 树的节点是这3层CI, 具体的数据展示是应用下面的所有资源，可以是物理机，也可以是docker，如图11所示。
图11. 关系视图-服务树
04自动发现
自动发现正如其字面意思，就是自动的去发现各种各样的运维资源，资源的变更能及时的反馈到CMDB里，降低了人力维护数据的成本。自动发现的建设一般分为3步: **创建自动发现规则、模型关联自动发现规则、执行自动发现。**接下来我们对这3步进行简要的阐述。
4.1 自动发现规则
维易开源CMDB的自动发现规则主要包括3大类:
4.1.1 内置插件和自定义插件
内置插件是把物理机、虚拟机、硬盘、网卡的发现内置到了OneAgent(注：维易统一运维探针OneAgent，可在官网免费申请veops.cn)里。点开内置插件的自动发现规则，呈现的是采集的属性列表，如下图所示：
图12.内置插件
自定义插件实际上是可以实现其他所有采集需求的，比如MySQL、Nginx、Tomcat等常用的一些软件自动发现，实现一个自定义的插件很简单，就是一段python脚本:
import json
class AutoDiscovery(object):
@property
def unique_key(self):
"""
:return: 返回唯一属性的名字
"""
return
@staticmethod
def attributes():
"""
定义属性字段
:return: 返回属性字段列表, 列表项是(名称, 类型, 描述), 名称必须是英文
类型: String Integer Float Date DateTime Time JSON
例如:
return [
("ci_type", "String", "模型名称"),
("private_ip", "String", "内网IP, 多值逗号分隔")
]
"""
return []
@staticmethod
def run():
"""
执行入口, 返回采集的属性值
:return: 返回一个列表, 列表项是字典, 字典key是属性名称, value是属性值
例如:
return [dict(ci_type="server", private_ip="192.168.1.1")]
"""
return []
if __name__ == "__main__":
result = AutoDiscovery().run()
if isinstance(result, list):
print("AutoDiscovery::Result::{}".format(json.dumps(result)))
else:
print("ERROR: 采集返回必须是列表")
4.1.2 网络设备的自动发现
这个发现能力同样内置在OneAgent里，通过SNMP等网络协议去采集网络设备，目前实现的主要包括交换机、路由器、防火墙、打印机。
图14. 网络设备自动发现
4.1.3 公有云资源的发现
通过对接公有云厂商的开放API，主动定时轮训的方式去获取公有云资源，目前集成了阿里云、腾讯云、华为云、AWS的云主机的自动发现，后续会扩充云资源的发现。当然如果本身在云主机上部署了OneAgent，实际上也是可以用内置的虚拟机的自动发现插件来进行采集。
4.2 模型关联自动发现规则
4.2.1 模型属性自动发现
以网卡为例进行说明，主要包括属性映射和执行配置:
1) 属性映射
关联上内置的网卡自动发现规则后，模型的属性名和自动发现规则的属性名会进行自动匹配，如果名字不一样则需要人工来匹配。实际上每个模型可以应用多个自动发现规则，每个规则里可能采集了模型的部分属性。
2) 执行配置
首先指定自动发现规则执行的目标机器，可以的选项有：
- 所有节点，比如物理机、虚拟机等，但是必须管理员才能配置为所有节点。
- 具体的某个节点，比如公有云资源的自动发现或者网络设备的自动发现，都是指定具体的某个节点去执行的。
- 从CMDB里选择，比如网卡，可以选择CMDB里所有的物理机去执行。
图15. 网卡属性自动发现
其次可选择是否自动入库，一般来说自动发现的准确率如果接近100%，那么可以直接选择自动入库，即自动发现的实例会直接入库为CI。如果选择不自动入库，实例会先进入自动发现资源池，然后需要人工批量入库为CI。
4.2.2 关系自动发现
关系自动发现配置极其简单，还是以网卡为例进行说明：
如下图所示，只需配置网卡采集的属性sn(物理机的序列号，实际上对网卡模型来说是冗余字段)和物理机模型的序列号建立关系即可，当采集上来的网卡入库CMDB时，会用字段来建立和物理机之间的关系。
图16. 网卡关系自动发现
4.3 执行自动发现
模型关联好自动发现规则之后，OneAgent会自动定时同步其所在节点的自动发现规则，然后执行自动发现规则，如果采集的数据和上一次采集有异同，则推送数据到服务端。
05权限管理
权限管理对运维系统来说是极其重要的，因为运维人员是拥有比较高权限的角色，所以运维系统的权限严格管控是至关重要的。比如自动化运维系统要从执行作业、执行目标机器、执行用户3个方面同时去控制权限。
如下图所示，在每个模型配置的页面里有权限设置的tab，这个页面里明显可以看到分为:
1.模型权限
配置权限表示的是模型可以被编辑，授权权限则是这个模型和实例可以被授权，一般是给管理员才会分配授权的权限。
2.实例权限
包括查看字段，即上面所讲的属性级别的控制；查看实例是指实例的权限控制，增删改这个比较容易理解。
添加图片注释，不超过 140 字（可选）
查看字段的权限设置如下图所示，默认是全部字段可以被查看，当然可以自定义字段给用户授权，图中授权了8个字段给demo用户角色。
添加图片注释，不超过 140 字（可选）
查看实例的权限如下图所示，默认也是可以查看所有的CI实例，当然也可以自定义，比如定义物理机里开发负责人是用户自己的，我们可以用双大括号来引用变量，目前支持的变量有user对象。
{{引用变量}}
添加图片注释，不超过 140 字（可选）
3.关系权限
在模型关联里可以对CI关系进行授权，主要包括新增、删除和授权的权限控制，这里很容易理解，就不再赘述了。
添加图片注释，不超过 140 字（可选）
经过上面的权限设置，以demo用户登录CMDB系统，在资源数据视图里查看物理机，结果呈现如下图所示。首先CI列表仅包含了开发负责人是demo的实例，字段仅展示了上面定义的8个属性。
添加图片注释，不超过 140 字（可选）
结语
设计和实践一个通用的运维CMDB需要时间、资源和不断地改进。一个成功的CMDB可以为组织提供更好的可见性、管理配置项的效率以及支持监控、ITSM流程的能力。然而，关键是要记住，CMDB不仅仅是一个工具，还需要与组织的文化和流程相结合，以实现最大的价值。在设计和实践CMDB时，持续的合作和反馈是成功的关键因素。
基于此设计我们开源了一个CMDB，希望能帮助到更多企业，并得到大家的积极反馈，系统将持续不断的改进，也欢迎您的加入。
在线体验
在线Demo: https://cmdb.veops.cn
用户名: demo 或者 admin
密码: 123456
开源地址
GitHub开源地址为：
github.com/veops/cmdb
大家如果觉得有用，麻烦GitHub上点个⭐️以示鼓励。
