搭建CMDB系统——概述

一、CMDB是什么？

CMDB 是什么，作为 IT 工程师的你想必已经听说过了，或者已经烂熟了，容我再介绍一下，，根据百度百科的解释呢，配置管理数据库( Configuration Management Database,CMDB)是一个逻辑数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。
CMDB存储与管理企业IT架构中设备的各种配置信息，它与所有的服务支持和服务交付流程都紧密相连，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。

它存储与管理企业 IT 架构中设备的各种配置信息，它支撑服务流程的运转、发挥着配置信息的价值。在今天，无论是自动化运维、标准化运维、DevOps、甚至是时髦的智能运维，其实都离开不 CMDB，可以说 CMDB 是运维体系的基石，有了配置信息数据库，后面各种标准、流程都可以建立在 CMDB 基础之上，从而实现真正的标准化、自动化、智能化运维，节约运维成本的同时，也降低运维流程混乱带来的操作风险。

二、IT运维的分类

IT运维，指的是对已经搭建好的网络、软件、硬件进行维护。具体可以分为硬件运维和软件运维。

• 硬件运维主要包括对基础设施的运维，例如机房的设备，主机的键盘，内存等物理设备的维护。
• 软件运维主要包括系统运维和应用运维，系统运维主要包括对OS，数据库，中间件的监控和维护，这些系统介于设备和应用之间，应用运维主要是对线上业务系统的运维。

三、CMDB与传统数据库的区别

CMDB软件侧重于信息的管理(采集、整合、记录、维护、检验、更新等)，数据库侧重于信息的物理存储，两者是密切联系的。

CMDB的功能需要专门的CMDB管理软件，很难在传统数据库上直接完成。因为对配置信息的管理是CMDB的核心功能，而这一部分功能很难由数据库软件实现。

四、传统运维的缺点

目前许多企业的IT运维已经实现从人工运维到计算机管理，但在同客户的交流中发现其中很多企业的IT运维管理还只是处在“半自动化”的运维状态。因为这种IT运维仍然是等到IT故障出现后再由运维人员采取相应的补救措施。这些传统式被动、孤立、半自动式的IT运维管理模式经常让IT部门疲惫不堪，主要表现在以下三个方面：

(1)IT 运维人员被动、效率低

在IT运维过程中，只有当事件已经发生并已造成业务影响时才能发现和着手处理，这种被动“救火”不但使IT运维人员终日忙碌，也使IT运维本身质量很难提高，导致IT部门和业务部门对IT运维的服务满意度都不高。目前绝大多数的企业IT运维人员日常大部分时间和精力是处理一些简单重复的问题，而且由于故障预警机制不完善，往往是故障发生后或报警后才会进行处理，使到IT运维人员的工作经常是处于被动“救火”的状态，不但事倍功半而且常常会出现恶性连锁反应。

(2)缺乏一套高效的IT运维机制

目前许多企业在IT运维管理过程中缺少自动化的运维管理模式，也没有明确的角色定义和责任划分，使到问题出现后很难快速、准确地找到根本原因，无法及时地找到相应的人员进行修复和处理，或者是在问题找到后缺乏流程化的故障处理机制，而在处理问题时不但欠缺规范化的解决方案，也缺乏全面的跟踪记录。

(3)缺乏高效的IT运维技术工具

随着信息化建设的深入，企业IT系统日趋复杂，林林总总的网络设备、服务器、储存设备、中间件、业务系统等让IT运维人员难以从容应对，即使加班加点地维护、部署、管理也经常会因设备出现故障而导致业务的中断，严重影响企业的正常运转。出现这些问题部分原因是企业缺乏事件监控和诊断工具等IT运维技术工具，因为在没有高效的技术工具的支持下故障事件很难得到主动、快速处理。

五、为什么需要自动化运维？

1.项目上线

流程：产品经理调研（画出原型图）–>定需求–>三方会谈（研发，产品经理，老大们）–>定日期–>测试项目–>最终上线–>应用运维

• 目前：将代码打包给运维，运维解压上线

• 问题：随着机器数量的线性增加，运维的工作量也是线性增加，重复而且是毫无意义的劳动

• 解决：

  1.写一个shell脚本，进行部署
  2.搞一个自动化代码上线系统

• 必要条件：服务器的各种信息（主机名，CPU，硬盘大小等）

2.监控系统

监测服务器的各种信息（硬盘是否满，CPU的使用率，内存使用率，网站服务运行是否正常）

• 问题：之前简单的脚本，监测服务器的信息，比较麻烦

• 解决：
  想将服务器的各种信息，以图表的形式展示在web界面上（可视化）

• 必要条件：服务器的各种信息（主机名，CPU，硬盘大小等）

3.自动装机系统

• 问题：人工装机需要一台一台去装

• 解决：
  搞一个装机系统，cobbler软件

• 必要条件：服务器的各种信息（主机名，CPU等）

六、自动化运维平台的特征

针对传统运维的痛点，我们可以知道自动化运维需要支持哪些功能？
运维自动化最重要的就是标准化一切

• OS的选择统一化，同一个项目使用同样的OS系统部署其所需要的各类软件
• 软件安装标准化，例如JAVA虚拟机，php，nginx，mysql等各类应用需要的软件版本，安装目录，数据存放目录，日志存放目录等
• 应用包目录统一标准化，及应用命名标准化
• 启动脚本统一目录和名字，需要变化的部分通过参数传递
• 配置文件标准化，需要变化的部分通过参数传递
• 日志输出，日志目录，日志名字标准化
• 应用生成的数据要实现统一的目录存放
• 主机/虚拟机命名标准化，虚拟机管理使用标准化模板
• 使用docker比较容易实现软件运行环境的标准化

七、CMDB包含的功能

1用户管理，记录测试，开发，运维人员的用户表

2：业务线管理，需要记录业务的详情

3：项目管理，指定此项目需属于那条业务线，以及项目详情

4：应用管理，指定此应用的开发人员，属于哪个项目，和代码地址，部署目录，部署集群，依赖的应用，软件等信息。

5：主机管理，包括云主机，物理机，主机属于哪个集群，运行着哪些软件，主机管理员，连接着哪些网络设备，云主机的资源地，存储等相关信息。

6：主机变更管理，主机的一些信息变更，例如管理员，所属集群等信息更改，连接的网络变更等。

7：网络设备管理，主要记录网络设备的详细信息，及网络设备连接的上级设备

8：IP管理，IP属于哪个主机，哪个网段，是否被占用等

八、CMDB的四种实现方式

方式一：Agent方式

可以将服务器上面的Agent程序作定时任务，定时将资产信息提交到指定API录入数据库

• 本质就是在各个服务器上执行subprocess.getoutput(“命令”),然后将每台机器上执行的结果返回给主句API，然后主机API收到这些数据之后，放到数据库中，最终通过web界面展现给用户。

• 优点：速度快

• 缺点：需要为每台服务器部署有关Agent程序

• 使用场景：服务器比较多的时候

方式二：ssh类实现方式（基于paramiko模块）

中控机通过Paramiko（py模块）登录到各个服务器上，然后执行命令的方式去获取各个服务器上的信息。

• 优点：没有Agent
• 缺点：有一个中控机，速度慢
• 使用场景：服务器比较少的时候

# 创建SSH对象
ssh = paramiko.SSHClient()
# 允许连接不在know_hosts文件中的主机
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
# 连接服务器
ssh.connect(hostname='192.168.226.128',port=22, username='ubuntu1', password='root123456')

# 执行命令
stdin, stdout, stderr = ssh.exec_command('ifconfig')

# 获取命令结果
result = stdout.read()
ssh.close()

方式三：salt-stack方式

此方案本质上和第二种方案是差不多的流程，中控机发送命令给服务器执行。服务器将结果放入另一个队列中，中控机获取将服务信息发送到API进而录入到数据库。

• 优点：速度快，开发成本低
• 缺点：依赖于第三方工具
• 使用场景：公司已经使用salt-stack软件

方式四：Puppet方式（了解）

这是相对比较古老的一种方式，上面的几种都是由中控服务端去主动获取数据；
而puppet方式是由puppet-master和puppet-salve组成；puppet-salve每隔30分钟发送数据给puppet-master。

puppet-master内维护了一个报表：获取这个报表发送数据给API

puppet:是用ruby写的。所以我们在通过报表采集资产的时候，需要使用ruby语言。

感谢一下几个链接提供帮助
引用博文