一、問題背景：

大部分的應用運維工作隨著服務器數(shù)量和產(chǎn)品數(shù)量的增長而增加，而運維人數(shù)的不足導致單個運維人員所承擔的工作任務較為繁重，同時運維工作的不標準、無自動化使得應用運維任務十分復雜，耗費的大量的人員成本、時間成本和溝通成本。

應用運維工作說白了大體可以分為兩種情況：1． 在某個或某些服務器上執(zhí)行某個腳本或命令；2．將某個或某些文件傳輸?shù)侥硞€或某些特定的服務器的特定位置上。在服務器數(shù)量較少的情況下，可以通過ssh或scp命令實現(xiàn)上面兩個操作；服務器數(shù)量較多的情況下，我們可以通過包裝ssh或者使用批量ssh工具，如pssh，ansible等來解決問題，但這種方式大多數(shù)都是一次性的方式，無論使用方法以及后續(xù)跟蹤來看都并不友好。

還有，由于一系列歷史原因，現(xiàn)網(wǎng)的服務環(huán)境也較為繁雜，現(xiàn)網(wǎng)的服務器上的代碼、配置、軟件包、腳本等文件沒有進行統(tǒng)一的版本管理與配置管理，比如某個產(chǎn)品的代碼版本多種多樣；現(xiàn)網(wǎng)的代碼和文件幾乎都是通過一臺復制到另一臺的方式來實現(xiàn)；由于代碼版本、配置版本等問題導致的現(xiàn)網(wǎng)質(zhì)量事件也并不在少數(shù)。

另外，應用運維也需要一個統(tǒng)一的資源管理系統(tǒng)，對現(xiàn)網(wǎng)的服務的數(shù)據(jù)進行業(yè)務維度的資源管理，系統(tǒng)運維的CMDB系統(tǒng)只在靜態(tài)資源維度進行了管控，動態(tài)的業(yè)務數(shù)據(jù)等資源需要應用運維團隊自行來管理。

因此，針對上面所述的各種問題，需要一個運維管控系統(tǒng)，來解決包括：資源管理、配置管理、任務管理、文件發(fā)布等一些列常用的運維跟蹤，通過簡單高效、自動化的方式將繁瑣的應用運維工作通過管控系統(tǒng)來完成，即可以降低運維的難度，也可以提高運維的效率，同時可以提高運維操作的成功率，并實現(xiàn)運維任務的持續(xù)跟蹤和管理，甚至在不遠的將來可以實現(xiàn)移動運維。

二、功能結(jié)構(gòu)：

經(jīng)過上述的分析和整理，我們將整個管控平臺的功能細化到如下幾個大功能，如圖所示：

三、詳細設計：

這里圍繞上面功能結(jié)構(gòu)圖中的4個大功能，進行詳細的分析和設計，其中移動運維功能為附加功能，這里暫時不介紹。

3．1 資源管理

先說資源管理，資源管理是一切后續(xù)自動化運維功能的前提，也是所有自動化功能的數(shù)據(jù)依賴。

資源管理的功能可以較為薄弱，但是對數(shù)據(jù)的要求比較高，可以基于系統(tǒng)運維的CMDB系統(tǒng)進行二次構(gòu)建，主要的功能可以分為：

1、物理機資源管理：物理機資源管理功能，需要將CMDB中所有交付到應用運維的物理機資源進行重新整理，按照二級業(yè)務產(chǎn)品線進行管理，支持多種服務器狀態(tài)（如部署中，備用池等等）標注?？梢曰谖锢頇C資源管理系統(tǒng)進行服務器初始化管理操作，加快服務初始化部署工作的效率。物理機資源管理對于后續(xù)的配置管理和作業(yè)管理來說是最為重要的，是后續(xù)兩個功能的數(shù)據(jù)基礎。

2、管理虛機資源管理：所有的管理服務都部署在管理虛機上，因此我們也需要對管理虛機進行管理，管理虛機的數(shù)據(jù)和物理機資源管理一樣，可以依賴系統(tǒng)運維的CMDB中的數(shù)據(jù)進行二次管理，功能和物理機資源管理類似，這里不再闡述。

3、虛擬資源管理：虛擬資源管理就是在每一臺物理機上的虛擬機／業(yè)務DB的資源管理，可以基于業(yè)務管理數(shù)據(jù)庫中的數(shù)據(jù)進行二次整合，或者通過數(shù)據(jù)采集上報的方式實現(xiàn)，盡可能的做到虛擬資源數(shù)據(jù)的有效性和狀態(tài)一致性。

虛擬資源數(shù)據(jù)在進行后續(xù)的虛擬資源管理、虛擬資源遷移等功能上會有較大幫助，可以基于虛擬資源管理完成自動化的實例遷移工作，節(jié)省大量的手動實例遷移任務。另外虛擬資源管理對宕機恢復或機房、機架斷電等問題也會有較大的幫助。

整個資源管理比較簡單，可以優(yōu)先完成物理機資源管理功能，再實現(xiàn)虛擬資源管理功能。

3．2 作業(yè)管理

作業(yè)管理是應用運維管控系統(tǒng)的核心功能，也是應用運維工作中最經(jīng)常使用到的功能，作業(yè)管理功能也可以分為如下子功能，如圖所示：

下面將分別對上面幾個子功能進行詳細介紹：

1． 腳本執(zhí)行：

腳本執(zhí)行和文件分發(fā)是整個作業(yè)功能的基礎功能，其他的功能都是通過對著兩個功能進行組裝和裝飾來實現(xiàn)的。

腳本執(zhí)行的表現(xiàn)形式就是運維人員在頁面中提交一個腳本，腳本建議支持shell和python兩種形式，可以通過三種方式：

1）手動書寫；也就是在頁面上的編輯器中編寫腳本；

2）上傳腳本；也就是通過瀏覽器將本地的腳本上傳到系統(tǒng)中；

3）克隆系統(tǒng)腳本；所謂的系統(tǒng)腳本就是運維人員通過上面兩個步驟提交到系統(tǒng)中的腳本，可以分為基礎系統(tǒng)腳本和用戶系統(tǒng)腳本，基礎系統(tǒng)腳本就是那些我們明確可能會多次執(zhí)行的腳本，比如服務器初始化等腳本；用戶系統(tǒng)腳本就是用戶自定義的腳本，可以實現(xiàn)任何功能。

腳本的編寫要依賴一定的語法規(guī)范，我們可以為shell和python語言提供基礎的類包和函數(shù)庫，同時所有的腳本的執(zhí)行結(jié)果都會根據(jù)腳本的exit的 ＄？ 值來判斷，＄？ 值為0，則表示該腳本執(zhí)行成功，若為其他值則表示腳本執(zhí)行失敗。腳本的輸出內(nèi)容會存儲到數(shù)據(jù)庫中用于后續(xù)的問題跟蹤和排查，因此需要運維人員寫腳本的時候注意寫上詳細的日志內(nèi)容。

腳本支持輸入?yún)?shù)。用戶可以在頁面中的參數(shù)一欄輸入執(zhí)行參數(shù)，當然也可以直接寫到腳本里。

支持選擇執(zhí)行賬戶。目前大部分服務的運行賬戶仍然是root用戶，后續(xù)可能會改成非root用戶，所以這里支持選擇執(zhí)行賬戶，具體的賬戶名稱，可以在用戶管理的功能中維護。

支持選擇所執(zhí)行的服務器。用戶在選擇好相應的腳本之后，需要指定在哪些服務器上執(zhí)行該腳本，因此需要支持選擇所需的服務器。這里面服務器選擇分為兩種模式：

1）本地執(zhí)行模式；本地模式指，該腳本的執(zhí)行并不會到遠程服務器去執(zhí)行，而是在管理服務所在的本地執(zhí)行，這種模式可以用來判斷遠程服務器是否啟動等功能，或是某些只能在管理服務器上執(zhí)行的命令；

2）遠程服務器執(zhí)行模式；遠程服務器執(zhí)行模式就是比較常規(guī)的將腳本發(fā)送到遠程服務器上，并在遠程服務器上執(zhí)行的模式，這種模式需要選擇所需要執(zhí)行服務器列表，這里就需要依靠資源管理系統(tǒng)中的物理機管理功能了，可以通過某種方式對服務器進行手動分組或自動分組，然后執(zhí)行的時候可以按照不同的維度（比如按ip選擇，按機房選擇，按業(yè)務選擇，或按自定義組名選擇）選擇所需的服務器組，進而將腳本下發(fā)到這些服務器上執(zhí)行。

總結(jié)一下，腳本執(zhí)行功能比較基礎，同時還包含三個子功能，這三個子功能放到配置管理里面去實現(xiàn)，后面會具體闡述：

1）腳本管理功能；用于管理用戶上傳的腳本和常用的基礎腳本。

2）賬戶管理功能；用于管理具體的執(zhí)行用戶。

3）服務器分組功能；用于基于資源管理系統(tǒng)的物理機管理數(shù)據(jù)按照某種方式劃分成一定的服務器組。

說完具體的功能之后，我們需要確定具體的實現(xiàn)方式，準確的說，實現(xiàn)方式有兩種：

1）SSH遠程執(zhí)行；可以通過封裝ssh和paramiko的方式實現(xiàn)，python中的ansible和fabric包也都支持遠程SSH執(zhí)行的功能。Shell就用ssh命令即可。

該方式對中心節(jié)點要求比較高，每一個遠程執(zhí)行命令都會在中心節(jié)點啟動一個進程（線程）來執(zhí)行，對中心機的壓力較大，同時由于是基于SSH的原理，故命令執(zhí)行的效率較差，命令執(zhí)行時間長。

2）Agent執(zhí)行；在每臺服務器上部署一個Agent，用戶執(zhí)行管控系統(tǒng)發(fā)送的腳本。這種方式的優(yōu)點是可以采用拉的方式，由各個子節(jié)點訂閱分給自己的任務，執(zhí)行完成后再講結(jié)果推給中心節(jié)點的數(shù)據(jù)；當然也可以像SSH方式通過推的方式由中心節(jié)點將任務發(fā)給遠程的Agent，然后Agent去執(zhí)行，并將結(jié)果反饋給中心節(jié)點。這種方式的執(zhí)行效率會比較高，可擴展性強，將來甚至可以通過該Agent進行配置或運行數(shù)據(jù)上報，對于配置管理也比較方便，缺點是需要開發(fā)Agent，Agent需要支持異步非阻塞模式，且需要維護每臺服務器的Agent，包括部署和管理。

Python的saltstack軟件就是通過Agent的方式實現(xiàn)的，需要在每臺物理機上部署一個saltstack minion進程用于接受任務和執(zhí)行任務，在每個中心機上部署saltstack master進程用于下發(fā)任務，saltstack master通過將任務下發(fā)到zeromq中從而實現(xiàn)各個minion獲取任務并執(zhí)行，同時saltstack也支持將任務執(zhí)行結(jié)果存儲到Redis等數(shù)據(jù)庫中，便于后續(xù)的跟蹤和查看。

不過Agent也可以通過自行開發(fā)的方式實現(xiàn)，線上所有的Agent大多都是這種原理，也都是自己實現(xiàn)的，不過具有一定的開發(fā)難度。

因此對于腳本執(zhí)行的實現(xiàn)方式來看總結(jié)如下：

1）如果用SSH的方式，使用python的ansible api或fabric。

2）如果用Agent的方式，可以考慮使用Python的saltstack minion Agent。

3）如果用自研Agent的方式，可以使用golang。上面兩種方式相對快速容易實現(xiàn)，這種方式會有一點的時間消耗，不過可以積累一定的開發(fā)經(jīng)驗。

2． 文件分發(fā)：

文件分發(fā)是除了腳本執(zhí)行的另一個基礎功能，該功能的技術描述就是將某臺服務器上的某個或某些文件，傳輸?shù)狡渌哪硞€或某些服務器的某個位置上。

文件分發(fā)功能分為以下兩個子功能，相關文件和模板的管理工作放到配置管理中去實現(xiàn)，這里只介紹如何實現(xiàn)文件分發(fā)：

1）普通文件分發(fā)，如代碼包，鏡像文件，軟件包等。

2）模板文件分發(fā)，如配置文件等。

模板文件分發(fā)與普通文件分發(fā)不同的區(qū)別是模板文件中存儲變量替換的邏輯，這里普通文件的管理和模板文件的管理以及配置變量的管理都放到配置管理系統(tǒng)中去實現(xiàn)，用戶選擇文件下發(fā)的時候可以選擇是普通文件還是模板文件，如果是模板文件就會自動去加載配置管理中的變量管理生成臨時的普通文件并下發(fā)。

具體的下發(fā)方式也分為兩種：

1）管理機文件下發(fā)到普通的業(yè)務物理機上。

其實大部分的文件分發(fā)場景應該都是這一種，也就是我們將基礎文件或模板文件放到管理機上，作為我們的基準文件，比如我們的部署代碼，軟件包等等，我們只要保證管理機上的文件版本的一致性，就可以保證普通的業(yè)務物理機上面的文件和管理機上的文件一致，也就是配置管理功能的中的文件版本一致性管理。

這種模式下的文件可能相對容量較小，比如小文件（幾k），軟件包（幾M），或者稍大文件（幾G），文件從管理機下發(fā)到某些業(yè)務物理機上面臨的問題是并發(fā)導致的傳輸速度問題，小文件情況下還可以忽略，基本可以在秒級完成，但稍大文件的傳輸就會有時間問題，隨著業(yè)務物理機的個數(shù)增加而增加，因此這種情況會有并發(fā)和流量的控制。

另外文件的傳輸會提前進行文件md5的對比判斷，如果文件的md5值相同，那就沒有再傳輸文件的必要，在稍大文件情況下可以節(jié)省較多的時間。

文件傳輸，可以使用ansible的copy模塊，或者salt的文件file模塊，當然也可以自研方式中封裝rsync的方式，rsync支持文件md5值校驗以及斷點續(xù)傳等方式。

2）物理機之間的文件互傳。

物理機之間的文件互傳準確的來說是反配置管理邏輯的，這種方式就和我們現(xiàn)在的文件傳輸方式很類似，也就是從一臺服務器scp文件到另一臺服務器上。對于配置文件和小文件、軟件包等需要配置管理的文件來說，我們需要明確禁止使用這種方式。但這種方式的好處就是可以用來P2P的傳輸較大的文件，比如幾百G的鏡像文件。

對于幾百G的鏡像文件來說，如果使用第一種管理機管理的方式，只能1對多的傳輸將會造成傳輸時間的極大占用，而使用這種P2P的方式，即可以極大的提升文件傳輸?shù)乃俣取?/p>

物理機之間的文件互傳使用rsync即可，由于文件較大，且可能出現(xiàn)斷點，rsync是比較方便的解決大文件傳輸?shù)姆椒?，需要在每臺服務器上的Agent上對rsync功能進行封裝，支持Agent之間的rsync文件互傳。

物理機文件中需要管理的文件列表，可以通過Agent匯報到配置管理系統(tǒng)中，用戶選擇文件分發(fā)的時候，可以選擇配置管理系統(tǒng)中的點對點大文件傳輸功能，配置管理系統(tǒng)中可以自動選擇傳輸源，針對被傳輸物理機的個數(shù)，實現(xiàn)真正的點對點傳輸，不需要用戶自己去選擇源文件服務器，可以節(jié)省大量的人為運維操作。

3． 批量執(zhí)行：

所謂的批量執(zhí)行功能就是上面兩個基礎功能中在選擇目的服務器的個數(shù)的時候支持多個服務器，而不是只能選擇單個服務器。

在使用SSH方式情況下并發(fā)的速度會較差，可能控制在單機30－50個任務同時進行。

在使用Agent的方式情況下，任務本身是異步下發(fā)的，可以實現(xiàn)同時1000＋任務同時進行。

由于服務器數(shù)量較多，且分機房的模式，整個后端架構(gòu)會是與目前的UCloud后端架構(gòu)類似的分布式架構(gòu)，一個中心任務下發(fā)節(jié)點，每個機房一個任務中轉(zhuǎn)節(jié)點，每臺服務器一個Agent（或者中轉(zhuǎn)節(jié)點SSH的方式）。

4． 定制任務：

所謂的定制任務，就是可以通過任務組裝的方式，將腳本執(zhí)行和文件分發(fā)這兩個主要功能（可以根據(jù)需要添加其他的功能，比如重啟后的服務器ping探測，端口探測等），將上面的這些功能，按照1、2、3、4、5的方式組裝，具體的支持功能如下：

1） 支持使用基礎功能模塊的子任務組裝成完成任務

2） 支持設置每個子任務的子步驟的執(zhí)行控制。比如失敗后停止，完成后停止等待確認，忽略失敗等功能。

3） 支持每個子任務的執(zhí)行服務器ip修改。

定制任務適用于某些使用頻次較高的任務，比如服務器初始化上線，代碼版本發(fā)布，軟件包更新等操作。

5． 定時任務：

定時任務是對普通的基礎任務以及定制任務實現(xiàn)定時執(zhí)行的功能，該功能的實現(xiàn)也相對簡單，即按照crontab的分時日月周的語法，支持周期性或者定時性，也可以按照手機創(chuàng)建鬧鈴的方式選擇觸發(fā)時間和觸發(fā)頻率。

具體的實現(xiàn)方式如下：

1）用戶輸入的時間計劃通過轉(zhuǎn)換后寫到管理機的crontab服務中。

2）每次有定時任務產(chǎn)生或刪除或修改后生成新的計劃任務。

3）計劃任務中寫明具體的執(zhí)行命令

4）通過腳本調(diào)度API的方式實現(xiàn)任務的定時執(zhí)行。

6． 灰度計劃：

對于非周期性重復執(zhí)行的任務，都可以加入灰度計劃功能，該功能又結(jié)合定時任務實現(xiàn)。

灰度計劃可以有兩個維度體現(xiàn)：

1）定制任務中的每個子任務的子步驟都可以實現(xiàn)灰度，即上面所說的完成后暫停，或失敗后暫停。

2）物理機個數(shù)維度，并發(fā)執(zhí)行的時候支持自定義灰度計劃，比如：任務先執(zhí)行1臺服務器，成功后隔多久后可以執(zhí)行第二批服務器，再間隔一段時間再執(zhí)行第三批任務。同時可以設置任務失敗條件，比如：任何一臺服務器失敗，則整個任務失??；或當失敗服務器的數(shù)量達到灰度計劃服務器數(shù)量的百分比后整個任務放棄執(zhí)行。

上面這些是作業(yè)管理系統(tǒng)的主要功能，當然想要實現(xiàn)整個作業(yè)管理系統(tǒng)還會有一些其他的子功能，比如：

1）任務結(jié)果記錄跟蹤系統(tǒng)。

2）任務重做，重做任務子步驟是否重做控制。

3）腳本內(nèi)容安全審核功能。

4）其他暫時未想到功能。

3．3 配置管理

配置管理功能是整個管控功能中十分重要的一環(huán)，上面的作業(yè)管理系統(tǒng)中很多功能都依賴配置管理系統(tǒng)才能實現(xiàn)。

配置管理整個功能經(jīng)過梳理之后如下圖所示：

下面將依次介紹上面所述的功能：

1）賬戶管理：

所謂的賬戶管理十分簡單，就是服務運行的時候所使用的用戶，目前線上的服務大多都是root用戶，但是有改成業(yè)務用戶的趨勢，故需要有一個賬戶管理功能。運維人員在使用作業(yè)管理的時候，選擇相應的用戶進行任務執(zhí)行。

該功能可以發(fā)展成用戶權(quán)限管理系統(tǒng)，即在該系統(tǒng)中控制每一個用戶的系統(tǒng)權(quán)限。生成相應的權(quán)限配置文件，并下發(fā)到所有服務器上。不過用戶管理的功能可能系統(tǒng)運維已經(jīng)管理，這里就不再敘述了。

2） 文件管理：

文件管理功能比較基礎，其實主要是對管理機上的重要文件進行管理，比如代碼版本，腳本文件，軟件包文件等等，文件類型包括：普通文件，文件夾，壓縮文件和模板文件。

文件管理中，用戶按照一定的規(guī)范將所需要的文件放到管理機上的指定位置，并將相應的路徑配置在數(shù)據(jù)庫中。

文件管理主要用在作業(yè)管理中進行文件分發(fā)的基礎文件依賴。

3）腳本管理：

腳本管理也是文件管理中的一種，但需要單獨管理，腳本是作業(yè)管理系統(tǒng)的基礎依賴。腳本分為基礎系統(tǒng)腳本和用戶自定義腳本兩種。

所謂的基礎系統(tǒng)腳本就是經(jīng)過嚴格認證過的，可以重復多次使用的基礎功能腳本。而用戶自定義腳本指用戶通過上傳或是通過web 編輯器提交的腳本文件，存儲下來用戶后續(xù)可能的重復使用。

基礎系統(tǒng)腳本和用戶自定義腳本都會存儲在管理機的固定位置上，在文件管理中進行管理，用戶在使用的時候選擇對應的腳本名稱即可。

腳本也支持添加標簽，方便記憶和查找。

4）分組管理：

分組管理也是基礎功能之一，在作業(yè)系統(tǒng)中腳本執(zhí)行和文件分發(fā)都需要有明確的服務器ip地址，而分組管理就是將這些ip地址按照特定的用戶自定義的方式來命名和分類，支持添加標簽，用戶在選擇服務器的時候可以通過搜索的方式選擇到一組服務器中的一個或幾個。

分組管理依賴于資源管理系統(tǒng)，以資源管理系統(tǒng)的物理機資源（管理服務是虛擬機資源）為依據(jù)，用戶選擇一部分服務器并進行命名或添加標簽從而得到一個新的分組。

分組可以分為靜態(tài)分組和動態(tài)分組兩種。

所謂的靜態(tài)分組指的是確定完分組后，如需變化必須手動添加或修改的分組。這類分組會占很大一部分。

而動態(tài)分組指的是可以通過對服務器資源的某種匹配而自動將其添加到某個分組中的功能，比如說某個機房新上線N臺服務器，可以不需要手動，而自動的添加到某個組中。這種功能可以通過手動來實現(xiàn)，在技術和時間限制的情況下，可以暫時不考慮。

分組功能還有組優(yōu)先級的概念，主要是結(jié)合變量管理、模板管理結(jié)合使用，這些在變量管理和模板管理里面再進行介紹。

5）變量管理：

變量管理主要是配合分組管理和模板管理使用，所謂的模板就是在不同的情況層顯不同內(nèi)容的文件，而如何呈現(xiàn)不同內(nèi)容就是在模板中配置了相關的變量名稱，而變量的具體賦值則需要在變量管理里面體現(xiàn)。

變量管理建議使用yml語法格式來編寫，比如如下的格式：

region： id： 7001 name： js mongodb： hosts： － 172．27．117．201 － 172．27．117．202 － 172．27．117．203 port： 27017

編寫完成后解析成格式化的數(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)境就需要有變量管理這個功能來控制。

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

■全局變量

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

■組變量

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

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

■全局組（級別最低）

■IDC組（級別次之）

■Set組（級別次之）

■自定義組（級別次之）

■主機變量

主機變量是主機級別的動態(tài)變量，具有較高的優(yōu)先級，建議結(jié)合資源管理系統(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值，以及具有參照樣本才可以管理。

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

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

服務器ip： xxx．xxx．xxx．xxx｜ 軟件包名稱｜ 版本號 ｜ 是否是最新可用版本｜ 點擊升級｜ ：—－｜：—－｜｜ nodejs｜ v0．1．1｜ 是｜｜ libvirt｜ x．x．x｜ 是｜｜ zookeeper｜ 3．3．5｜ 否｜ 升級

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

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

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è)管理相結(jié)合，實現(xiàn)服務的重啟，停止，啟動等功能。

服務管理功能也是很有用的功能。

到此位置，整個配置管理工具的功能介紹也完成了，具體的實現(xiàn)方式可以有兩種實現(xiàn)方式：

1、基于過程的實現(xiàn)方式（主動）

基于過程的實現(xiàn)方式，就是所說的的配置變化，通過中心觸發(fā)的方式實現(xiàn)，服務器上所有的配置變化都是主動的而不是被動的，可以通過SSH的方式，也可以通過Agent的方式來實現(xiàn)?？梢允褂肁nsible、fabirc的API或者salt的daemon，也可以自研daemon的方式實現(xiàn)。

2、基于結(jié)果的實現(xiàn)方式（被動）

基于結(jié)果的實現(xiàn)方式是指整個操作并不關心過程，也不是主動觸發(fā)的，而是被動觸發(fā)的，這種方式是基于Agent的實現(xiàn)方式。 運維人員對某臺服務器的某個配置設置一個最終的狀態(tài)，Agent獲取這個最終狀態(tài)后執(zhí)行相應的操作，只要Agent滿足條件需求，那么這臺服務器最終所呈現(xiàn)的結(jié)果就是我們配置的結(jié)果，Puppet就是這種理念設計的，當然也可以自研。

總結(jié)：

整個運維管控系統(tǒng)還是比較大的系統(tǒng)，每一個子系統(tǒng)的功能的很復雜，而且還需要結(jié)合使用，整體的架構(gòu)是分布式的，多種開源軟件與自研系統(tǒng)結(jié)合的方式實現(xiàn)，大體功能和架構(gòu)如上面所述，具體的實現(xiàn)上肯定會有很多細節(jié)需要攻克的。

PS： 這個功能和架構(gòu)設計參考了騰訊的藍鯨系統(tǒng)，并結(jié)合了Ansible、saltstack和puppet的理念，綜合而成，而且其中的部分功能已經(jīng)實現(xiàn)完成。

關于作者：

趙新宇，UCloud平臺架構(gòu)部，資深專家工程師，DevOps架構(gòu)師。曾任新浪微博高級數(shù)據(jù)庫工程師，唯品會資深數(shù)據(jù)庫工程師。從事數(shù)據(jù)庫、運維、自動化開發(fā)、中間層開發(fā)、系統(tǒng)架構(gòu)設計等工作。