一個(gè)通用應(yīng)用運(yùn)維管控平臺(tái)的設(shè)計(jì)實(shí)現(xiàn)
2)遠(yuǎn)程服務(wù)器執(zhí)行模式;遠(yuǎn)程服務(wù)器執(zhí)行模式就是比較常規(guī)的將腳本發(fā)送到遠(yuǎn)程服務(wù)器上,并在遠(yuǎn)程服務(wù)器上執(zhí)行的模式,這種模式需要選擇所需要執(zhí)行服務(wù)器列表,這里就需要依靠資源管理系統(tǒng)中的物理機(jī)管理功能了,可以通過某種方式對(duì)服務(wù)器進(jìn)行手動(dòng)分組或自動(dòng)分組,然后執(zhí)行的時(shí)候可以按照不同的維度(比如按ip選擇,按機(jī)房選擇,按業(yè)務(wù)選擇,或按自定義組名選擇)選擇所需的服務(wù)器組,進(jìn)而將腳本下發(fā)到這些服務(wù)器上執(zhí)行。
本文引用地址:http://m.butianyuan.cn/article/201807/383696.htm總結(jié)一下,腳本執(zhí)行功能比較基礎(chǔ),同時(shí)還包含三個(gè)子功能,這三個(gè)子功能放到配置管理里面去實(shí)現(xiàn),后面會(huì)具體闡述:
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命令即可。
該方式對(duì)中心節(jié)點(diǎn)要求比較高,每一個(gè)遠(yuǎn)程執(zhí)行命令都會(huì)在中心節(jié)點(diǎn)啟動(dòng)一個(gè)進(jìn)程(線程)來執(zhí)行,對(duì)中心機(jī)的壓力較大,同時(shí)由于是基于SSH的原理,故命令執(zhí)行的效率較差,命令執(zhí)行時(shí)間長。
2)Agent執(zhí)行;在每臺(tái)服務(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í)行效率會(huì)比較高,可擴(kuò)展性強(qiáng),將來甚至可以通過該Agent進(jìn)行配置或運(yùn)行數(shù)據(jù)上報(bào),對(duì)于配置管理也比較方便,缺點(diǎn)是需要開發(fā)Agent,Agent需要支持異步非阻塞模式,且需要維護(hù)每臺(tái)服務(wù)器的Agent,包括部署和管理。
Python的saltstack軟件就是通過Agent的方式實(shí)現(xiàn)的,需要在每臺(tái)物理機(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é)果存儲(chǔ)到Redis等數(shù)據(jù)庫中,便于后續(xù)的跟蹤和查看。
不過Agent也可以通過自行開發(fā)的方式實(shí)現(xiàn),線上所有的Agent大多都是這種原理,也都是自己實(shí)現(xiàn)的,不過具有一定的開發(fā)難度。
因此對(duì)于腳本執(zhí)行的實(shí)現(xiàn)方式來看總結(jié)如下:
1)如果用SSH的方式,使用python的ansible api或fabric。
2)如果用Agent的方式,可以考慮使用Python的saltstack minion Agent。
3)如果用自研Agent的方式,可以使用golang。上面兩種方式相對(duì)快速容易實(shí)現(xiàn),這種方式會(huì)有一點(diǎn)的時(shí)間消耗,不過可以積累一定的開發(fā)經(jīng)驗(yàn)。
2. 文件分發(fā):
文件分發(fā)是除了腳本執(zhí)行的另一個(gè)基礎(chǔ)功能,該功能的技術(shù)描述就是將某臺(tái)服務(wù)器上的某個(gè)或某些文件,傳輸?shù)狡渌哪硞€(gè)或某些服務(wù)器的某個(gè)位置上。
文件分發(fā)功能分為以下兩個(gè)子功能,相關(guān)文件和模板的管理工作放到配置管理中去實(shí)現(xiàn),這里只介紹如何實(shí)現(xiàn)文件分發(fā):
1)普通文件分發(fā),如代碼包,鏡像文件,軟件包等。
2)模板文件分發(fā),如配置文件等。
模板文件分發(fā)與普通文件分發(fā)不同的區(qū)別是模板文件中存儲(chǔ)變量替換的邏輯,這里普通文件的管理和模板文件的管理以及配置變量的管理都放到配置管理系統(tǒng)中去實(shí)現(xiàn),用戶選擇文件下發(fā)的時(shí)候可以選擇是普通文件還是模板文件,如果是模板文件就會(huì)自動(dòng)去加載配置管理中的變量管理生成臨時(shí)的普通文件并下發(fā)。
具體的下發(fā)方式也分為兩種:
1)管理機(jī)文件下發(fā)到普通的業(yè)務(wù)物理機(jī)上。
其實(shí)大部分的文件分發(fā)場(chǎng)景應(yīng)該都是這一種,也就是我們將基礎(chǔ)文件或模板文件放到管理機(jī)上,作為我們的基準(zhǔn)文件,比如我們的部署代碼,軟件包等等,我們只要保證管理機(jī)上的文件版本的一致性,就可以保證普通的業(yè)務(wù)物理機(jī)上面的文件和管理機(jī)上的文件一致,也就是配置管理功能的中的文件版本一致性管理。
這種模式下的文件可能相對(duì)容量較小,比如小文件(幾k),軟件包(幾M),或者稍大文件(幾G),文件從管理機(jī)下發(fā)到某些業(yè)務(wù)物理機(jī)上面臨的問題是并發(fā)導(dǎo)致的傳輸速度問題,小文件情況下還可以忽略,基本可以在秒級(jí)完成,但稍大文件的傳輸就會(huì)有時(shí)間問題,隨著業(yè)務(wù)物理機(jī)的個(gè)數(shù)增加而增加,因此這種情況會(huì)有并發(fā)和流量的控制。
另外文件的傳輸會(huì)提前進(jìn)行文件md5的對(duì)比判斷,如果文件的md5值相同,那就沒有再傳輸文件的必要,在稍大文件情況下可以節(jié)省較多的時(shí)間。
文件傳輸,可以使用ansible的copy模塊,或者salt的文件file模塊,當(dāng)然也可以自研方式中封裝rsync的方式,rsync支持文件md5值校驗(yàn)以及斷點(diǎn)續(xù)傳等方式。
2)物理機(jī)之間的文件互傳。
物理機(jī)之間的文件互傳準(zhǔn)確的來說是反配置管理邏輯的,這種方式就和我們現(xiàn)在的文件傳輸方式很類似,也就是從一臺(tái)服務(wù)器scp文件到另一臺(tái)服務(wù)器上。對(duì)于配置文件和小文件、軟件包等需要配置管理的文件來說,我們需要明確禁止使用這種方式。但這種方式的好處就是可以用來P2P的傳輸較大的文件,比如幾百G的鏡像文件。
對(duì)于幾百G的鏡像文件來說,如果使用第一種管理機(jī)管理的方式,只能1對(duì)多的傳輸將會(huì)造成傳輸時(shí)間的極大占用,而使用這種P2P的方式,即可以極大的提升文件傳輸?shù)乃俣取?/p>
物理機(jī)之間的文件互傳使用rsync即可,由于文件較大,且可能出現(xiàn)斷點(diǎn),rsync是比較方便的解決大文件傳輸?shù)姆椒?,需要在每臺(tái)服務(wù)器上的Agent上對(duì)rsync功能進(jìn)行封裝,支持Agent之間的rsync文件互傳。
物理機(jī)文件中需要管理的文件列表,可以通過Agent匯報(bào)到配置管理系統(tǒng)中,用戶選擇文件分發(fā)的時(shí)候,可以選擇配置管理系統(tǒng)中的點(diǎn)對(duì)點(diǎn)大文件傳輸功能,配置管理系統(tǒng)中可以自動(dòng)選擇傳輸源,針對(duì)被傳輸物理機(jī)的個(gè)數(shù),實(shí)現(xiàn)真正的點(diǎn)對(duì)點(diǎn)傳輸,不需要用戶自己去選擇源文件服務(wù)器,可以節(jié)省大量的人為運(yùn)維操作。
3. 批量執(zhí)行:
所謂的批量執(zhí)行功能就是上面兩個(gè)基礎(chǔ)功能中在選擇目的服務(wù)器的個(gè)數(shù)的時(shí)候支持多個(gè)服務(wù)器,而不是只能選擇單個(gè)服務(wù)器。
評(píng)論