CMDB與自動化運維

時間 2019-11-30

原文原文鏈接

1、傳統的運維痛點

1.1 平常工做繁瑣

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

1.2 應用運行環境不統一

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

1.3 運維及部署效率低下

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

1.4 無用報警信息過多

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

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

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

2、自動化運維平臺特性

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

OS的選擇統一化，同一個項目使用一樣的OS系統部署其所須要的各種軟件

軟件安裝標準化，例如JAVA虛擬機，php，nginx，mysql等各種應用須要的軟件版本，安裝目錄，數據存放目錄，日誌存放目錄等

應用包目錄統一標準化，及應用命名標準化

啓動腳本統一目錄和名字，須要變化的部分經過參數傳遞

配置文件標準化，須要變化的部分經過參數傳遞

日誌輸出，日誌目錄，日誌名字標準化

應用生成的數據要實現統一的目錄存放

主機/虛擬機命名標準化，虛擬機管理使用標準化模板

使用docker比較容易實現軟件運行環境的標準化

3、資產管理系統（CMDB）

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

3.1 CMDB包含的功能

用戶管理，記錄測試，開發，運維人員的用戶表

業務線管理，須要記錄業務的詳情

項目管理，指定此項目用屬於哪條業務線，以及項目詳情

應用管理，指定此應用的開發人員，屬於哪一個項目，和代碼地址，部署目錄，部署集羣，依賴的應用，軟件等信息

主機管理，包括雲主機，物理機，主機屬於哪一個集羣，運行着哪些軟件，主機管理員，鏈接哪些網絡設備，雲主機的資源池，存儲等相關信息

主機變動管理，主機的一些信息變動，例如管理員，所屬集羣等信息更改，鏈接的網絡變動等

網絡設備管理，主要記錄網絡設備的詳細信息，及網絡設備鏈接的上級設備

IP管理，IP屬於哪一個主機，哪一個網段, 是否被佔用等

4、CMDB實現的四種方式

關鍵點：
　　1. 到linux服務器上，執行linux的命令，最終獲取服務器的信息
　　2. 用Python的方式執行linux命令，而後將執行的結果返回分析並最終入庫nginx

4.1 Agent實現方式

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

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

優勢：速度快
缺點：須要爲每臺服務器部署一個Agent程序sql

4.2 ssh實現方式（基於Paramiko模塊）

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

優勢：無Agent 缺點：速度慢

若是在服務器較少的狀況下，可應用此方法
import paramiko
   
# 建立SSH對象
ssh = paramiko.SSHClient()
# 容許鏈接不在know_hosts文件中的主機
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
# 鏈接服務器
ssh.connect(hostname='127.0.0.1', port=22, username='root', password='123')
   
# 執行命令
stdin, stdout, stderr = ssh.exec_command('df')
# 獲取命令結果
result = stdout.read()
   
# 關閉鏈接
ssh.close()

4.3 saltstack方式

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

優勢：快，開發成本低缺點：依賴於第三方工具

4.3.1 salstack的安裝與配置

一、安裝與配置

master端：
"""
1. 安裝salt-master
    　　yum install salt-master
　  　　yum install -y epel-release salt-master salt-minion
2. 修改配置文件：
　　　　vim /etc/salt/master
    # 第15行左右 打開註釋並修改 
　　　　interface: Master的IP地址    # 表示Master的IP 
3. 啓動
       service salt-master start
"""


slave端：
"""
　　1. 安裝salt-minion
    　　yum install salt-minion
　　2. 修改配置文件 
　　　　vim /etc/salt/minion
　　　　# 第15行左右 打開註釋並修改 
　　　　master: Master的IP地址   # master的地址 　　
　　3. 啓動 　　 service salt-minion start 
"""

二、受權

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

三、執行命令：在master服務器上對salve進行遠程操做

salt '*' cmd.run  'ifconfig'

基於API設計

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

# python3
import subprocess
cmd_info = "salt '%s' cmd.run  '%s'" % (self.hostname, cmd)
result = subprocess.getoutput(cmd_info)

參考安裝：

http://www.cnblogs.com/tim1blog/p/9987313.html
https://www.jianshu.com/p/84de3e012753

4.4 Puppet（ruby語言開發）（瞭解）

5、CMDB面試常見問題

5.1 爲啥要作CMDB系統

1. 本來公司使用的是EXCE表格用來，管理起來比較麻煩

2. 部門推行本身的自動化運維，CMDB是基石

5.2 調研CMDB的架構有哪些？

5.2.1 agent

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

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

5.2.2 ssh類

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

5.2.3 saltstack

中控機發送命令給服務器執行。服務器將結果放入另外一個隊列中，中控機獲取將服務信息發送到API進而錄入數據庫。

5.3 最終選取的方案

根據公司的業務需求決定

5.4 開發的時候，你負責哪塊

負責採集數據這一方面：

高級配置文件參考django的配置文件（用戶自定義的用用戶本身的，沒有自定義的用系統默認的配置）

高內聚低耦合思想

可插拔式的插件採集資產信息參考的django的中間件

5.5 開發過程當中遇到的問題

一、不知道需求 --- 溝通問題

二、Linux不熟悉 --- 百度，問老運維

三、惟一標識問題

# 經過選取hostname做爲每臺服務器的惟一表示，可是每臺機器的主機名可能會被開發更改，形成查詢資產時候丟失，所以提早分配好 ， 而且每臺服務器的主機名是惟一的，再分配給開發以前，咱們須要跑一遍client代碼， 此時採集到的信息是最乾淨的， hostname也是最原始分配的hostname能夠把這個最原始的hostname記錄到一個文件中，每次查詢時候，就按照最原始的記錄的數據進行查詢，這樣就能避免由於開發者更改主機名而形成查詢的遺漏