大數(shù)據(jù)時(shí)代高伸縮性、容錯(cuò)性的特點(diǎn)給運(yùn)維提出了更高的要求。系統(tǒng)管理不再是疲于安裝操作系統(tǒng)、對(duì)系統(tǒng)參數(shù)進(jìn)行逐一配置與優(yōu)化、打補(bǔ)丁、安裝軟件、配置軟件、添加某個(gè)服務(wù)的時(shí)代。為了提高效率、避免重復(fù)勞動(dòng)、減少錯(cuò)誤、積累知識(shí)，系統(tǒng)管理員都已開始做一些局部的自動(dòng)化工作。但這些還遠(yuǎn)不夠， 為了滿足運(yùn)維需求，需要更徹底地應(yīng)用自動(dòng)化運(yùn)維工具。

本文將介紹如何利用配置管理自動(dòng)化工具Puppet完成系統(tǒng)安裝、監(jiān)控報(bào)警工作，解剖Puppet給系統(tǒng)管理員帶來(lái)的便利，同時(shí)還將介紹Puppet的架構(gòu)和工作原理。

從系統(tǒng)安裝到自動(dòng)化部署軟件、配置、回滾，再到服務(wù)器的可用性、性能、安全維護(hù)，運(yùn)維管理人員都需要完全掌握，為了有效完成工作，熟悉幾款優(yōu)秀的開源軟件必不可少。如表1所示。

表1 常用運(yùn)維工具分類

對(duì)于我來(lái)說(shuō)，工具箱中最趁手的要數(shù)Kickstart、Puppet、Zabbix和Cacti。

運(yùn)維工作難點(diǎn)

運(yùn)維工作流程

常見的運(yùn)維工作流程包括：安裝系統(tǒng)→優(yōu)化系統(tǒng)與配置→安裝軟件→配置軟件→添加監(jiān)控→檢查。后續(xù)可能還會(huì)有添加服務(wù)→配置變更→打補(bǔ)丁修復(fù)漏洞等。是不是覺得很繁瑣？尤其當(dāng)你負(fù)責(zé)大量設(shè)備，無(wú)法憑借一己之力完成時(shí)，便需要一些工具來(lái)幫忙。

運(yùn)維工作面臨的各種不確定性更讓人頭疼。在10臺(tái)機(jī)器上變更應(yīng)用還是很簡(jiǎn)單的事，但如果上升到千臺(tái)、萬(wàn)臺(tái)就會(huì)變得非常復(fù)雜。重復(fù)性的勞動(dòng)還會(huì)讓人覺得疲憊和乏味，久而久之可能還會(huì)產(chǎn)生厭倦工作的情緒。使用Puppet則能將這些問(wèn)題迎刃而解。

自己實(shí)現(xiàn)自動(dòng)化

為了提升工作效率，減少出錯(cuò)機(jī)率。很多公司都在逐步采用自動(dòng)化來(lái)實(shí)現(xiàn)上述工作。有的公司選擇自己開發(fā)一套工具，因?yàn)榭梢园凑招枨笕我舛ㄖ疲@真的有必要嗎？我們來(lái)看看這樣做的缺點(diǎn)。

1. 從頭造輪子：構(gòu)建腳本工作的挑戰(zhàn)與繁瑣。

2. 程序的可維護(hù)性無(wú)法保障（語(yǔ)言）。

3. 支撐不同的平臺(tái)。

4. 系統(tǒng)重裝后的考慮。

統(tǒng)籌與規(guī)劃整個(gè)系統(tǒng)需要花費(fèi)很長(zhǎng)時(shí)間，伴隨著人員的流動(dòng)，技能水平不一，還會(huì)帶來(lái)新的問(wèn)題。而且單獨(dú)開發(fā)的系統(tǒng)不可能只是支撐一個(gè)平臺(tái)——跨平臺(tái)開發(fā)則意味著更多不確定性。

自動(dòng)化配置工具比較

表2比較了兩種最常用的自動(dòng)化運(yùn)維工具Puppet和Cfengine。

表2 Puppet和Cfengine功能對(duì)比

但我真正想說(shuō)的是：以上比較沒有太多的意義，工具在于你怎么去用，如何用得***，發(fā)揮出它的優(yōu)勢(shì)，與你的業(yè)務(wù)***結(jié)合。我們不需要忙著選工具，而是應(yīng)該深入研究它。#p#

剖析Puppet

在使用任何軟件前我們都需要了解其工作原理，否則會(huì)給后續(xù)使用帶來(lái)諸多不便。Puppet采用了非常簡(jiǎn)單的C/S架構(gòu)，所有數(shù)據(jù)的交互都通過(guò)SSL進(jìn)行，以保證安全。它的工作流程如圖1所示。

圖1 Puppet工作流程

1. 客戶端Puppetd向Master發(fā)起認(rèn)證請(qǐng)求，或使用帶簽名的證書。

2. Master告訴Client你是合法的。

3. 客戶端Puppetd調(diào)用Facter，F(xiàn)acter探測(cè)出主機(jī)的一些變量，例如主機(jī)名、內(nèi)存大小、IP地址等。Puppetd將這些信息通過(guò)SSL連接發(fā)送到服務(wù)器端。

4. 服務(wù)器端的Puppet Master檢測(cè)客戶端的主機(jī)名，然后找到manifest對(duì)應(yīng)的node配置，并對(duì)該部分內(nèi)容進(jìn)行解析。Facter送過(guò)來(lái)的信息可以作為變量處 理，node牽涉到的代碼才解析，其他沒牽涉的代碼不解析。解析分為幾個(gè)階段，首先是語(yǔ)法檢查，如果語(yǔ)法錯(cuò)誤就報(bào)錯(cuò)；如果語(yǔ)法沒錯(cuò)，就繼續(xù)解析，解析的結(jié) 果生成一個(gè)中間的“偽代碼”（catelog），然后把偽代碼發(fā)給客戶端。

5. 客戶端接收到“偽代碼”，并且執(zhí)行。

6. 客戶端在執(zhí)行時(shí)判斷有沒有File文件，如果有，則向fileserver發(fā)起請(qǐng)求。

7. 客戶端判斷有沒有配置Report，如果已配置，則把執(zhí)行結(jié)果發(fā)送給服務(wù)器。

8. 服務(wù)器端把客戶端的執(zhí)行結(jié)果寫入日志，并發(fā)送給報(bào)告系統(tǒng)。

當(dāng)服務(wù)器超過(guò)千臺(tái)

當(dāng)你的服務(wù)器越來(lái)越多時(shí)，你可能會(huì)發(fā)現(xiàn)Puppet執(zhí)行效率開始下降，服務(wù)器已無(wú)法滿足你的需求。下面介紹幾種方案來(lái)解決這類問(wèn)題。

LoadBlancer

這是通過(guò)非常簡(jiǎn)單的擴(kuò)容Master方案，來(lái)提升Master計(jì)算“偽代碼”的能力。通常這種架構(gòu)能支撐1000臺(tái)左右的服務(wù)器。當(dāng)然，這也依賴于你的系統(tǒng)是否夠“復(fù)雜”。

圖2 LoadBlancer方案

這種架構(gòu)有兩種常用的實(shí)現(xiàn)方式：Apache+Passenger，以及Nginx+Mongrel。本文將以后者為例簡(jiǎn)單介紹其工作方式。

1. Puppet Master運(yùn)行多個(gè)進(jìn)程：

Puppet Master+Mongrel，port 18140

Puppet Master+Mongrel，port 18141

Puppet Master+Mongrel，port 18142

Puppet Master+Mongrel，port 18143

2. Nginx通過(guò)Upstream的方式實(shí)現(xiàn)對(duì)Puppet Master的負(fù)載均衡。Nginx監(jiān)聽port 8140將除文件下發(fā)之外的請(qǐng)求，代理轉(zhuǎn)發(fā)給上面的4個(gè)Puppet Master實(shí)例之一，Nginx會(huì)對(duì)客戶端證書進(jìn)行驗(yàn)證，但需要配置CA簽發(fā)的證書才允許請(qǐng)求，我們也可以再配置8141提供證書簽發(fā)。

3. 如果使用了fileserver，Nginx也可以直接處理。#p#

Puppet認(rèn)證負(fù)載均衡

僅有多個(gè)Master是否夠用？一臺(tái)機(jī)器還是有風(fēng)險(xiǎn)，為此我們需要有容錯(cuò)，將Master分布在不同機(jī)器上，而CA認(rèn)證也是非常重點(diǎn)的一部分，我們可以采用以下架構(gòu)做一個(gè)熱備。如圖3所示。

這 架構(gòu)還可以進(jìn)行擴(kuò)展。我們?cè)俅位仡橮uppet工作原理；Puppet客戶端跟Nginx之間是HTTPS連接，Nginx跟各個(gè)Mongrel之間用的 是HTTP連接。對(duì)客戶端證書的驗(yàn)證由Nginx負(fù)責(zé)，而Nginx只需要有CA的公鑰就可以做驗(yàn)證工作。這樣做的好處是多臺(tái)管理機(jī)之間不需要同步客戶端 的證書等設(shè)置，只需要有CA的公鑰，公鑰復(fù)制就能使用。但這樣有一個(gè)缺點(diǎn)：不太方便刪除客戶端證書。不過(guò)可以采用一個(gè)主管理機(jī)的方式，其他管理機(jī)從這臺(tái)管 理機(jī)上實(shí)時(shí)同步證書。

圖3 Puppet認(rèn)證負(fù)載均衡方案

Puppet管理機(jī)集群思路如下：

1. 將CA配置同步到每臺(tái)機(jī)器上，包括公私鑰；

2. 用CA給每臺(tái)管理機(jī)器簽發(fā)一個(gè)證書；

3. 每臺(tái)管理機(jī)都配成LoadBalancer的方式，8140提供配置管理，8141提供證書簽發(fā)；

4. 各管理機(jī)之間可以使用Keeplived實(shí)現(xiàn)高可用性及故障切換，包括HA等，架構(gòu)可隨意擴(kuò)展；

5. 每臺(tái)管理機(jī)配置分Production和Development兩種，簡(jiǎn)單地通過(guò)Git中發(fā)布到管理機(jī)上；

6. 測(cè)試時(shí)只修改Development部分，在個(gè)別客戶端指定用它，成功后再推到Production下；

7. 配置一臺(tái)主CA管理機(jī)，解決刪除認(rèn)證的問(wèn)題。#p#

合理規(guī)劃

所有的一切事后挽救方案都不如使用前合理規(guī)劃，你需要非常清楚當(dāng)前業(yè)務(wù)的狀態(tài)、運(yùn)維的現(xiàn)狀。了解你需要解決什么問(wèn)題，然后將它分解，再逐步擊破。

• 推薦采用Git管理Puppet；
• 規(guī)范HostName，采用DNS管理；
• fileServer獨(dú)立，將不經(jīng)常變化的放在fileserver里，經(jīng)常變化的放在模板中；
• 溝通自定義OS。

可能很多人不太明白為什么要自定義OS，它***的優(yōu)點(diǎn)就是可以在系統(tǒng)初始化安裝時(shí)幫你做一些Puppet所需要的軟件包，通過(guò)采購(gòu)設(shè)備時(shí)拿到的SN號(hào)，在 WebUI系統(tǒng)里注冊(cè)這臺(tái)機(jī)器的信息，機(jī)器在啟動(dòng)后即可完成所有的配置。如果你的WebUI做得更好，可以調(diào)用監(jiān)控系統(tǒng)的API完成監(jiān)控。這樣是不是很***？

結(jié)束語(yǔ)

相信大家讀完本文后不但對(duì)Puppet有了整體的了解，而且會(huì)更加熟悉自動(dòng)化運(yùn)維工作的重點(diǎn)。也許會(huì)讓你開始考慮在自己的運(yùn)維工作中，嘗試采用Puppet解決諸多重復(fù)性勞動(dòng)，或者解決你現(xiàn)在所面臨的架構(gòu)問(wèn)題。

我想對(duì)很多希望學(xué)習(xí)Puppet或正在使用Puppet的系統(tǒng)管理員說(shuō)，工作原理很重要，很多人就是沒有弄明白工作原理，因而在使用過(guò)程中一遇到問(wèn)題就手忙腳亂。讀者朋友們一定要靠多動(dòng)腦思考來(lái)解決問(wèn)題。

作者劉宇，linuxtone.org創(chuàng)始人之一，SinaEdge平臺(tái)運(yùn)維主管。負(fù)責(zé)新浪微博、新浪視頻、看點(diǎn)、微盤、音樂等業(yè)務(wù)CDN運(yùn)維。曾編寫《Puppet集中化管理》。