CMDBuild试用总结

本文记录一个 iTop 老用户试用 CMDBuild 的感受,并对两个开源 CMDB 做一个简单的对比。选择的是 CMDBuild READY2USE,版本是 2.1,基于 CMDBuild 3.3.2。首先简单说一下安装过程。

安装

PostgreSQL 9.6

版本用 9.6,CentOS 7 上可以用 SCL 源安装。

postgres 用户启动的方法(没有root权限时)

用户操作

Tomcat 9.0

官网下载 https://tomcat.apache.org/download-90.cgi,(Binary Distributions,Core)。
解压到 /data/tomcat
进入 /data/tomcat/bin 执行 ./startup.sh 启动

CMDBuild READY2USE

下载 war 包,放到 /data/tomcat/webapps 里,会自动解压。然后进入 /data/tomcat/webapps/cmdbuild/WEB-INF/lib_ext,将 postgresql-42.2.5.jar 复制到 /data/tomcat/lib 目录
浏览器访问 IP:PORT/cmdbuild ,开始安装

使用

建模方法

READY2USE 是适用于 IT 资产管理的一个有预定义模型的产品,因此安装完成之后理论上就可以立即用于服务器,机柜,虚拟机等 IT 资产的管理。

和 iTop 类似,CMDBuild 也使用了 继承 的方式设计模型,READY2USE 的模型如图所示:

CMDBuild READY2USE 数据模型

因此,相比 bk-cmdb 之类的 CMDB 算是一个优点,至少属性和关联关系的管理会省力一些。

不同于 iTop,CMDBuild 的枚举类型用了一个叫 LookUp 类型的东西,本质上是将全部的枚举存储在一张 叫 LookUp 的表里,结构大致如下:

然后需要事先定义好枚举,类添加属性时才能用。用的时候属性选 LookUp 类型,选择一个 Type,枚举值这是该 Type 下的 Code。我没有想明白为什么要这样设计,PostgreSQL 里是有 ENUM 类型的,为什么不直接用呢?

还有一个和 LookUp 有点类似的 REFERNCE 类型,引用一个叫 Domain(域) 的对象,用来管理 1:N 和 N:N 关系。和 LookUp 不同的是,每个 Domain 都有独立的表。管理 1:N 关系时,类似 iTop 里的使用体验。管理 N:N 关系时,需要在编辑对象时切到 关系 选项卡下添加,显示也时在 关系 选项卡 下,即所有关系混在一个选项卡里,不如 iTop 的 AttributeLinkedSet 和 AttributeLinkedSetIndirect 类型的属性清晰。另外,REFERNCE 类型的属性没有超链接,跳转很不方便。

另外,Domain 定义的关系加了很多奇怪的描述,还要正向反向都描述,这点和 bk-cmdb 类似。

CMDBuild 关系描述

我认为这种做法是画蛇添足,没有必要这么复杂,直接 上游/下游 就全包含了,比如 机房的下游是 数据中心设备,网络设备的 下游 是 服务器,服务器的下游是业务,多简单。

在界面上建模

很多人喜欢界面上建模的方式,iTop 似乎也有个 Designer 提供界面建模功能。由于没有用过,这里不做讨论。单说 iTop 社区版,一般是通过用XML写的插件来建模的,并最终编译为 PHP 代码,存储在 env-production 目录下,而不是存储到数据库中。在 env-production 中随便看一个 model.xxx.php 文件,可以看到编译后的模型一般是这样的形式:

由于模型本质上是代码,因此可以干的事情很多,在实例新增更新删除的各个阶段都能实现精准的控制。

不同于 iTop,CMDBuild 在 WEB 界面上建模(而且似乎只有这一种手段)。虽然可以设置的属性参数比同为界面建模的 bk-cmdb 丰富的多,但相信从上面 iTop 模型的代码你也能看出界面建模的局限性,肯定是有很多需求无法实现的。CMDBuild 为了尽可能支持用户对属性控制的需求,弄了个界面上定义 Javascript 代码的古怪方案,如下图所示,通过JavaScript代码控制 属性的隐藏和是否只读,校验规则,自动设置值。

CMDBuild Ohter properties

我可能不会喜欢这种方式。在界面上维护代码,绝对是一个糟糕的做法。

我认为,界面定义模型的设计是没有前途的,iTop 那样代码定义模型才是更好的方法,因为:

  1. 对于模型设计者来说,在界面上维护上千个模型属性是一个很大的心智和体力负担,光是点击鼠标就够费劲的了
  2. 模型迁移麻烦,试想一下,在测试环境点了上千下鼠标才设计好的模型,要怎么方便的弄到生产环境?
  3. 如何记录模型的设计思路?又不能像写代码那样写注释,也不能用 Git 记录变更和管理版本
  4. iTop 插件式的模型设计方法,利于分享,可以方便的把自己的插件分享给别人,也可以方便的享受社区的成果,极大的提高 CMDB 建设的效率,比如,用 iTop 的 TeemIP 插件快速建设一个 IPAM 系统,不香吗?

用户操作

CMDB 软件的用户其实分为两种,一种是 模型设计 人员,负责设计数据模型,另一种则是使用 CMDB 支持工作的运维或研发人员。根据上节讨论,我认为针对模型设计人员,iTop 完胜。那么针对最终用户,CMDBuild 表现如何呢?

首先吐槽一下导入导出功能,和 iTop 相比,差了几条街,居然要求为每个类设置导入导出模板,不设置就用不了,想多导入导出一个属性,就得先改模板,用过 iTop 导入导出的,绝对忍受不了这种操作模式。

另外一个要吐槽的是列表的筛选功能,简直太弱,太麻烦了,居然要一个个属性的加,想想 iTop 的 default_search,不能忍。

另外一些小槽点:

  1. 导航组织逻辑凌乱,层次不够清晰
  2. 大写表名和属性,postgres 不识别大写但是又区分大小写,所有大写都得加双引号,烦
  3. 官网硬件需求写的最小 16G 内存,太多了。当然我在 8G 内存的机器上也跑起来了。但是 iTop 对硬件的需求小多了
  4. 关系图, iTop 的要漂亮多了

总结

正如 iTop Github主页的描述一样:A simple, web based IT Service Management tool,我认为在同行的衬托下 iTop 基本做到了 Simple,易于理解的概念,直观的模型设计方法,简单的关联关系管理...

总之, iTop 大法好。

参考文档

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注