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

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

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

表1 常用運維工具分類

對于我來說，工具箱中最趁手的要數(shù)Kickstart、Puppet、Zabbix和Cacti。

運維工作難點

運維工作流程

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

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

自己實現(xiàn)自動化

為了提升工作效率，減少出錯機率。很多公司都在逐步采用自動化來實現(xiàn)上述工作。有的公司選擇自己開發(fā)一套工具，因為可以按照需求任意定制，但這真的有必要嗎？我們來看看這樣做的缺點。

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

2. 程序的可維護性無法保障（語言）。

3. 支撐不同的平臺。

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

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

自動化配置工具比較

表2比較了兩種最常用的自動化運維工具Puppet和Cfengine。

表2 Puppet和Cfengine功能對比

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

剖析Puppet

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

圖1 Puppet工作流程

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

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

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

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

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

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

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

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

當服務器超過千臺

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

LoadBlancer

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

圖2 LoadBlancer方案

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

1. Puppet Master運行多個進程：

Puppet Master+Mongrel，port 18140

Puppet Master+Mongrel，port 18141

Puppet Master+Mongrel，port 18142

Puppet Master+Mongrel，port 18143

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

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

Puppet認證負載均衡

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

這 架構(gòu)還可以進行擴展。我們再次回顧Puppet工作原理；Puppet客戶端跟Nginx之間是HTTPS連接，Nginx跟各個Mongrel之間用的 是HTTP連接。對客戶端證書的驗證由Nginx負責，而Nginx只需要有CA的公鑰就可以做驗證工作。這樣做的好處是多臺管理機之間不需要同步客戶端 的證書等設置，只需要有CA的公鑰，公鑰復制就能使用。但這樣有一個缺點：不太方便刪除客戶端證書。不過可以采用一個主管理機的方式，其他管理機從這臺管 理機上實時同步證書。

圖3 Puppet認證負載均衡方案

Puppet管理機集群思路如下：

1. 將CA配置同步到每臺機器上，包括公私鑰；

2. 用CA給每臺管理機器簽發(fā)一個證書；

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

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

5. 每臺管理機配置分Production和Development兩種，簡單地通過Git中發(fā)布到管理機上；

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

7. 配置一臺主CA管理機，解決刪除認證的問題。#p#

合理規(guī)劃

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

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

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

結(jié)束語

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

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

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