運維自動化和CMDB實現方法

CMDB和運維自動化

1、運維

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

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

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

2、軟件運維

傳統運維

• 平常工做繁瑣

平常運維工做是比較繁瑣的，研發同窗會常常須要到服務器上查日誌，重啓應用，或者是說今天上線某個產品，須要部署下環境。這些雜事是傳統運維的大部分工做

• 應用運行環境不統一

在部署某應用後，應用不能訪問，就會聽到開發人員說，在個人環境運行很好的，怎麼部署到測試環境後，就不能用了，由於各種環境的類庫不統一
還有一種極端狀況，運維人員習慣不一樣，可能憑本身的習慣來安裝部署軟件，每種服務器上運行軟件的目錄不統一

• 運維及部署效率低下

想一想運維人員須要登錄到服務器上執行命令，部署程序，不只效率很低，而且很是容易出現人爲的錯誤，一旦手工出錯，追溯問題將會很是不容易

• 無用報警信息過多

常常會收到不少報警信息，多數是無用的報警信息，形成運維人員常常屏蔽報警信
另外若是應用的訪問速度出了問題，老是須要從系統、網絡、應用、數據庫等一步步的查找緣由

• 資產管理和應用管理混亂

常常會收到不少報警信息，多數是無用的報警信息，形成運維人員常常屏蔽報警信
另外若是應用的訪問速度出了問題，老是須要從系統、網絡、應用、數據庫等一步步的查找緣由

自動化運維

針對傳統運維的痛點，咱們能夠知道自動化運維須要支持哪些功能

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

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

3、CMDB

功能

1. 用戶管理，記錄測試，開發，運維人員的用戶表
2. 業務線管理，須要記錄業務的詳情
3. 項目管理，指定此項目用屬於哪條業務線，以及項目詳情
4. 應用管理，指定此應用的開發人員，屬於哪一個項目，和代碼地址，部署目錄，部署集羣，依賴的應用，軟件等信息
5. 主機管理，包括雲主機，物理機，主機屬於哪一個集羣，運行着哪些軟件，主機管理員，鏈接哪些網絡設備，雲主機的資源池，存儲等相關信息
6. 主機變動管理，主機的一些信息變動，例如管理員，所屬集羣等信息更改，鏈接的網絡變動等
7. 網絡設備管理，主要記錄網絡設備的詳細信息，及網絡設備鏈接的上級設備
8. 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 '命令'