一個通用應用運維管控平臺的設計實現

編寫完成后解析成格式化的數據，比如下面表格：

key value region.id 7001 region.name js region.mongodb.hosts [‘172.27.117.201’，’172.27.117.202’，’172.27.117.203’] region.mongodb.port 27017

用戶可以選擇兩種可視化方式，但使用的時候需要按照解析后格式化的方式來使用，比如用戶在模板中需要使用某個region的mongodb的服務器列表，則需要這種方式來使用：region.mongodb.hosts ， 如果需要進一步處理該數據，可以在模板文件中直接使用Python語法處理，這個在模板管理中再介紹。

之所以需要有變量管理，就是因為模板管理的存在，很多配置需要按照不同的環境生成，而這些環境就需要有變量管理這個功能來控制。

變量管理細分可以分為幾個維度：

■全局變量

全局變量指的是那些在任何場景下都只有一個的變量，可能會改變，但全局只有這一個變量，它一變會影響到所有的使用它的模板。

■組變量

組變量是指和分組管理結合后對某個分組設置的變量，組變量的使用場合比較多，而且不同的分組之間可能還有優先級的問題，因此需要在分組的時候設置組的優先級。

建議將組的優先級分為如下幾類：

■全局組(級別最低)

■IDC組(級別次之)

■Set組(級別次之)

■自定義組(級別次之)

■主機變量

主機變量是主機級別的動態變量，具有較高的優先級，建議結合資源管理系統使用，可以給每一臺物理主機(虛擬主機)都設置一組相應的動態變量，比如某個set的某些mongodb集群，需要區分主、從，設置的變量可以這個樣子：

172.27.117.252 id=0 priority=2 arbiterOnly=False 172.27.117.248 id=1 priority=1 arbiterOnly=False 172.27.117.247 id=2 priority=0 arbiterOnly=True

在服務部署的時候可以根據相應的優先級決定生成的配置文件的不同，甚至執行腳本的不同。

■任務變量

任務變量是具有最高優先級的變量，這個變量只有任務執行的時候，通過輸入的參數來控制，該變量實際并不進行管理，使用用戶在使用的時候輸入而已，一次性的操作。

6) 模板管理

模板管理就是管理各種配置文件的管理系統。

配置文件之所以需要管理，是因為兩個原因：

1、在不同的環境中配置文件的內容可能是不同的

2、配置文件中的某些內容可能是會被修改的

我們以下面的配置文件為例，分別說說這兩種情況下使用模板管理的必要性：

[common]region = {{ region.id ｝｝set = 1instance = 1...[network]listen-ip = {{ inventory_hostname ｝｝file_ulimit = {{ global.file_ulimit ｝｝

上面配置文件中的 {{ region.id ｝｝以及{{ inventory_hostname ｝｝說的就是第一種情況， 而{{ global.file_path ｝｝就是第二種情況。

第一種情況中，在不同的region之間，文件的格式不變，但region.id的值是有變化的;inventory_hostname這里表示的是某個服務器的ip地址，這個在服務器級別都是變化的。因此這類文件需要是需要進行模板管理的。

第二種情況中，所有的file_ulimit都是一樣的，那我們為什么不寫死在文件里而把它變成變量呢?是因為這個配置，雖然現在沒有變化，但將來可能會發生變化，在變量管理中直接修改一下，那新的配置文件就都會按照這個生成了，比起去改一個文件內容還有可能產生格式錯誤的風險來說，這種方式是不是簡單多了。

至于模板文件如何編寫，這里將會使用python的最通用的模板引擎jinja2引擎，所有的語法都必須遵循jinja2的引擎即可，變量使用變量管理中定義的變量，對于每一臺主機都是在使用的時候動態生成最新的臨時文件，并通過文件分發的方式傳輸就可以了。

7) 軟件管理

所謂的軟件管理，也就是軟件包的管理，軟件包的管理有兩種：

1、rpm或yum，npm，pip等安裝的軟件包，具有明確的包管理工具。

2、壓縮包或目錄格式的代碼版本。

具有軟件包管理工具的代碼，比較容易進行管理，只要通過每臺服務器自動的Agent定期執行list操作將所需要跟蹤的軟件包的版本進行跟蹤，并匯報到中心管理數據庫即可。

而壓縮包或目錄格式的代碼版本則比較麻煩，需要對比MD5值，以及具有參照樣本才可以管理。

這些所有的軟件包都需要有一個最新可用的全局版本管理，用于進行版本對比操作，甚至可以直接點擊升級。

總之，最終的軟件管理的結果會呈現如下的形態，以某臺服務器為例：

服務器ip： xxx.xxx.xxx.xxx| 軟件包名稱| 版本號 | 是否是最新可用版本| 點擊升級| ：—-|：—-|| nodejs| v0.1.1| 是|| libvirt| x.x.x| 是|| zookeeper| 3.3.5| 否| 升級

當然有了軟件管理之后，當我們有某種類似如： 將某些服務器上面的某個軟件包升級! 這樣的問題的時候，無論是獲取基準ip列表，還是后續的升級工作，都十分簡單了。

當然版本升級工作會和作業管理相結合，每個版本升級都會是一個單獨的作業，這樣版本升級的進度，結果也都一目了然，而且還可以做到灰度。

8)服務管理

服務管理有點類似監控工具，它所層顯的狀態和版本管理類似，實現的方式也類似，都是通過Agent定時上報的機制獲取最新的數據。

所謂的服務管理，就是講每一臺服務器上所運行這些進程進行管理，當然不是全部進程，而是我們所關注的服務進程，呈現的狀態如：

以服務器：xxx.xx.xxx.xxx為例：| 進程id| 進程名稱| 啟動時間| 檢查時間|運行時間 | 運行用戶| 運行狀態| 操作|：—-：| 1234| uhost-action| 2016-2-07 10：00：00| 2016-2-17 10：00：00 | 10day | root|運行中 | 重啟/停止| 2345| uimage3-action| 2016-2-07 10：00：00 |2016-2-17 10：00：00| 8day | root|已停止 | 啟動

上面是某臺服務器上的服務管理的實時情況，每一個任務都可以有詳細的跟蹤記錄，可以用于問題跟蹤，服務報警，dashborad展現等等。

另外服務管理可以和作業管理相結合，實現服務的重啟，停止，啟動等功能。