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

安装

PostgreSQL 9.6

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

yum install rh-postgresql96*

非 postgres 用户启动的方法（没有root权限时）

initdb -D ~/postgres/data
pg_ctl -D ~/postgres/data -l logfile start

用户操作

添加用户
createuser --superuser posgres
设置密码
psql postgres
\password postgres

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 的模型如图所示：

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

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

Code       Type
HP         Brand
Cisco      Brand
Production State
Stock      State
Obsolete   State 

然后需要事先定义好枚举，类添加属性时才能用。用的时候属性选 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 类似。

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

在界面上建模

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

// 服务器，继承自 数据中心设备
class Server extends DatacenterDevice
{
	public static function Init()
	{
		$aParams = array(			'category' => 'bizmodel,searchable',
			'key_type' => 'autoincrement',
			'name_attcode' => array('name'),
			'state_attcode' => '',
			'reconc_keys' => array('name', 'org_id', 'organization_name'),
			'db_table' => 'server',
			'db_key_field' => 'id',
			'db_finalclass_field' => '',
			'icon' => utils::GetAbsoluteUrlModulesRoot().'itop-config-mgmt/images/server.png',);
		MetaModel::Init_Params($aParams);      // 模型初始化
		MetaModel::Init_InheritAttributes();   // 初始化继承的属性
		// 初始化新增的属性
		// MetaModel::Init_AddAttribute(属性实例对象)
		MetaModel::Init_AddAttribute(new AttributeExternalKey("osfamily_id", array("targetclass"=>'OSFamily', "allowed_values"=>null, "sql"=>'osfamily_id', "is_null_allowed"=>true, "on_target_delete"=>DEL_MANUAL, "depends_on"=>array(), "display_style"=>'select', "always_load_in_tables"=>false)));
		// 略

		// 展示
		MetaModel::Init_SetZListItems('details', array ());         // 对象详情页
		MetaModel::Init_SetZListItems('search', array ());          // 可以搜索的属性
		MetaModel::Init_SetZListItems('default_search', array ());  // 列表页展示的默认搜索项
		MetaModel::Init_SetZListItems('list', array ());            // 列表展示的属性
	}

	// 很多方法，可以控制属性展示，读写，校验，关联关系等
	public static function GetRelationQueriesEx($sRelCode){}
	// 自定义方法，一般提供给 默认方法 多次调用的场景
	public function CustomFunction() {}
}

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

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

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

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

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

用户操作

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

我的结论依然是 iTop 胜出（也可能是因为我习惯了 iTop）。首先吐槽一下导入导出功能，和 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，易于理解的概念，直观的模型设计方法，简单的关联关系管理...

参考文档

1. https://www.cmdbuildready2use.org/files/cmdbuildready2use_overviewmanual_eng_v100.pdf
2. https://www.cmdbuild.org/file/manuali/administrator-manual-in-english
3. https://www.cmdbuild.org/file/manuali/technical-manual-in-english