1、運維
運維，指的是對已經搭建好的網絡，軟件，硬件進行維護。運維領域也是細分的，有硬件運維和軟件運維python
- 硬件運維主要包括對基礎設施的運維，好比機房的設備，主機的硬盤，內存這些物理設備的維護
- 軟件運維主要包括系統運維和應用運維，系統運維主要包括對OS，數據庫，中間件的監控和維護，這些系統介於設備和應用之間，應用運維主要是對線上業務系統的運維
討論的主要是軟件運維的自動化，包括系統運維和應用運維的自動化mysql
2、軟件運維
傳統運維
- 平常工做繁瑣
平常運維工做是比較繁瑣的，研發同窗會常常須要到服務器上查日誌，重啓應用，或者是說今天上線某個產品，須要部署下環境。這些雜事是傳統運維的大部分工做
- 應用運行環境不統一
在部署某應用後，應用不能訪問，就會聽到開發人員說，在個人環境運行很好的，怎麼部署到測試環境後，就不能用了，由於各種環境的類庫不統一 還有一種極端狀況，運維人員習慣不一樣，可能憑本身的習慣來安裝部署軟件，每種服務器上運行軟件的目錄不統一
- 運維及部署效率低下
想一想運維人員須要登錄到服務器上執行命令，部署程序，不只效率很低，而且很是容易出現人爲的錯誤，一旦手工出錯，追溯問題將會很是不容易
- 無用報警信息過多
常常會收到不少報警信息，多數是無用的報警信息，形成運維人員常常屏蔽報警信 另外若是應用的訪問速度出了問題，老是須要從系統、網絡、應用、數據庫等一步步的查找緣由
- 資產管理和應用管理混亂
常常會收到不少報警信息，多數是無用的報警信息，形成運維人員常常屏蔽報警信 另外若是應用的訪問速度出了問題，老是須要從系統、網絡、應用、數據庫等一步步的查找緣由
自動化運維
針對傳統運維的痛點，咱們能夠知道自動化運維須要支持哪些功能nginx
運維自動化最重要的就是標準化一切sql
- OS的選擇統一化，同一個項目使用一樣的OS系統部署其所須要的各種軟件
- 軟件安裝標準化，例如JAVA虛擬機，php，nginx，mysql等各種應用須要的軟件版本，安裝目錄，數據存放目錄，日誌存放目錄等
- 應用包目錄統一標準化，及應用命名標準化
- 啓動腳本統一目錄和名字，須要變化的部分經過參數傳遞
- 配置文件標準化，須要變化的部分經過參數傳遞
- 日誌輸出，日誌目錄，日誌名字標準化
- 應用生成的數據要實現統一的目錄存放
- 主機/虛擬機命名標準化，虛擬機管理使用標準化模板
- 使用docker比較容易實現軟件運行環境的標準化
3、CMDB
功能
- 用戶管理，記錄測試，開發，運維人員的用戶表
- 業務線管理，須要記錄業務的詳情
- 項目管理，指定此項目用屬於哪條業務線，以及項目詳情
- 應用管理，指定此應用的開發人員，屬於哪一個項目，和代碼地址，部署目錄，部署集羣，依賴的應用，軟件等信息
- 主機管理，包括雲主機，物理機，主機屬於哪一個集羣，運行着哪些軟件，主機管理員，鏈接哪些網絡設備，雲主機的資源池，存儲等相關信息
- 主機變動管理，主機的一些信息變動，例如管理員，所屬集羣等信息更改，鏈接的網絡變動等
- 網絡設備管理，主要記錄網絡設備的詳細信息，及網絡設備鏈接的上級設備
- IP管理，IP屬於哪一個主機，哪一個網段, 是否被佔用等
CMDB實現的方式
1.Agent實現方式
Agent實現方式，能夠將服務器上面的Agent程序做定時任務，定時將資產信息提交到指定API錄入數據庫docker
實現流程數據庫
1.在每臺服務器上都有一個agent腳本，也就是python程序，其核心就是subprocess模塊的subprocess.getoutput('命令') 2.天天定時觸發subprocess.getoutput('命令')，其返回值是命令的執行結果，將其發送到API中 3.API會把收到的數據進行處理，而後再存儲到db，也就是數據庫中 4.用戶就能夠經過後臺管理系統，直觀的看到每臺服務器的各類信息 # 優缺點 # 優勢 1.執行速度快，適用於擁有超多服務器的大型公司 # 缺點 1.每臺服務器都必須部署一個agent腳本
核心代碼vim
# 經過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模塊）登陸到各個服務器上，而後執行命令的方式去獲取各個服務器上的信息服務器
實現流程markdown
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 '命令'