本文记录一个 iTop 老用户试用 CMDBuild 的感受，并对两个开源 CMDB 做一个简单的对比。选择的是 CMDBuild READY2USE，版本是 2.1，基于 CMDBuild 3.3.2。首先简单说一下安装过程。
Contents
安装
PostgreSQL 9.6
版本用 9.6，CentOS 7 上可以用 SCL 源安装。
|
1 |
yum install rh-postgresql96* |
非 postgres 用户启动的方法（没有root权限时）
|
1 2 |
initdb -D ~/postgres/data pg_ctl -D ~/postgres/data -l logfile start |
用户操作
|
1 2 3 4 5 |
添加用户 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 的表里，结构大致如下：
|
1 2 3 4 5 6 |
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 文件，可以看到编译后的模型一般是这样的形式：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
// 服务器，继承自 数据中心设备 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 那样代码定义模型才是更好的方法，因为：
- 对于模型设计者来说，在界面上维护上千个模型属性是一个很大的心智和体力负担，光是点击鼠标就够费劲的了
- 模型迁移麻烦，试想一下，在测试环境点了上千下鼠标才设计好的模型，要怎么方便的弄到生产环境？
- 如何记录模型的设计思路？又不能像写代码那样写注释，也不能用 Git 记录变更和管理版本
- iTop 插件式的模型设计方法，利于分享，可以方便的把自己的插件分享给别人，也可以方便的享受社区的成果，极大的提高 CMDB 建设的效率，比如，用 iTop 的 TeemIP 插件快速建设一个 IPAM 系统，不香吗？
用户操作
CMDB 软件的用户其实分为两种，一种是 模型设计 人员，负责设计数据模型，另一种则是使用 CMDB 支持工作的运维或研发人员。根据上节讨论，我认为针对模型设计人员，iTop 完胜。那么针对最终用户，CMDBuild 表现如何呢？
我的结论依然是 iTop 胜出（也可能是因为我习惯了 iTop）。首先吐槽一下导入导出功能，和 iTop 相比，差了几条街，居然要求为每个类设置导入导出模板，不设置就用不了，想多导入导出一个属性，就得先改模板，用过 iTop 导入导出的，绝对忍受不了这种操作模式。
另外一个要吐槽的是列表的筛选功能，简直太弱，太麻烦了，居然要一个个属性的加，想想 iTop 的 default_search，不能忍。
另外一些小槽点：
- 导航组织逻辑凌乱，层次不够清晰
- 大写表名和属性，postgres 不识别大写但是又区分大小写，所有大写都得加双引号，烦
- 官网硬件需求写的最小 16G 内存，太多了。当然我在 8G 内存的机器上也跑起来了。但是 iTop 对硬件的需求小多了
- 关系图， iTop 的要漂亮多了
总结
正如 iTop Github主页的描述一样：A simple, web based IT Service Management tool，我认为在同行的衬托下 iTop 基本做到了 Simple，易于理解的概念，直观的模型设计方法，简单的关联关系管理...
参考文档
|
1 2 3 |
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 |
请问cmdbuild怎么使用，部署好了但却不会用