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

一、問題背景：

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

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

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

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

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

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

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

三、詳細(xì)設(shè)計(jì)：

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

3.1 資源管理

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

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

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

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

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

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

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

3.2 作業(yè)管理

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

下面將分別對上面幾個(gè)子功能進(jìn)行詳細(xì)介紹：

1. 腳本執(zhí)行：

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

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

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

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

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

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

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

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

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

1)本地執(zhí)行模式;本地模式指，該腳本的執(zhí)行并不會到遠(yuǎn)程服務(wù)器去執(zhí)行，而是在管理服務(wù)所在的本地執(zhí)行，這種模式可以用來判斷遠(yuǎn)程服務(wù)器是否啟動等功能，或是某些只能在管理服務(wù)器上執(zhí)行的命令;[!--empirenews.page--]

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

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

1)腳本管理功能;用于管理用戶上傳的腳本和常用的基礎(chǔ)腳本。

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

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

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

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

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

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

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

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

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

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

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

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

2. 文件分發(fā)：

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

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

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

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

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

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

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

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

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

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

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

2)物理機(jī)之間的文件互傳。

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

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

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

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

3. 批量執(zhí)行：

所謂的批量執(zhí)行功能就是上面兩個(gè)基礎(chǔ)功能中在選擇目的服務(wù)器的個(gè)數(shù)的時(shí)候支持多個(gè)服務(wù)器，而不是只能選擇單個(gè)服務(wù)器。[!--empirenews.page--]

在使用SSH方式情況下并發(fā)的速度會較差，可能控制在單機(jī)30-50個(gè)任務(wù)同時(shí)進(jìn)行。

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

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

4. 定制任務(wù)：

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

1) 支持使用基礎(chǔ)功能模塊的子任務(wù)組裝成完成任務(wù)

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

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

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

5. 定時(shí)任務(wù)：

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

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

1)用戶輸入的時(shí)間計(jì)劃通過轉(zhuǎn)換后寫到管理機(jī)的crontab服務(wù)中。

2)每次有定時(shí)任務(wù)產(chǎn)生或刪除或修改后生成新的計(jì)劃任務(wù)。

3)計(jì)劃任務(wù)中寫明具體的執(zhí)行命令

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

6. 灰度計(jì)劃：

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

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

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

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

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

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

2)任務(wù)重做，重做任務(wù)子步驟是否重做控制。

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

4)其他暫時(shí)未想到功能。

3.3 配置管理

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

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

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

1)賬戶管理：

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

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

2) 文件管理：

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

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

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

3)腳本管理：

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

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

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

腳本也支持添加標(biāo)簽，方便記憶和查找。

4)分組管理：

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

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

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

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

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

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

5)變量管理：

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

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

region： id： 7001 name： js mongodb： hosts： - 172.27.117.201 - 172.27.117.202 - 172.27.117.203 port： 27017[!--empirenews.page--]

編寫完成后解析成格式化的數(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è)維度：

■全局變量

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

■組變量

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

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

■全局組(級別最低)

■IDC組(級別次之)

■Set組(級別次之)

■自定義組(級別次之)

■主機(jī)變量

主機(jī)變量是主機(jī)級別的動態(tài)變量，具有較高的優(yōu)先級，建議結(jié)合資源管理系統(tǒng)使用，可以給每一臺物理主機(jī)(虛擬主機(jī))都設(shè)置一組相應(yī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)先級決定生成的配置文件的不同，甚至執(zhí)行腳本的不同。

■任務(wù)變量

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

6) 模板管理

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

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

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

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

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

7) 軟件管理

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

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

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

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

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

這些所有的軟件包都需要有一個(gè)最新可用的全局版本管理，用于進(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ù)器上面的某個(gè)軟件包升級! 這樣的問題的時(shí)候，無論是獲取基準(zhǔn)ip列表，還是后續(xù)的升級工作，都十分簡單了。

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

8)服務(wù)管理

服務(wù)管理有點(diǎn)類似監(jiān)控工具，它所層顯的狀態(tài)和版本管理類似，實(shí)現(xiàn)的方式也類似，都是通過Agent定時(shí)上報(bào)的機(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)程名稱| 啟動時(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|已停止 | 啟動

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

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

服務(wù)管理功能也是很有用的功能。

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

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

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

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

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

總結(jié)：

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

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

關(guān)于作者：

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