集中化運維管理 Puppet管理之路

2021-06-09 15:45:48 字數 4042 閱讀 1419

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

本文將介紹如何利用配置管理自動化工具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臺左右的伺服器。當然,這也依賴於你的系統是否夠「複雜」。

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管理之路

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