一個(gè)通用應(yīng)用運(yùn)維管控平臺(tái)的設(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

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

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

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

■全局變量

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

■組變量

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

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

■全局組(級(jí)別最低)

■IDC組(級(jí)別次之)

■Set組(級(jí)別次之)

■自定義組(級(jí)別次之)

■主機(jī)變量

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

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ù)部署的時(shí)候可以根據(jù)相應(yīng)的優(yōu)先級(jí)決定生成的配置文件的不同，甚至執(zhí)行腳本的不同。

■任務(wù)變量

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

6) 模板管理

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

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

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

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

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

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

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

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

7) 軟件管理

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

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

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

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

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

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

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

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

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

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

8)服務(wù)管理

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

所謂的服務(wù)管理，就是講每一臺(tái)服務(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)程名稱| 啟動(dòng)時(shí)間| 檢查時(shí)間|運(yùn)行時(shí)間 | 運(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|已停止 | 啟動(dòng)

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

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