运维体系管理课二落地 CMDB 与应用配置管理用代码讲清应用-集群-资源三层模型一、引言CMDB 是地图应用才是目的地每一位运维人都知道 CMDB配置管理数据库的重要性——它是运维的地图记录了机房、服务器、网络设备等所有基础设施信息。但做过三年以上运维的同学一定深有体会光有资源台账远远不够。假设你接手了一套系统CMDB 里躺着 300 台服务器的 IP、CPU、内存、磁盘但你不知道它们分别属于哪个应用、哪个环境、跑的是什么进程。这时候 CMDB 只是一份资产管理 Excel离真正的运维管理差着一个应用层的距离。应用配置管理就是在 CMDB 的资源底座之上补上应用这个逻辑实体。它回答三个核心问题这个应用有哪些集群开发 / 测试 / 生产每个集群下面挂着哪些资源服务器不同环境的配置项是什么怎么隔离本文以一台真实云服务器120.46.139.159上运行的轻量 CMDB 服务Flask atomcode 生成为例完整演示应用-集群-资源三层模型的落地细节。源码由 AI 编程工具 atomcode 协助生成力求简洁可复用。二、模型设计三层结构 环境隔离2.1 核心数据模型Application应用 │ ├── Cluster集群按环境划分 │ ├── dev │ ├── test │ └── prod │ └── ConfigItem配置项绑定集群应用Application是整个管理体系的唯一管理实体。不再以 IP 或主机名为维度去运维——所有操作都围绕应用展开。一个应用可以有多个集群按环境dev / test / prod或地域华南 / 华北 / 境外划分。集群Cluster是环境和资源的聚合单元。每个集群包含一组主机Host和一组配置项ConfigItem天然实现了环境隔离。资源Host是具体服务器。但与 CMDB 传统模型不同主机不再孤立存在它必须归属于某个集群从而归属于某个应用。反向查询时能快速回答“这台机器上跑的是什么应用的什么环境”配置项ConfigItem按集群隔离。同一个应用dev 环境的DB_URL指向开发数据库prod 环境指向生产数据库互不干扰。2.2 精简数据表结构# 内存模型示意完整版见 lab/appcmdb/app.pyapps{}# {app_id: {name, owner, clusters: {...}}}clusters{}# {cluster_id: {env, region, hosts: [...], configs: {...}}}三、实操真实 curl 输出服务已部署在120.46.139.159:5000下面是真实 API 交互输出。3.1 应用-集群-资源三层拓扑// GET /apps/order-service/topology{app:order-service,clusters:[{cluster_id:order-service-dev,env:dev,region:华南,hosts:[{ip:10.0.1.11,role:web,cpu:4,mem:8,status:online},{ip:10.0.1.12,role:worker,cpu:8,mem:16,status:online}]},{cluster_id:order-service-test,env:test,region:华北,hosts:[{ip:10.0.2.11,role:web,cpu:4,mem:8,status:online},{ip:10.0.2.12,role:db,cpu:8,mem:32,status:online}]},{cluster_id:order-service-prod,env:prod,region:华东,hosts:[{ip:10.0.3.11,role:web,cpu:8,mem:16,status:online},{ip:10.0.3.12,role:worker,cpu:16,mem:32,status:online}]}]}从这个拓扑可以一目了然order-service 有三个集群开发环境华南2 台、测试环境华北2 台、生产环境华东2 台。每台机器的角色、规格、在线状态全都清晰可见。3.2 应用配置按环境隔离// GET /apps/order-service/config?envprod[{key:DB_URL,value:mysql://prod-db:3306/order},{key:redis_host,value:prod-redis},{key:log_level,value:WARN},{key:max_conn,value:200}]切换?envdev返回的就是另一组值——DB_URL 指向dev-dblog_level是DEBUGmax_conn仅20。同一份代码不同环境通过这套机制拿到不同的运行时配置。3.3 创建新应用$curl-XPOST http://120.46.139.159:5000/apps\-HContent-Type: application/json\-d{name: pay-service, owner: 支付团队}应用 pay-service 创建成功$curlhttp://120.46.139.159:5000/apps[order-service,pay-service]新建应用只需指定名称和负责人系统建立应用实体集群与配置初始为空后续通过add_host接口往集群添加主机——首次添加某环境时会自动创建对应集群再写入主机与配置项。四、代码要点精选接口实现下面摘录app.py中最核心的两个接口体现应用是唯一管理实体的设计思想。fromflaskimportFlask,request,jsonify appFlask(__name__)apps{}# app_name - {clusters: [...]}clusters{}# cluster_id - {env, region, hosts, configs}app.route(/apps/app_name/topology)defget_topology(app_name):返回应用的三层拓扑应用 → 集群列表含主机app_dataapps.get(app_name)ifnotapp_data:returnjsonify({error:应用不存在}),404clusters_list[]forcidinapp_data[clusters]:cclusters[cid]clusters_list.append({cluster_id:cid,env:c[env],region:c[region],hosts:c[hosts]})returnjsonify({app:app_name,clusters:clusters_list})app.route(/apps/app_name/config)defget_config(app_name):按环境获取应用的配置项——环境隔离的核心入口envrequest.args.get(env,dev)app_dataapps.get(app_name)ifnotapp_data:returnjsonify({error:应用不存在}),404cluster_keyf{app_name}-{env}clusterclusters.get(cluster_key)ifnotcluster:returnjsonify({error:集群不存在}),404returnjsonify(cluster[configs])这两段代码的关键设计点拓扑以应用为入口外界看到的不是零散的 IP 列表而是 order-service → prod → [5 台主机] 的清晰层级。配置按集群环境隔离cluster_key f{app_name}-{env}决定了 dev、test、prod 的配置天然隔离不存在跨环境互相覆盖的风险。查询链路短两到三层字典查找就能拿到完整信息对于轻量级场景足够高效。五、落地经验与避坑指南5.1 资源视角 vs 应用视角CMDB 早期以资源服务器、网络设备为中心建模型运维操作是修这台机器“换那块硬盘”。但业务方关心的是订单应用挂了“支付应用慢”。两种视角必须打通。我们的做法是在 CMDB 之上加一层应用管理层不推翻原有资源 CMDB而是通过 cluster_id 建立关联。资源 CMDB 负责生命周期上下架、维修应用 CMDB 负责拓扑与配置编排。5.2 配置漂移应用配置管理的头号敌人是配置漂移——某次排障时运维 SSH 到服务器直接改了个配置文件几周后又一台机器重建时发现配置对不上了。对抗配置漂移需要声明式而非修正式的运维模式配置只从 API 写入或 CI/CD 流水线同步禁止人工在服务器上手动修改。上面的配置查询接口可以封装进 agent配合定时巡检做配置一致性校验。5.3 与配置中心的边界很多团队问有了 Nacos / Apollo / Consul 这些配置中心还需要应用配置管理吗答案是分工不同维度应用配置管理本文配置中心Nacos/Apollo粒度环境级、集群级单个应用实例级可热更新变更频率低随发布变更可高动态调优存储形式CMDB 中的结构化数据独立配置中心典型内容DB_URL、基础参数开关、限流阈值、灰度比例二者是互补关系应用 CMDB 定义应该是什么配置中心负责运行时是什么。建议配置中心从 CMDB 同步基线配置作为默认值再做动态下发。六、小结与预告本文通过一个真实部署的轻量 CMDB 服务完整呈现了应用-集群-资源三层模型的设计与实操。从 curl 输出到代码片段你可以直接类比引入自己的运维体系。核心观点再强调一遍以应用为唯一管理实体——你的 CMDB 落地得再好如果不能回答这台机器跑的是什么应用的什么环境它就只是一个资产管理工具而不是运维管理平台。下一篇我们讲持续交付流水线如何把应用-集群-资源模型接入 CI/CD实现环境感知的自动化发布。敬请期待。配套源码完整代码见 Giteehttps://gitee.com/LiaCin/ops-management-course 的 lab/appcmdb 目录。所有 API 示例均可本地运行测试欢迎 Star 和 PR。
