目录：
1.为啥要做cmdb👀
2.开发cmdb的思路和大概做法👀
3.cmdb的四套方案👀
一、为啥要做CMDB
a.项目发开和上线场景🎆
流程：
产品经理调研需求 ===》定一个时间开发 ===》测试 ===》产品项目上线（运维）
传统做法：
运维解压文件（以邮件的形式发给运维），将代码部署到相对应的服务器目录下面。如果是由100等的话就是写shell脚本，后面跟着一串服务器的列表，然后把项目代码部署分发到每个服务器上，然后再用一个命令进行解压
存在问题：
--效率不高
--不能实现覆盖Bug的代码（代码需要完bug之后就要重新走一套流程，效率极低）
解决方法：
代码上线系统：
前端展示给用户页面，用户可选择要上传的代码，页面还展示了公司所有的服务器和对应的ip地址可以进行勾选，然后点击上传即可。
这样就不需要交给运维人员了，运维只要告诉你有什么权限，然后分配了哪几台机器，再去选择需要发布的服务器，上传交给后端（使用django去改写shell脚本的那一套）
如果需要修改代码的话，也是直接发布提交，然后后台会自动的进行代码之间的比较
-------------------必要的条件：服务器的IP地址，硬盘空间，CPU的使用率，内存等
b.监控服务器🎪
（🔯监控服务器的报警信息：公司的服务器运行好多程序，会有好多的图表，就是监控这个服务|应用|网址的状态码等的一些变化信息♍）
传统做法：
shell脚本执行命令
问题：
--不能实时
--不能自动化
现在做法：
后台用python去做，收集一下服务的元信息（IP地址，硬盘大小，内存）
前台配合kibana
c.装机服务🐷
(👍服务器操作系统（centos）:将服务器格式化之后装成我们自己想要的系统并且还需要装公司定制的服务👍)
做法：
自动装机服务（将网线插入，然后输入指令就会自动装机，而且是并发的执行）
必要条件：
服务器的元信息，IP地址
d.年底统计🚲
之前的做法：
使用excel统计服务器（ip地址，内存，硬盘大小等等）
存在问题：
--不能实时，需要对变更进行记录（哪台服务器哪一天由谁操作从250G变成了50G）
现在的做法：
统计资产的系统
必要条件：
服务器的各种信息，需要实时的汇报变更记录
cmdb:
😊资产管理系统（以上的所有的系统都需要smdb作为前提，包括服务器的ip,硬盘，cpu等等，以上的系统可以向cmdb要数据，也就是cmdb写接口，然后其他系统可以调用cmdb使用，cmdb管理服务器各种信息包括变更记录也是实时汇报）
业界方案都差不多
本质上就是：收集服务器的各种信息😜
总：
-实现运维自动化，而CMDB是实现运维自动化的基石-之前公司统计资产的时候，使用Excel来统计，为了年底资产审计方便，因此需要做CMDB
二、开发cmdb的思路和大概做法
--使用python代码执行linux的命令，并且获取服务器上的对应信息
--使用Http协议发送执行好的数据
三、cmdb的四套方案
---agent模式🚘
采集的服务器们（客户端）都是gent，然后我们需要在每一台服务器上去部署这个采集的脚本，把采集的脚本叫agent脚本，agent脚本主要是写python代码的python就是执行linux命令的，使用的是subprocess 模块执行命令，接下来就是将执行的结果传给（使用requests模块post方法）服务端API，API拿到结果之后，都需要进行二次分析，将分析好的数据传给db数据，然后我可以起一个django的web服务去db中取数据创建django项目中test文件进行测试：
# 1.agent方案
import json #导模块快捷键，按alt+enter,再按enter
import subprocess
res=subprocess.getoutput('ipconfig') #采集windows这台机器的ip地址
print(res[30-40]) #这台服务器的信息，res最终类型就是字符串，使用字符串的一些方法将其获取
data = json.dumps(res[30-40])
import requests
ret = requests.post('http://127.0.0.1/8000',data=data)
优点：速度快缺点：每次都需要部署适用的场景： 服务器数量特别多的情况
---ssh类模式🚕
中控机的paramiko ,本质就是采用ssh协议22端口逐个的去连到采集的服务器上，就会执行命令，然后将结果返回给中控机，中控机还是通过request中的post将数据交给API，API拿到数据之后再进行一个处理，然后将数据存到db里面，起django服务连接db
创建django项目中test文件进行测试：
#2.ssh类方案
import paramiko
# 创建SSH对象
ssh = paramiko.SSHClient()
# 允许连接不在know_hosts文件中的主机
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
# 连接服务器
ssh.connect(hostname='47.102.110.185', port=22, username='root', password='yayayaya20.')
# 执行命令
stdin, stdout, stderr = ssh.exec_command('df') #stdin 是当xshell连接到服务器后安装软件yum ...会问你是否要安装也就是y/n，而stdin就是接受这个结果的
# 获取命令结果
result = stdout.read()
print(result)
# 关闭连接
ssh.close()
import requests
ret = requests.post("http://127.0.0.1/8000", data=data)
缺点：使用paramiko登录服务器的话， 速度比较慢优点： 不需要部署agent脚本适用场景： 服务器比较少 （100）
---比较以上两套方案的优缺点
第一套方案：-agent模式：优点：速度快缺点：每次都需要部署适用的场景：服务器数量特别多的情况-ssh类模式：缺点：使用paramiko登录服务器的话，速度比较慢优点：不需要部署agent脚本适用场景：服务器比较少
---saltstack模式🚃
（😁也是一个采集的架构，中控机上装着一个软件saltstack,是用python写的，然后也是需要saltstack里面装着saltack-master.需要在待采集的多台服务器上装一个软件salt-minion中控机是这样采集的salt'cmd.config'ip地址'‘ifconfig’本质就是，中控机先连上这些服务器去发linux相关的命令，发完之后，多台服务器会将结果返回给中控机，然后中控机拿到这些消息之后，post给API，然后API去连一下DB数据库，然后django起一个web服务去连接db数据，然后管理员就可以看到了😁）原理：中控机底层原理，将命令放到一个队列里面，叫zeromq,然后连上的服务端从zeromq里面取服务器要执行的而命令，然后又起了一个zeromq这样的队列，将结果放到新的zeromq里面，然后中控机去这里面取它的结果，优点：不用写python代码使用场景：-服务器上已经部署了salt-stack或想要使用salt-stack使用： sudo apt-get remove sudo apt-get remove salt-master ubuntu的配置文件怎么删除dpkg -l |grep ^rc|awk '{print $2}' |sudo xargs dpkg -P 软件apt autoremove连接服务器，创建一个会话，我的是阿里云ubuntu ,然后部署salt-master先下载apt-get salt-master然后启动服务service salt-master start 重启的话是service salt-master restart查看 service salt-master status再下载apt-get salt-minion启动service salt-minion start查看 ps aux | grep saltsalt-key -Lsalt-key -Asalt "*"cmd.run 'ifconfig'❗❗❗💥
开发的时候选择哪套方案三套方案都实现将三套方案集成一份代码里面，只需要在配置文件中修改配置就可以换方案，三套方案不一样的地方就是数据采集这里
https://lupython.gitee.io/2018/05/05/CMDB介绍/
---puppet模式（比较传统，不常用）🚜
ruby on railspuppet每隔30分钟会定时执行任务，跟方案都是一样的自动化运维的目的和愿景：将之前人工介入的所有的操作，全部变成各类系统降低人力成本
小总结：
1. 为什么要做CMDB？ - 实现运维自动化， 而CMDB是实现运维自动化的基石 - 之前公司统计资产的时候，使用Excel来统计， 为了年底资产审计方便，因此需要做CMDB 2. CMDB的架构方案是什么？ - 调研的几套方案 - agent - ssh类 - saltstack 3. 你们公司选用的是第几套方案? 根据公司的规模来去说 小公司的话， 第二套或者第三套 大公司的话， 第一套方案
来源：https://www.cnblogs.com/huangxuanya/p/11620427.html