【CMDB和自動化運維】

1、IT運維的分類

　　運維，是公司中一個必不可缺的職位，它的工做指的是對已經搭建好的網絡，軟件，硬件進行維護。運維領域也是細分的，有硬件運維（基礎運維）和軟件運維（應用運維）。

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

 2、傳統運維的痛點

平常工做繁瑣

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

應用運行環境不一

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

 運維及部署效率低下

　　部署項目或者應用時，運維人員須要登陸服務器上執行命令，不只僅效率很低，而且很是容易出現人爲的錯誤，一旦出現人爲的錯誤，追溯問題將會很是不容易。

無用報警信息過多

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

資產管理和應用管理混亂

　　資產管理，服務管理常常記錄在excel、文本文件或者wiki中，不便於管理，老員工由於比較熟，不注重這些文檔的維護，只有靠每次有新員工入職時，資產才能更正一次。

3、自動化運維平臺的特性

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

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

4、資產管理系統（CMDB）

CMDB系統是全部運維工具的數據基礎

CMDB包含的功能

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

CMDB實現的四種方式

•  Agent實現方式

Agent方式實現CMDB，在每臺服務器上部署Agent腳本，將服務器上的Agent程序做爲定時任務，定時將資產信息提交到指定API，進行
數據分析與清洗後錄入數據庫。

其本質上就是在各個服務器上執行subprocess.getoutput（）命令，而後將每臺機器上的執行的結果，返回給主機API，而後主機
API接受到這些數據後，放入到數據庫，最終經過web界面展示給用戶。

優勢：速度快

缺點：須要爲每臺服務器都部署一個Agent程序

應用場景：服務器較多的狀況下推薦使用

• ssh實現方式

中控機經過Paramiko模塊登陸到各個服務器上，而後以執行命令的方式去獲取各個服務器上的信息。

優勢：無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()

python代碼

• salt-stack方式實現

此方案本質上和第二種方案大體是差很少的流程，中控機發送命令給服務器。服務器將結果放入另一個隊列中，中控機獲取將服
務器信息發送至API主機而錄入數據庫。

優勢：速度快，開發成本低

缺點:依賴於第三方工具

salt-stack的安裝與配置

1.安裝與配置

master端：
"""
1.安裝salt-master
    yum install salt-master
2.修改配置文件：/etc/salt/master
    interface:0.0.0.0  #表示Master的Ip
3.啓動
    server salt-master start 
"""
minion端：
"""
1.安裝salt-minion
    yum install salt-minion
2.修改配置文件：/etc/salt/minion
    master:10.0.0.51 #master的ip地址
    或者（多個master，隨機選擇）
    master:
      - 10.0.0.51
      - 10.0.0.52
      random_master:True    
    id：c2.salt.com  #客戶端在salt-master中顯示的惟一ID
3.啓動
    service salt-minion start
"""

2.受權

"""
salt-key -L     #查看以受權和未受權的slave
salt-key -a salve_id  #接受指定id的salve
salt-key -r salve_id  #拒絕指定id的salve
salt-key -d salve_id  #刪除指定id的salve 
"""

3.執行命令

在Master服務器上對salve進行遠程操做

salt 'c2.salt.com' cmd.run 'ifconfig'

基於API的方式

import salt.client
local = salt.client.LocalClient()
result = local.cmd('c2.salt.com','cmd.run',['ifconfig'])

參考安裝：

http://www.cnblogs.com/tim1blog/p/9987313.html

https://www.jianshu.com/p/84de3e012753

• Puppet（ruby語言開發）方式實現

每隔30分鐘，經過RPC消息隊列將執行的結果返回給用戶