CMDB与自动化运维

CMDB与自动化运维

1、传统运维与自动化运维的对比

1、企业中，项目的发布流程

产品经理调研需求 ----》三方开会讨论(开发，产品，运维，测试) -----> 开发进行开发产品 ----> 测试流程 (黑盒和白盒测试) -----> 上线

2、传统的上线流程：

SVN 开发将代码压缩一下发给运维，运维拿到代码之后，然后将代码解压缩，部署到服务器上，启动服务

好处：流程简单

缺点：服务器数量多的话，部署就非常的慢，影响上线的进度

3、自动化运维的流程：

搞一个web的系统，勾选发布的机器，上传代码， 进行发布

运维自动化最重要的就是标准化一切

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

 上述系统需要知道服务器的基本信息（元信息）

4、监控系统

需要监控服务器的CPU使用率，磁盘大小(>90%,报警)，内存使用率

上述系统需要知道服务器的基本信息

 2、CMDB

1、概念介绍

做自动化运维项目首先需要做一个基石项目，来提供服务器的基础信息（服务器的磁盘、CPU、内存等），这个基石项目叫做CMDB（Configure Manage DataBase）配置管理数据库，主要用来收集服务器的基础信息

2、架构图方案

方案一：Agent方案

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

优点：速度快
缺点：需要为每台服务器部署一个Agent程序

1. python中是使用subprocess模块来控制终端执行命令

2. Django中接收数据是在body中根据请求头来判断是否交给post，如果conten-type:application/form-url-encodeDjango会将body中的数据交给post，如果是content-type:application/json的话Django就不会把body中的数据交个post

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

在中控机服务器上安装一个模块叫paramiko模块，通过这个模块登录到带采集的服务器上，然后执行相关的linux命令，最后返回执行的结果，将分析得到的结果通过requests模块发送给API，API获取到数据之后，进行二次比对数据，最后将比对的结果存入到数据库中，最后django起一个webserver从数据库中将数据获取出来，供用户查看

 优点：无agent

缺点：速度慢，如果服务器少的情况下可以使用

import paramiko

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

# 执行命令
stdin, stdout, stderr = ssh.exec_command('ifconfig')
# 获取命令结果
result = stdout.read()
print(result)
# 关闭连接
ssh.close()

方案三：saltstack 方案

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

总结：

整个架构方案分成3部分：客户端采集，API数据分析，数据展示