CMDB和運維自動化

一、運維

運維，指的是對已經搭建好的網絡，軟件，硬件進行維護。運維領域也是細分的，有硬件運維和軟件運維

硬件運維主要包括對基礎設施的運維，比如機房的設備，主機的硬盤，內存這些物理設備的維護
軟件運維主要包括系統運維和應用運維，系統運維主要包括對OS，數據庫，中間件的監控和維護，這些系統介于設備和應用之間，應用運維主要是對線上業務系統的運維

討論的主要是軟件運維的自動化，包括系統運維和應用運維的自動化

二、軟件運維

傳統運維

日常工作繁瑣

日常運維工作是比較繁瑣的，研發同學會經常需要到服務器上查日志，重啟應用，或者是說今天上線某個產品，需要部署下環境。這些瑣事是傳統運維的大部分工作

應用運行環境不統一

在部署某應用后，應用不能訪問，就會聽到開發人員說，在我的環境運行很好的，怎么部署到測試環境后，就不能用了，因為各類環境的類庫不統一
還有一種極端情況，運維人員習慣不同，可能憑自己的習慣來安裝部署軟件，每種服務器上運行軟件的目錄不統一

運維及部署效率低下

想想運維人員需要登陸到服務器上執行命令，部署程序，不僅效率很低，并且非常容易出現人為的錯誤，一旦手工出錯，追溯問題將會非常不容易

無用報警信息過多

經常會收到很多報警信息，多數是無用的報警信息，造成運維人員經常屏蔽報警信
另外如果應用的訪問速度出了問題，總是需要從系統、網絡、應用、數據庫等一步步的查找原因

資產管理和應用管理混亂

經常會收到很多報警信息，多數是無用的報警信息，造成運維人員經常屏蔽報警信
另外如果應用的訪問速度出了問題，總是需要從系統、網絡、應用、數據庫等一步步的查找原因

自動化運維

針對傳統運維的痛點，我們可以知道自動化運維需要支持哪些功能

? 運維自動化最重要的就是標準化一切

OS的選擇統一化，同一個項目使用同樣的OS系統部署其所需要的各類軟件
軟件安裝標準化，例如JAVA虛擬機，php，nginx，mysql等各類應用需要的軟件版本，安裝目錄，數據存放目錄，日志存放目錄等
應用包目錄統一標準化，及應用命名標準化
啟動腳本統一目錄和名字，需要變化的部分通過參數傳遞
配置文件標準化，需要變化的部分通過參數傳遞
日志輸出，日志目錄，日志名字標準化
應用生成的數據要實現統一的目錄存放
主機/虛擬機命名標準化，虛擬機管理使用標準化模板
使用docker比較容易實現軟件運行環境的標準化

三、CMDB

功能

用戶管理，記錄測試，開發，運維人員的用戶表
業務線管理，需要記錄業務的詳情
項目管理，指定此項目用屬于哪條業務線，以及項目詳情
應用管理，指定此應用的開發人員，屬于哪個項目，和代碼地址，部署目錄，部署集群，依賴的應用，軟件等信息
主機管理，包括云主機，物理機，主機屬于哪個集群，運行著哪些軟件，主機管理員，連接哪些網絡設備，云主機的資源池，存儲等相關信息
主機變更管理，主機的一些信息變更，例如管理員，所屬集群等信息更改，連接的網絡變更等
網絡設備管理，主要記錄網絡設備的詳細信息，及網絡設備連接的上級設備
IP管理，IP屬于哪個主機，哪個網段, 是否被占用等

CMDB實現的方式

1.Agent實現方式

Agent實現方式，可以將服務器上面的Agent程序作定時任務，定時將資產信息提交到指定API錄入數據庫

實現流程

1.在每臺服務器上都有一個agent腳本，也就是python程序，其核心就是subprocess模塊的subprocess.getoutput('命令')

2.每天定時觸發subprocess.getoutput('命令')，其返回值是命令的執行結果，將其發送到API中

3.API會把收到的數據進行處理，然后再存儲到db，也就是數據庫中

4.用戶就可以通過后臺管理系統，直觀的看到每臺服務器的各種信息




# 優缺點
# 優點
    1.執行速度快，適用于擁有超多服務器的大型公司
    
# 缺點
    1.每臺服務器都必須部署一個agent腳本

核心代碼

# 通過subprocess模塊，在本地端運行命令，獲取信息
import  subprocess
res = subprocess.getoutput('ipconfig')
# 模擬對返回數據的切分
print(res[5:6])

# request模塊
import requests
# http://127.0.0.1:8000/asset/：是API的一個接口，通過request模塊發送請求并攜帶切分后的數據，交給API，API會存入到數據庫
res = requests.post('http://127.0.0.1:8000/asset/', data={"ip":res[5:6]})

2.SSH實現方式(基于Paramiko模塊)

中控機通過Paramiko（py模塊）登錄到各個服務器上，然后執行命令的方式去獲取各個服務器上的信息

實現流程

1.與agent的不同，SSH實現方式是把python代碼放在了單獨的的一個服務器上，這個服務器稱之為中控機

2.中控機通過Paramiko模塊以SSH方式鏈接，向服務器發送命令，然后獲得其返回數據，并轉交給API

3.API會把收到的數據進行處理，然后再存儲到db，也就是數據庫中

4.用戶就可以通過后臺管理系統，直觀的看到每臺服務器的各種信息




# 優缺點
# 優點
    1.相比agent方式，不用在每臺服務器上都放一份腳本
    2.適用于服務器較少的場景
    
# 缺點
    1.這種方式會限制于網絡，所以速度慢
    2.需要部署一臺中控機

核心代碼

import paramiko

# 創建SSH對象
ssh = paramiko.SSHClient()
# 允許連接不在know_hosts文件中的主機
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
# 連接服務器
ssh.connect(hostname='10.0.0.100', port=22, username='root', password='1')

# 執行命令
stdin, stdout, stderr = ssh.exec_command('ifconfig')
# 獲取命令結果
result = stdout.read()
print(result)
# 關閉連接
ssh.close()

3.saltstack方式

通過第三方軟件來實現鏈接服務器并執行命令

實現流程

1.該方案與第二種方案類似，但是卻依靠第三方軟件saltstack，saltstack有兩個身份，master和minion，也就是主人和奴隸，我們可以給中控機分配master的身份來控制所有的minion服務器

2.中控機salt-master通過salt 'minion主機名' cmd.run '命令'，向服務器minion發送命令，minion會把執行結果放到隊列中，然后master從隊列中取出數據，并轉交給API

3.API會把收到的數據進行處理，然后再存儲到db，也就是數據庫中

4.用戶就可以通過后臺管理系統，直觀的看到每臺服務器的各種信息




# 優缺點
# 優點
    1.執行速度快，開發成本低
    
# 缺點
    1.比較依賴于第三方軟件
    2.需要部署一臺中控機

saltstack的安裝、配置及使用

master端：

# 1.安裝salt-master
    yum install salt-master -y
# 2.修改配置文件：/etc/salt/master
    vim /etc/salt/master
    interface: 10.0.0.100 # Master的IP     
# 3.啟動
    service salt-master start


slave端：

# 1.安裝salt-minion
    yum install salt-minion -y
# 2.修改配置文件 /etc/salt/minion
    vim /etc/salt/minion
    # 單個master
    master: 10.0.0.100           # master的地址
    # 多個master
    master:
        - 10.211.55.4
        - 10.211.55.5
    random_master: True
    id: c2.salt.com       # 客戶端在salt-master中顯示的唯一ID
# 3.啟動
    service salt-minion start

    
# 4.使用
# master服務器上對salve進行遠程操作
    salt 'minion主機名' cmd.run '命令'

總結

以上是生活随笔為你收集整理的浅谈CMDB的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。