CMDB和運維自動化

時間 2019-11-11

原文原文鏈接

本文目錄

ITIL

TIL，即基礎架構庫（Information Technology Infrastructure Library，ITIL，信息技術基礎架構庫）由英國由英國政府部門CCTA(Central Computing and Telecommunications Agency)在20世紀80年代末制訂，現由英國商務部OGC(Office of Government Commerce)負責管理，主要適用於IT服務管理（ITSM）。ITIL爲企業的IT服務管理實踐提供了一個客觀、嚴謹、可量化的標準和規範。python

一、事件管理（Incident Management）mysql

事故管理負責記錄、歸類和安排專家處理事故並監督整個處理過程直至事故獲得解決和終止。事故管理的目的是在儘量最小地影響客戶和用戶業務的狀況下使IT系統恢復到服務級別協議所定義的服務級別。nginx

目標是：在不影響業務的狀況下，儘量快速的恢復服務，從而保證最佳的效率和服務的可持續性。事件管理流程的創建包括事件分類，肯定事件的優先級和創建事件的升級機制。web

二、問題管理（Problem Management）sql

問題管理是指經過調查和分析IT基礎架構的薄弱環節、查明事故產生的潛在緣由，並制定解決事故的方案和防止事故再次發生的措施，將因爲問題和事故對業務產生的負面影響減少到最低的服務管理流程。與事故管理強調事故恢復的速度不一樣，問題管理強調的是找出事故產生的根源，從而制定恰當的解決方案或防止其再次發生的預防措施。docker

目標是：調查基礎設施和全部可用信息，包括事件數據庫，來肯定引發事件發生的真正潛在緣由，一塊兒提供的服務中可能存在的故障。shell

三、配置管理（Configuration Management）數據庫

配置管理是識別和確認系統的配置項，記錄和報告配置項狀態和變動請求，檢驗配置項的正確性和完整性等活動構成的過程，其目的是提供IT基礎架構的邏輯模型，支持其它服務管理流程特別是變動管理和發佈管理的運做。

目標是：定義和控制服務與基礎設施的部件，並保持準確的配置信息。

四、變動管理（Change Management）

變動管理是指爲在最短的中斷時間內完成基礎架構或服務的任一方面的變動而對其進行控制的服務管理流程。變動管理的目標是確保在變動實施過程當中使用標準的方法和步驟，儘快地實施變動，以將由變動所致使的業務中斷對業務的影響減少到最低。

目標是：以受控的方式，確保全部變動獲得評估、批准、實施和評審。

五、發佈管理（Release Management）

發佈管理是指對通過測試後導入實際應用的新增或修改後的配置項進行分發和宣傳的管理流程。發佈管理之前又稱爲軟件控制與分發。

目標是：在實際運行環境的發佈中，交付、分發並跟蹤一個或多個變動。

IT運維分類

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

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

軟件運維自動化，包括系統運維和應用運維的自動化。

傳統運維痛點

平常工做繁瑣

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

應用運行環境不統一

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

運維及部署效率低下

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

無用報警信息過多

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

資產管理和應用管理混亂

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

自動化運維平臺的特性

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

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

資產管理系統（CMDB）

　　CMDB（Configuration Management Database）配置管理數據庫，CMDB存儲與管理企業IT架構中設備的各類配置信息，它與全部服務支持和服務交付流程都緊密相連，支持這些流程的運轉、發揮配置信息的價值，同時依賴於相關流程保證數據的準確性。

　　在實際的項目中，CMDB經常被認爲是構建其餘ITIL流程的基礎而優先考慮，ITIL項目的成敗與是否創建CMDB有很是大的關係。

70%～80%的IT相關問題與環境的變動有着直接的關係。實施變動管理的難點和重點並非工具，而是流程。即經過一個自動化的、可重複的流程管理變動，使得當變動發生的時候，有一個標準化的流程去執行，可以預測到這個變動對整個系統管理產生的影響，並對這些影響進行評估和控制。而變動管理流程自動化的實現關鍵就是CMDB。

CMDB工具中至少包含這幾種關鍵的功能：整合、調和、同步、映射和可視化。

整合是指可以充分利用來自其餘數據源的信息，對CMDB中包含的記錄源屬性進行存取，將多個數據源合併至一個視圖中，生成連同來自CMDB和其餘數據源信息在內的報告；
調和能力是指經過對來自每一個數據源的匹配字段進行對比，保證CMDB中的記錄在多個數據源中沒有重複現象，維持CMDB中每一個配置項目數據源的完整性；自動調整流程使得初始實施、數據庫管理員的手動運做和現場維護支持工做降至最低；
同步指確保CMDB中的信息可以反映聯合數據源的更新狀況，在聯合數據源更新頻率的基礎上肯定CMDB更新日程，按照通過批准的變動來更新 CMDB，找出未被批准的變動；
應用映射與可視化，說明應用間的關係並反應應用和其餘組件之間的依存關係，瞭解變動形成的影響並幫助診斷問題。

CMDB是運維自動化項目，它能夠減小人工干預，下降人員成本。

　　功能：自動裝機、實時監控、自動化部署軟件，創建在它們的基礎上是資產信息變動記錄（資產管控自動進行彙報）

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

CMDB包含的功能

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

CMDB實現的四種方式

第一種：Agent實現方式（基於shell命令實現）

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

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

1.將subprocess執行的代碼放到每臺服務器上
2.定時（crontab）的執行收集代碼，但結果還在服務器上
3.將執行的結果返回給咱們的某一臺收集的總服務器

View Code

優勢：速度快

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

第二種：Paramiko類（SSH形式，基於Paramiko模塊）

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

優勢：不須要爲每臺服務器部署一個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()

第三種：saltstack方式

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

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

缺點：依賴saltstack軟件（第三方工具）

saltstack的安裝和配置

1 安裝和配置

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端：
"""
1. 安裝salt-minion
    yum install salt-minion
2. 修改配置文件 /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
3. 啓動
    service salt-minion start

ps aux | grep salt-master   #查看salt-master有沒有啓動

ps aux | grep salt-minion  #查看salt-minion進程

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
salt-key -A　　　　　　　　　　#容許全部

3 執行命令

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

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

或

salt "*" cmd.run "ifconfig"  #向全部salt-minion發送命令

基於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消息隊列將執行的結果返回給用戶

基於Puppet的factor和report功能實現

 1 puppet中默認自帶了5個report，放置在【/usr/lib/ruby/site_ruby/1.8/puppet/reports/】路徑下。若是須要執行某個report，那麼就在puppet的master的配置文件中作以下配置：
 2  
 3 ######################## on master ###################
 4 /etc/puppet/puppet.conf
 5 [main]
 6 reports = store #默認
 7 #report = true #默認
 8 #pluginsync ＝ true #默認
 9  
10  
11 ####################### on client #####################
12  
13 /etc/puppet/puppet.conf
14 [main]
15 #report = true #默認
16    
17 [agent]
18 runinterval = 10
19 server = master.puppet.com
20 certname = c1.puppet.com
21  
22 如上述設置以後，每次執行client和master同步，就會在master服務器的 【/var/lib/puppet/reports】路徑下建立一個文件，主動執行：puppet agent  --test

自定義factor示例

 1 在 /etc/puppet/modules 目錄下建立以下文件結構：
 2  
 3 modules
 4 └── cmdb
 5     ├── lib
 6     │   └── puppet
 7     │       └── reports
 8     │           └── cmdb.rb
 9     └── manifests
10         └── init.pp
11  
12 ################ cmdb.rb ################
13 # cmdb.rb
14 require 'puppet'
15 require 'fileutils'
16 require 'puppet/util'
17    
18 SEPARATOR = [Regexp.escape(File::SEPARATOR.to_s), Regexp.escape(File::ALT_SEPARATOR.to_s)].join
19    
20 Puppet::Reports.register_report(:cmdb) do
21   desc "Store server info
22     These files collect quickly -- one every half hour -- so it is a good idea
23     to perform some maintenance on them if you use this report (it's the only
24     default report)."
25    
26   def process
27     certname = self.name
28     now = Time.now.gmtime
29     File.open("/tmp/cmdb.json",'a') do |f|
30       f.write(certname)
31       f.write(' | ')
32       f.write(now)
33       f.write("\r\n")
34     end
35    
36   end
37 end
38  
39  
40 ################ 配置 ################
41 /etc/puppet/puppet.conf
42 [main]
43 reports = cmdb
44 #report = true #默認
45 #pluginsync ＝ true #默認

小結：

採集資產信息有四種不一樣的形式（puppet是基於ruby開發的）
API提供相關處理接口
管理平臺爲用戶提供可視化操做

    傳統運維和自動化運維的區別:

    傳統運維:
        1. 項目上線:
            a. 產品經理前期調研 (需求分析)
            b. 和開發進行評審
            c. 開發進行開發
            d. 測試進行測試
            e. 交給運維人員進行上線
        
        上線:
            直接將代碼給運維人員,讓業務運維人員把代碼放到服務器上
        
        痛點:
            增長運維的成本
        
        改進:
            搞一個自動分發代碼的系統 
            必須的條件:
                服務器的信息(ip, hostname等)
        
        2. 能不能把報警自動化
        
        3. 裝機系統:
            傳統的裝機和佈線:
                idc運維 
                    
                    用大量的人力和物力,來進行裝機
                
                自動運維:
                    
                    collober 自動發送命令裝機
        
        4. 收集服務器的元信息:
            a. excel表格
                缺點: 
                    - 人爲干預太嚴重
                    - 統計的時候也會有問題
            
            b. 搞一個系統
                做用: 自動的幫我收集服務器的信息,而且自動的記錄咱們的變動信息
            
        cmdb: (********************)
            
            做用: 自動的幫我收集服務器的信息,而且自動的記錄咱們的變動信息
            
        願景:
            解放雙手, 讓全部的東西所有的都自動化
        
    開始收集服務器的元數據:
        
        在實際開發中,收集服務器的信息總共有4種方案: (****************************************)
            
            
            1. agent方式:
                - agent腳本
                - API
                - web界面
                
            2. ssh類(parmiko, frbric, ansible)
                - parmiko模塊 (獲取主機名)
                - API
                - web界面
            
            3. salt-stack方式(python3):
                - slat-stack軟件
                - API
                - web界面
                
            4. puppet(ruby)(瞭解便可)
            
            畫圖(echarts highcharts)
            
        大體的步驟:
            
            1. 收集服務器的信息
    
            2. 數據提交給API
            
            3. web頁面展現
        
        crontab:
            13  11   *   *   *   *     python3 test.py  > a.txt
            分  時  日  月  周  年
        
        
        Hexo + markdown 寫博客
        
        gap year
        
    寫代碼:
        三種CMDB採集的方案:
            - agent方式採集: 
                - 場景: 服務器比較多
                - 缺點: 須要每一臺服務器上部署
                - 優勢: 速度快
            
            - ssh類(parmiko fabric ansible):
                - 缺點: 速度慢  須要一臺中控機
                - 優勢: 不須要部署agent腳本
                - 場景: 服務器比較少
            
            - salt-stack方式:
                - 缺點: 每一臺須要部署這個軟件
                - 優勢: 速度快, 開發成本低
                - 場景: 企業以前已經在用
        
        
        目標:
            
            三種方案咱們都要實現兼容
            只須要改配置文件裏面的一個配置,咱們就可以自如的切換
            
            
        採集服務器的信息代碼編寫(1/3)
            
            項目的目錄結構:
                - bin : 執行文件夾
                - config: 自定義配置文件
                - lib: 公共的模塊或者類文件
                - src: 核心業務邏輯代碼
                - tests: 測試的亂代碼
                
            
            
            配置文件的編寫:
                目標: 寫一個相似於django的配置方法