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

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

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

■全局變量

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

■組變量

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

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

■全局組(級別最低)

■IDC組(級別次之)

■Set組(級別次之)

■自定義組(級別次之)

■主機變量

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

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

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

■任務變量

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

6) 模板管理

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

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

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

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

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

7) 軟件管理

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

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

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

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

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

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

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

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

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

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

8)服務管理

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

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

以服務器：xxx.xx.xxx.xxx為例：| 進程id| 進程名稱| 啟動時間| 檢查時間|運行時間 | 運行用戶| 運行狀態(tài)| 操作|：—-：| 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展現(xiàn)等等。

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