cmdb簡介

目錄：

1.爲啥要作cmdb👀

2.開發cmdb的思路和大概作法👀

3.cmdb的四套方案👀

 

 

 

 

1、爲啥要作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

 

 

 

2、開發cmdb的思路和大概作法

--使用python代碼執行linux的命令，而且獲取服務器上的對應信息

--使用Http協議發送執行好的數據

 

 

 

 

 

 

 

3、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 salt
salt-key -L
salt-key -A
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. 大家公司選用的是第幾套方案?
   
   根據公司的規模來去說
   
   小公司的話， 第二套或者第三套
   大公司的話， 第一套方案