CMDB與自動化運維,一切盡在掌握中?
生產力跟不上生產的速度時,就會出現很多問題,如何針對問題進行處理,制定什麼樣的計劃,如何解決就是需要思考的難點?
一、IT運維有哪些呢?
IT運維涉及的領域比較多,有參與到機房idc伺服器管理和維護的系統運維,有對網路進行管理和維護的,也有對系統上執行的業務進行管理和維護的,總的來說就是工作內容較多,而且繁雜,沒有較為準確的範圍.大致分為軟體運維,硬體運維也叫系統運維,網路運維,也不是在這麼的準確大家都是這麼稱呼.硬體運維呢主要包括對基礎設施的運維，比如機房的裝置，主機的硬碟，記憶體這些物理裝置的維護;軟體運維主要包括系統運維和應用運維，系統運維主要包括對OS，資料庫，中介軟體的監控和維護，這些系統介於裝置和應用之間;應用運維主要是對線上業務系統的運維.
這裡討論的主要是軟體運維的自動化，包括系統運維和應用運維的自動化.
二、傳統運維的痛點
日常工作繁瑣
日常運維工作是比較繁瑣的，研發同學會經常需要到伺服器上查日誌，重啟應用，或者是說今天上線某個產品，需要部署下環境。這些瑣事是傳統運維的大部分工作.
應用執行環境不統一
在部署某應用後，應用不能訪問，就會聽到開發人員說，在我的環境執行很好的，怎麼部署到測試環境後，就不能用了，因為各類環境的類庫不統一,還有一種極端情況，運維人員習慣不同，可能憑自己的習慣來安裝部署軟體，每種伺服器上執行軟體的目錄不統一
運維及部署效率低下
想想運維人員需要登陸到伺服器上執行命令，部署程式，不僅效率很低，並且非常容易出現人為的錯誤，一旦手工出錯，追溯問題將會非常不容易
無用報警資訊過多
經常會收到很多報警資訊，多數是無用的報警資訊，造成運維人員經常遮蔽報警信,另外如果應用的訪問速度出了問題，總是需要從系統、網路、應用、資料庫等一步步的查詢原因.
資產管理和應用管理混亂
資產管理，服務管理經常記錄在excel、文字檔案或者wiki中，不便於管理，老員工因為比較熟，不注重這些文件的維護，只有靠每次有新員工入職時，資產才能夠更正一次
三、自動化運維平臺的特性
針對傳統運維的痛點，我們可以知道自動化運維需要支援哪些功能?運維自動化最重要的就是標準化:
1.一切OS的選擇統一化，同一個專案使用同樣的OS系統部署其所需要的各類軟體
2.軟體安裝標準化，例如JAVA虛擬機器，php，nginx，mysql等各類應用需要的軟體版本，安裝目錄，資料存放目錄，日誌存放目錄等
3.應用包目錄統一標準化，及應用命名標準化
4.啟動指令碼統一目錄和名字，需要變化的部分通過引數傳遞
5.配置檔案標準化，需要變化的部分通過引數傳遞
6.日誌輸出，日誌目錄，日誌名字標準化
7.應用生成的資料要實現統一的目錄存放
8.主機/虛擬機器命名標準化，虛擬機器管理使用標準化模板
使用docker比較容易實現軟體執行環境的標準化
四、我們需要的自動化管理的工具叫什麼?------資產管理系統（CMDB）
CMDB是所有運維工具的資料基礎
五、CMDB包含的功能
使用者管理，記錄測試，開發，運維人員的使用者表
業務線管理，需要記錄業務的詳情
專案管理，指定此專案用屬於哪條業務線，以及專案詳情
應用管理，指定此應用的開發人員，屬於哪個專案，和程式碼地址，部署目錄，部署叢集，依賴的應用，軟體等資訊
主機管理，包括雲主機，物理機，主機屬於哪個叢集，執行著哪些軟體，主機管理員，連線哪些網路裝置，雲主機的資源池，儲存等相關資訊
主機變更管理，主機的一些資訊變更，例如管理員，所屬叢集等資訊更改，連線的網路變更等
網路裝置管理，主要記錄網路裝置的詳細資訊，及網路裝置連線的上級裝置
IP管理，IP屬於哪個主機，哪個網段, 是否被佔用等
六、CMDB實現的四種方式
（1）Agent指令碼實現方式
Agent方式，指的是agent的腳本里寫入了需要執行收集資訊的命令,並把agent指令碼部署到需要收集資訊的伺服器上時,將伺服器上面的Agent程式作定時任務，定時將資產資訊提交到指定API,然後錄入資料庫.其本質上就是在各個伺服器上執行subprocess.getoutput()命令，然後將每臺機器上執行的結果，返回給主機API，然後主機API收到採集的資料後，放入到資料庫中，最終通過web介面展現給使用者.
伺服器部署agent指令碼進行資料採集
優點：速度快
缺點：需要為每臺伺服器部署一個Agent程式
應用場景：大公司、伺服器數量多
（2）ssh實現方式（基於Paramiko模組）
部署一臺中控機,然後通過python的Paramiko（py模組）,此模組時基於ssh模式實現的遠端登陸,當登入到各個伺服器上後，就可以執行使用命令的方式去獲取各個伺服器上的需要採集的資訊.
paramiko模組進行ssh登陸執行cmd採集資訊
優點：不需要使用Agent指令碼
缺點：速度慢
應用場景：適合伺服器較少的環境
import paramiko
# 建立SSH物件
ssh = paramiko.SSHClient()
# 允許連線不在know_hosts檔案中的主機
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
# 連線伺服器
ssh.connect(hostname='c1.salt.com', port=22, username='root', password='123')
# 執行命令
stdin, stdout, stderr = ssh.exec_command('df')
# 獲取命令結果
result = stdout.read()
# 關閉連線
ssh.close()
（3）salt-stack 方式
此方案本質上和第二種方案大致是差不多的流程，部署好salt-master中控機後,由salt-master伺服器向其他的salt-minion伺服器(即salt的slave)傳送命令進行資料採集,salt-minion伺服器將返回的採集資料的結果放入 Q訊息佇列中，再將結果返回給salt-master中控機上,中控機再將獲取的服務資訊傳送到API,然後放入到資料庫。
slat-stack(master&slave)方式進行自動化控制採集資料
優點：快，開發成本低
缺點：依賴於第三方工具
應用場景：適合於公司一開始就使用這種方式，比較推薦
安裝以及配置
# master 端
# 1.安裝
salt-masteryum install salt-master
# 2.修改配置檔案
vim /etc/salt/masterinterface: 172.19.102.103# 表示master的ip
# 3.啟動
systemctl start salt-master
----------------------------------------------------------------------------------------------------------------------------
# slave 端
# 1.安裝
salt-minionyum install salt-minion
# 2.修改配置檔案
vim /etc/salt/minionmaster: 172.19.102.103 # 表示master的ip
# 3.啟動
systemctl start salt-minion
# 檢視是否啟動ps aux |grep salt-masterps aux |grep salt-minion
授權
salt-key -L # 檢視已授權和未授權的
slavesalt-key -a salve_id # 接受指定id的
salvesalt-key -r salve_id # 拒絕指定id的
salvesalt-key -d salve_id # 刪除指定id的salve
執行命令
# 授權成功後，主機（master）可以對 “奴隸機”（slave）進行遠端操作
# * 表示所有奴隸機salt '*' cmd.run 'ifconfig'
基於API的方式
import salt.client
local = salt.client.LocalClient()
result = local.cmd('c2.salt.com', 'cmd.run', ['ifconfig'])
以上時自動化的整體的需求分析和思路梳理,最終的落地和執行,需要整個開發team共同努力,相關的code,就需要自行動手搞起來了,加油小夥伴們.
注:文章如有疑問或錯誤之處,請留言評論指出,必將學習之.