大資料時代高伸縮性、容錯性的特點給運維提出了更高的要求。系統管理不再是疲於安裝作業系統、對系統引數進行逐一配置與優化、打補丁、安裝軟體、配置軟體、新增某個服務的時代。為了提高效率、避免重複勞動、減少錯誤、積累知識，系統管理員都已開始做一些區域性的自動化工作。但這些還遠不夠， 為了滿足運維需求，需要更徹底地應用自動化運維工具。
本文將介紹如何利用配置管理自動化工具puppet完成系統安裝、監控報警工作，解剖puppet給系統管理員帶來的便利，同時還將介紹puppet的架構和工作原理。
從系統安裝到自動化部署軟體、配置、回滾，再到伺服器的可用性、效能、安全維護，運維管理人員都需要完全掌握，為了有效完成工作，熟悉幾款優秀的開源軟體必不可少。如表1所示。
對於我來說，工具箱中最趁手的要數kickstart、puppet、zabbix和cacti。
運維工作難點
運維工作流程
常見的運維工作流程包括：安裝系統→優化系統與配置→安裝軟體→配置軟體→新增監控→檢查。後續可能還會有新增服務→配置變更→打補丁修復漏洞等。是不是覺得很繁瑣？尤其當你負責大量裝置，無法憑藉一己之力完成時，便需要一些工具來幫忙。
運維工作面臨的各種不確定性更讓人頭疼。在10臺機器上變更應用還是很簡單的事，但如果上公升到千台、萬台就會變得非常複雜。重複性的勞動還會讓人覺得疲憊和乏味，久而久之可能還會產生厭倦工作的情緒。使用puppet則能將這些問題迎刃而解。
自己實現自動化
為了提公升工作效率，減少出錯機率。很多公司都在逐步採用自動化來實現上述工作。有的公司選擇自己開發一套工具，因為可以按照需求任意定製，但這真的有必要嗎？我們來看看這樣做的缺點。
1. 從頭造輪子：構建指令碼工作的挑戰與繁瑣。
2. 程式的可維護性無法保障（語言）。
3. 支撐不同的平台。
4. 系統重灌後的考慮。
統籌與規劃整個系統需要花費很長時間，伴隨著人員的流動，技能水平不一，還會帶來新的問題。而且單獨開發的系統不可能只是支撐乙個平台——跨平台開發則意味著更多不確定性。
自動化配置工具比較
表2比較了兩種最常用的自動化運維工具puppet和cfengine。
但我真正想說的是：以上比較沒有太多的意義，工具在於你怎麼去用，如何用得最好，發揮出它的優勢，與你的業務完美結合。我們不需要忙著選工具，而是應該深入研究它。
剖析puppet
在使用任何軟體前我們都需要了解其工作原理，否則會給後續使用帶來諸多不便。puppet採用了非常簡單的c/s架構，所有資料的互動都通過ssl進行，以保證安全。它的工作流程如圖1所示。
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臺左右的伺服器。當然，這也依賴於你的系統是否夠「複雜」。
這種架構有兩種常用的實現方式：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的公鑰，公鑰複製就能使用。但這樣有乙個缺點：不太方便刪除客戶端證書。不過可以採用乙個主管理機的方式，其他管理機從這台管 理機上實時同步證書。
puppet管理機集群思路如下：
1. 將ca配置同步到每台機器上，包括公私鑰；
2. 用ca給每台管理機器簽發乙個證書；
3. 每台管理機都配成loadbalancer的方式，8140提供配置管理，8141提供證書簽發；
4. 各管理機之間可以使用keeplived實現高可用性及故障切換，包括ha等，架構可隨意擴充套件；
5. 每台管理機配置分production和development兩種，簡單地通過git中發布到管理機上；
6. 測試時只修改development部分，在個別客戶端指定用它，成功後再推到production下；
7. 配置一台主ca管理機，解決刪除認證的問題。
合理規劃
所有的一切事後挽救方案都不如使用前合理規劃，你需要非常清楚當前業務的狀態、運維的現狀。了解你需要解決什麼問題，然後將它分解，再逐步擊破。
可能很多人不太明白為什麼要自定義os，它最大的優點就是可以在系統初始化安裝時幫你做一些puppet所需要的軟體包，通過採購裝置時拿到的sn號，在 webui系統裡註冊這台機器的資訊，機器在啟動後即可完成所有的配置。如果你的webui做得更好，可以呼叫監控系統的api完成監控。這樣是不是很完 美？
結束語
相信大家讀完本文後不但對puppet有了整體的了解，而且會更加熟悉自動化運維工作的重點。也許會讓你開始考慮在自己的運維工作中，嘗試採用puppet解決諸多重複性勞動，或者解決你現在所面臨的架構問題。
我想對很多希望學習puppet或正在使用puppet的系統管理員說，工作原理很重要，很多人就是沒有弄明白工作原理，因而在使用過程中一遇到問題就手忙腳亂。讀者朋友們一定要靠多動腦思考來解決問題。
集中化運維管理 Puppet管理之路
大資料時代高伸縮性 容錯性的特點給運維提出了更高的要求。系統管理不再是疲於安裝作業系統 對系統引數進行逐一配置與優化 打補丁 安裝軟體 配置軟體 新增某個服務的時代。為了提高效率 避免重複勞動 減少錯誤 積累知識，系統管理員都已開始做一些區域性的自動化工作。但這些還遠不夠，為了滿足運維需求，需要更徹...
集中化運維管理 Puppet管理之路
文 劉宇 大資料時代高伸縮性 容錯性的特點給運維提出了更高的要求。系統管理不再是疲於安裝作業系統 對系統引數進行逐一配置與優化 打補丁 安裝軟體 配置軟體 新增某個服務的時代。為了提高效率 避免重複勞動 減少錯誤 積累知識，系統管理員都已開始做一些區域性的自動化工作。但這些還遠不夠，為了滿足運維需求...
集中化運維管理 Puppet管理之路
大資料時代高伸縮性 容錯性的特點給運維提出了更高的要求。系統管理不再是疲於安裝作業系統 對系統引數進行逐一配置與優化 打補丁 安裝軟體 配置軟體 新增某個服務的時代。為了提高效率 避免重複勞動 減少錯誤 積累知識，系統管理員都已開始做一些區域性的自動化工作。但這些還遠不夠，為了滿足運維需求，需要更徹...