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

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

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

表1 常用運維工具分類

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

運維工作難點

運維工作流程

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

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

自己實現自動化

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

1. 從頭造輪子：構建指令碼工作的挑戰與繁瑣。

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

3. 支撐不同的平臺。

4. 系統重灌後的考慮。

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

自動化配置工具比較

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

表2 Puppet和Cfengine功能對比

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

剖析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也可以直接處理。

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管理機，解決刪除認證的問題。

合理規劃

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

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

可能很多人不太明白為什麼要自定義OS，它最大的優點就是可以在系統初始化安裝時幫你做一些Puppet所需要的軟體包，通過採購裝置時拿到的SN號，在 WebUI系統裡註冊這臺機器的資訊，機器在啟動後即可完成所有的配置。如果你的WebUI做得更好，可以呼叫監控系統的API完成監控。這樣是不是很完 美？

結束語

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

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

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