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

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

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

表1 常用運維工具分類

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

運維工作難點

運維工作流程

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

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

自己實現自動化

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

1. 從頭造輪子：構建腳本工作的挑戰與繁瑣。

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

3. 支撐不同的平臺。

4. 系統重裝后的考慮。

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

自動化配置工具比較

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

表2 Puppet和Cfengine功能對比

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

剖析Puppet

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

圖1 Puppet工作流程

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

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

3. 客戶端Puppetd調用Facter，Facter探測出主機的一些變量，例如主機名、內存大小、IP地址等。Puppetd將這些信息通過SSL連接發送到服務器端。

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

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

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

7. 客戶端判斷有沒有配置Report，如果已配置，則把執行結果發送給服務器。

8. 服務器端把客戶端的執行結果寫入日志，并發送給報告系統。

當服務器超過千臺

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

LoadBlancer

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

圖2 LoadBlancer方案

這種架構有兩種常用的實現方式：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的方式實現對Puppet Master的負載均衡。Nginx監聽port 8140將除文件下發之外的請求，代理轉發給上面的4個Puppet Master實例之一，Nginx會對客戶端證書進行驗證，但需要配置CA簽發的證書才允許請求，我們也可以再配置8141提供證書簽發。

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

Puppet認證負載均衡

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

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

圖3 Puppet認證負載均衡方案

Puppet管理機集群思路如下：

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

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

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

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

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

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

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

合理規劃

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

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

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

結束語

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

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

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