您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 配置管理 > 正文

有了CMDB,为什么还要应用配置管理

发表于:2018-06-19 作者:赵成 来源:Forrest随想录
       CMDB翻译过来,Configuration Management DataBase,其实也是配置管理的意思,但从实际情况看,CMDB的概念定义已经出现了很大的局限性,之前老王也专门写过一篇文章《如何理解CMDB的套路》来阐述过这个观点,今天我从我们团队自己的实践过程中的理解和角度再来呼应下,因为这一点理解不清楚,基础打不好,后续的自动化也好,DevOps也好,等等等等,都将无从谈起。
  先抛观点: CMDB是面向资源的管理,应用配置是面向应用的管理。
  注意:是资源,不是资产,资源 ≠资产
  一、CMDB面向的是资源层面的管理,是运维的基石
  通常,我们在建设运维的基础管理平台时,通常要做的事情:
  1、把服务器、网络、IDC、机柜、存储、配件等这几大维度先定下来;
  2、这些硬件的属性确定下来,比如服务器就会有SN序列号、IP地址、厂商、硬件配置(如CPU、内存、硬盘、网卡、PCIE、BIOS)、维保信息等等;网络设备如交换机也会有厂商、型号、带宽等等;
  3、以上信息之间的关联关系,或者叫拓扑关系。比如服务器所在机柜,虚拟机所在的宿主机、机柜所在IDC等简单关系,复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系,这个就相对复杂一些
  4、其实应该是3.5步,在上面信息的梳理过程中肯定就会遇到一些规划问题,比如,IP地址段的规划,xx网段用于DB,xx网段用于大数据、xx网段用于业务应用等等,再比如同步要做的还有xx机柜用于做虚拟化宿主机、xx机柜只放DB机器等等。
  以上信息梳理清楚,通过ER建模工具进行数据建模,再将以上的信息固化到DB中,一个资源层面的信息管理平台就基本成型了。但是,信息固化不是目的,也没有价值,只有信息动态流转起来才有价值(跟货币一样)。接下来我们可以做的事情:
  1、基于这些信息进行流程规范的建设,比如服务器的上线、下线、维修、装机等流程。同时,流程过程中状态的变更要同步管理起来。
  2、拓扑关系的可视化和动态展示,比如交换机与服务器之间的级联关系、状态(正常or故障)的展示等,这样可以很直观的关注到资源节点的状态。
  至此,从资源维度的信息梳理,以及基于这些信息的平台和流程规范建设也算是基本成型了。这个时候,以服务器简单示例,我们的视角是下面这样的:
  二、应用配置管理是面向应用的管理,是运维的核心
  上面说明了CMDB的基础信息部分,如果从传统的SA运维模式,这些信息已经足够,但是从应用运维的角度,这些就远远不够了。这时我们就需要一个非常非常重要的句柄——应用名,或者叫应用标示。这时,应用运维里面最最重要的一条联系也就产生了——“应用名—IP“的关联关系。(注:这里也可以是定义的其它的唯一主机标示,如主机名、容器ID等等,因为我们使用的方式是IP,所以这里就以IP示例)
  之所以说应用名和应用名-IP关联关系非常重要,是因为它的影响力不仅仅在运维内部,而是会一直延伸整个技术架构上,后面的文章,我们介绍到的所有的平台和系统建设,都会跟这两个概念有关。
  CMDB是IP为标示的资源管理维度,有了应用名之后,我们后面就是以应用为视角的管理维度了。首先看一下应用会涉及到的信息:
  1、应用基础信息,如应用责任人、应用的Git地址等
  2、应用部署涉及的基础软件包,如语言包(Java、C++、GO等)、Web容器(Tomcat、JBoss等)、Web服务器(Apache、Nginx等)、基础组件(各种agent,如日志、监控、系统维护类的tsar等)
  3、应用部署涉及的目录,如运维脚本目录、日志目录、应用包目录、临时目录等
  4、应用运行涉及的各项脚本和命令,如启停脚本、健康监测脚本
  5、应用运行时的参数配置,如Java的jvm参数,特别重要的是GC方式、新生代、老生代、永生代的堆内存大小配置等
  6、应用运行的端口号
  7、应用日志的输出规范
  8、。。。。。。。
  我们梳理完上述信息后就会发现,这些信息跟CMDB里面的资源信息是完全两个维度的东西,所以从信息管理维度上讲,资源配置和应用配置分开会更清晰,解耦之后也更容易管理。
  好了,按照上面CMDB说的套路,梳理完成后,就是要进行信息的建模和数据的固化,这时就有了我们的——应用配置管理。再往后,就是基于应用配置管理的流程规范和工具平台的建设,这就涉及到我们经常说的持续集成&发布&交付,监控、稳定性平台、成本管理等等。
  从应用的视角,我们配置管理,应该是下面这样一个视图(简单示例,不是完整的):
  三、CMDB和应用配置管理的关系
  有了资源配置信息和应用配置信息,这两个信息应该怎么统一管理起来呢。直接上图:
  至此,CMDB和应用配置管理的分层分解就完成了,应用名关联着应用配置信息,IP关联着资源信息,二者通过应用名-IP的对应关系,联系到一起。
  CMDB是运维的基石,但是要发挥更大的价值,光有基础是不够的,我们要把更多的精力放到上层的应用和价值服务上,所以我才会讲应用才是运维的核心。我们可以看到,如果仅仅基于CMDB的资源信息作自动化,最多只能做出自动化的硬件资源采集、自动化装机、网络-硬件拓扑关系生成等资源层面的工具,这些工具只会在运维层面产生价值,离业务还很远,就更谈不上能给业务带来什么价值了。但是基于应用这一层去做,就可以做很多事情,比如持续集成和发布、持续交付、弹性扩缩容、稳定性平台、成本控制等等,这些事情,带来的价值就会大大不同,这些后续会一个个介绍出来。