目錄：
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 install salt-master
編輯vim /etc/salt/master
然后啟動服務service salt-master start 重啟的話是service salt-master restart
查看 service salt-master status
再下載apt-get install salt-minion
啟動service salt-minion start
編輯vim /etc/salt/minion
查看 ps aux | grep salt
salt-key -L
salt-key -A (授權給中控機)
salt-key -L (再次查看)
salt "*"cmd.run 'ifconfig' （執行命令）
❗❗❗💥
開發的時候選擇哪套方案
三套方案都實現
將三套方案集成一份代碼里面，只需要在配置文件中修改配置就可以換方案，三套方案不一樣的地方就是數據采集這里
https://lupython.gitee.io/2018/05/05/CMDB介紹/
---puppet模式（比較傳統，不常用）🚜
ruby on rails
puppet每隔30分鍾會定時執行任務，跟方案都是一樣的
自動化運維的目的和願景：
將之前人工介入的所有的操作，全部變成各類系統
降低人力成本
小總結：
1. 為什么要做CMDB？
- 實現運維自動化， 而CMDB是實現運維自動化的基石
- 之前公司統計資產的時候，使用Excel來統計， 為了年底資產審計方便，因此需要做CMDB
2. CMDB的架構方案是什么？
- 調研的幾套方案
- agent
- ssh類
- saltstack
3. 你們公司選用的是第幾套方案?
根據公司的規模來去說
小公司的話， 第二套或者第三套
大公司的話， 第一套方案