一個通用應(yīng)用運(yùn)維管控平臺的設(shè)計(jì)實(shí)現(xiàn)

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

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的服務(wù)器列表，則需要這種方式來使用：region.mongodb.hosts ， 如果需要進(jìn)一步處理該數(shù)據(jù)，可以在模板文件中直接使用Python語法處理，這個在模板管理中再介紹。

之所以需要有變量管理，就是因?yàn)槟０骞芾淼拇嬖?，很多配置需要按照不同的環(huán)境生成，而這些環(huán)境就需要有變量管理這個功能來控制。

變量管理細(xì)分可以分為幾個維度：

■全局變量

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

■組變量

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

建議將組的優(yōu)先級分為如下幾類：

■全局組(級別最低)

■IDC組(級別次之)

■Set組(級別次之)

■自定義組(級別次之)

■主機(jī)變量

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

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

在服務(wù)部署的時候可以根據(jù)相應(yīng)的優(yōu)先級決定生成的配置文件的不同，甚至執(zhí)行腳本的不同。

■任務(wù)變量

任務(wù)變量是具有最高優(yōu)先級的變量，這個變量只有任務(wù)執(zhí)行的時候，通過輸入的參數(shù)來控制，該變量實(shí)際并不進(jìn)行管理，使用用戶在使用的時候輸入而已，一次性的操作。

6) 模板管理

模板管理就是管理各種配置文件的管理系統(tǒng)。

配置文件之所以需要管理，是因?yàn)閮蓚€原因：

1、在不同的環(huán)境中配置文件的內(nèi)容可能是不同的

2、配置文件中的某些內(nèi)容可能是會被修改的

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

[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這里表示的是某個服務(wù)器的ip地址，這個在服務(wù)器級別都是變化的。因此這類文件需要是需要進(jìn)行模板管理的。

第二種情況中，所有的file_ulimit都是一樣的，那我們?yōu)槭裁床粚懰涝谖募锒阉兂勺兞磕?是因?yàn)檫@個配置，雖然現(xiàn)在沒有變化，但將來可能會發(fā)生變化，在變量管理中直接修改一下，那新的配置文件就都會按照這個生成了，比起去改一個文件內(nèi)容還有可能產(chǎn)生格式錯誤的風(fēng)險來說，這種方式是不是簡單多了。

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

7) 軟件管理

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

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

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

具有軟件包管理工具的代碼，比較容易進(jìn)行管理，只要通過每臺服務(wù)器自動的Agent定期執(zhí)行l(wèi)ist操作將所需要跟蹤的軟件包的版本進(jìn)行跟蹤，并匯報到中心管理數(shù)據(jù)庫即可。

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

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

總之，最終的軟件管理的結(jié)果會呈現(xiàn)如下的形態(tài)，以某臺服務(wù)器為例：

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

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

當(dāng)然版本升級工作會和作業(yè)管理相結(jié)合，每個版本升級都會是一個單獨(dú)的作業(yè)，這樣版本升級的進(jìn)度，結(jié)果也都一目了然，而且還可以做到灰度。

8)服務(wù)管理

服務(wù)管理有點(diǎn)類似監(jiān)控工具，它所層顯的狀態(tài)和版本管理類似，實(shí)現(xiàn)的方式也類似，都是通過Agent定時上報的機(jī)制獲取最新的數(shù)據(jù)。

所謂的服務(wù)管理，就是講每一臺服務(wù)器上所運(yùn)行這些進(jìn)程進(jìn)行管理，當(dāng)然不是全部進(jìn)程，而是我們所關(guān)注的服務(wù)進(jìn)程，呈現(xiàn)的狀態(tài)如：

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

上面是某臺服務(wù)器上的服務(wù)管理的實(shí)時情況，每一個任務(wù)都可以有詳細(xì)的跟蹤記錄，可以用于問題跟蹤，服務(wù)報警，dashborad展現(xiàn)等等。

另外服務(wù)管理可以和作業(yè)管理相結(jié)合，實(shí)現(xiàn)服務(wù)的重啟，停止，啟動等功能。