運維自動化和CMDB實現方法

CMDB和運維自動化

一、運維

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

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

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

二、軟件運維

傳統運維

• 日常工作繁瑣

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

• 應用運行環境不統一

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

• 運維及部署效率低下

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

• 無用報警信息過多

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

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

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

自動化運維

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

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

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

三、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 '命令'