自動化運維

自動化運維的概念：

IT運維，指的是對已經搭建好的網絡，軟件，硬件進行維護。運維領域也是細分的，有硬件運維和軟件運維
分類：
    硬件運維：IDC運維，硬件運維主要包括對基礎設施的運維，好比機房的設備，主機的硬盤，內存這些物理設備的維護
  軟件運維：主要包括系統運維和應用運維，系統運維主要包括對OS，數據庫，中間件的監控和維護，這些系統介於設備和應用之間，應用運維主要是對線上業務系統的運維。好比說對mysql進行備份管理，對nginx，apache軟件的管理以及配置
  shell 腳本（基本語言）
  
傳統運維的特色：平常工做繁瑣，應用運行環境單一，運維及部署效率低下，無用報警信息過多，資產管理及應用管理混亂

自動化運維平臺的特性

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

CMDB

是自動化運維的一個基石
全稱：配置管理數據庫
做用：收集服務器的各類信息 （包括收集服務器的內存，硬盤，CPU，IP， 主機名等信息）

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

1.Agent實現方式：
Agent方式，能夠將服務器上面的Agent程序做定時任務，定時將資產信息提交到指定API錄入數據庫

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

優勢：速度快
缺點：部署比較麻煩， 每次新增一臺服務器，都須要部署相應的腳本
使用場景：服務器多（500臺以上）的場景

如何使用python執行linux命令---subprocess
如何將拿到的結果返回給api---啓動一個django服務，鏈接請求requests庫傳輸數據
「header：Content-Type:application/json----只能從request.body中獲取數據
header:application/x-www-form-urlencoded----會將request.body中的值賦值給request.POST」

2.ssh實現方式（基於Paramiko模塊）運維裏面是ansible

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

優勢：無Agent，相比於第一套方案來講， 不須要額外的部署代碼

缺點：相比於第一套方案來講， 速度比較慢， 由於它須要進行ssh的鏈接

若是在服務器較少的狀況下，可應用此方法
************************************
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()
************************************

3.saltstack方式
此方案本質上和第二種方案大體是差很少的流程，中控機發送命令給服務器執行。服務器將結果放入另外一個隊列中，中控機獲取將服務信息發送到API進而錄入數據庫。
安裝和配置
master端
"""

1. 安裝salt-master
   yum install salt-master
2. 修改配置文件：/etc/salt/master
   interface: 0.0.0.0 # 表示Master的IP
3. 啓動
   service salt-master start
   """
   slave端：
   """
4. 安裝salt-minion
   yum install salt-minion
5. 修改配置文件 /etc/salt/minion
   master: 10.211.55.4 # master的地址
   或
   master:
   - 10.211.55.4
   - 10.211.55.5
   random_master: True
   id: c2.salt.com # 客戶端在salt-master中顯示的惟一ID
6. 啓動
   service salt-minion start
   """

底層原理是zeromq隊列

優勢：快，開發成本低

缺點：依賴於第三方工具，依賴saltstack軟件

---

"""
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
"""
在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'])

4.puppet方案（沒人用 ruby on rails）

第一種：

第二種

第三種