聊聊CMDB - 技术栈

写在前面：为什么你需要"神器"而非"常用命令

大家好,欢迎来到干货、技术、专业全方位遥遥领先的老杨的博客.

帮老杨点赞、转发、在看以及打开小星标哦

攒今世之功德,修来世之福报

现在是不是都在吹CMDB+N，今天聊聊CMDB

CMDB到底是个啥?能放啥?

全称配置管理数据库。

我把它当成一张活的资产表。

常见字段：资产 ID、主机名、IP、操作系统、所属应用、负责人、业务线、机房、环境、版本、上线时间、变更记录。

更重要的是它能表示依赖关系。

比如：order-service 依赖 mysql-order。这玩意儿在做影响面分析时特别关键。

整几个场景聊聊.

场景 1：监控告警来了，谁去处理？怎么最快把人唤起？

监控告警时，第一件事是定位 owner。

有 CMDB 就能自动查到联系人并通知。示例脚本是我常用的查询方法（假设 CMDB 有 REST 接口）。

查询服务 owner

go 复制代码

$ export CMDB_API="http://cmdb.company.local/api/v1"
$ export TOKEN="xxxx"
$ curl -s -H "Authorization: Bearer $TOKEN" \
  "$CMDB_API/services?name=order-service" | jq '.data[0] | {service,owner,contacts}'

输出

go 复制代码

{
  "service": "order-service",
  "owner": "liang.liu",
  "contacts": {"email":"liang.liu@company.com","phone":"13800138000"}
}

拿到这个信息，我会把警报直接 @ 到负责人群里。

这样能把"谁来处理"的等待时间降到最短。

场景 2：把 CMDB 当作 Ansible 的动态 inventory

我常把 CMDB 的主机导出成 Ansible 清单。

运行一次脚本，自动生成文件，交给 Ansible 做批量运维。

go 复制代码

#!/bin/bash
CMDB_API="http://cmdb.company.local/api/v1"
TOKEN="xxxx"
OUT=/tmp/ansible_hosts

curl -s -H "Authorization: Bearer $TOKEN" \
  "$CMDB_API/hosts?env=prod" | \
  jq -r '.data[] | "\(.hostname) ansible_host=\(.ip) owner=\(.owner)"' > $OUT

echo "生成 inventory: $OUT"
cat $OUT

输出

生成 inventory: /tmp/ansible_hosts

go 复制代码

web-01 ansible_host=10.0.1.10 owner=wangwu
web-02 ansible_host=10.0.1.11 owner=wangwu
db-01 ansible_host=10.0.2.5 owner=liang.liu

这样就能精确定位到 prod 的节点，避免把测试环境当成生产去动手。

少出灾的关键就在这一步。

场景 3：变更前的影响分析，别盲改

变更前想知道会影响哪些系统？用 CMDB 的依赖关系查。

下面是我常用的查询例子。

go 复制代码

$ curl -s -H "Authorization: Bearer $TOKEN" \
  "$CMDB_API/dependencies?service=order-service" | jq '.data'

输出

go 复制代码

[
  {"name":"payment-service","type":"service"},
  {"name":"inventory-service","type":"service"},
  {"name":"mysql-order","type":"database"}
]

看到这些下游后，我会避免在高峰期对任何一个关键组件做大改动。

这一步能把事故概率降得很低。

场景 4：CI 与 CMDB 对接，把部署指向真实库存

CI 发版时，先从 CMDB 拉出目标主机，再执行 playbook。这样不会误发到退役机。

CI job 片段

go 复制代码

script:
  - curl -s -H "Authorization: Bearer $TOKEN" "$CMDB_API/hosts?env=prod&app=myapp" > hosts.json
  - ansible-playbook -i hosts.json deploy.yml

实际运行里，我把这些步骤写进 pipeline。

发布只针对 CMDB 里登记的节点。出问题能回溯到谁改了什么。

场景 5：补丁与合规统计，一句 SQL 就能要账

审计要补丁覆盖率时，用 CMDB 的字段直接出报表。示例 SQL 如下：

go 复制代码

SELECT os_version, COUNT(*) AS hosts
FROM cmdb_assets
WHERE env='prod'
GROUP BY os_version;

输出

go 复制代码

os_version    hosts
Ubuntu18.04     120
CentOS7         300

有了这份表，安全团队就能迅速列出受影响主机并安排补丁计划。

零预算起步路线

先别上大厂商系统。

我建议先用 Git 管理 YAML 或 CSV，作为临时 CMDB。

把云标签当作初始数据源。逐步用脚本把这些数据汇总到简单的 API 服务。等数据稳定，再考虑迁移到 NetBox、iTop 或商业 CMDB。

示例：把云标签导出到 CSV（以阿里云 CLI 为例，示意命令）：

示意：用云 CLI 列出实例并导出基本字段

go 复制代码

$ aliyun ecs DescribeInstances --RegionId cn-hangzhou --PageSize 50 > instances.json
$ cat instances.json | jq -r '.Instances.Instance[] | [.InstanceId,.InstanceName,.PublicIpAddress.IpAddress[0],.Tags[0].TagValue] | @csv' > cmdb_seed.csv

输出（cmdb_seed.csv 的前几行）

go 复制代码

"i-bp1abc123","web-01","101.1.1.10","prod"
"i-bp2def456","db-01","10.0.2.5","prod"

这就能快速搭一个可用的起点。后面慢慢把字段丰富起来，接审批流。

老杨时间

这里老杨先声明一下,日常生活中大家都叫老杨波哥,跟辈分没关系,主要是岁数大了.就一个代称而已.

老杨的00后小同事老杨喊都是带哥的.张哥,李哥的.

但是这个称呼呀,在线下参加一些活动时.金主爸爸也这么叫就显的不太合适.

比如上次某集团策划总监,公司开大会来一句:"今个咱高兴!有请IT运维技术圈的波哥讲两句"

这个氛围配这个称呼在互联网这行来讲就有点对不齐!

每次遇到这个情况老杨老杨周末浅聊服务器开在公网的那些坑老杨干了,你们随意!"

所以以后咱们改叫老杨,即市井又低调.还挺亲切,老杨觉得挺好.

运维X档案系列文章:

从告警到CTO：一个P0故障的11小时生死时速

企业级 Kubernetes 集群安全加固全攻略（附带一键检查脚本）

看完别走.修行在于点赞、转发、在看.攒今世之功德,修来世之福报

老杨AI的号: 98dev