Puppet是開源的基於Ruby的系統配置管理工具,依賴於C/S的部署架構。主要開發者是Luke Kanies,遵循GPLv2版權協議。從1997年開始Kanies參與UNIX的系統管理工做,Puppet的開發源於這些經驗。由於對已有的配置工具不甚滿意,從2001年到2005年間,Kanies開始在Reductive實驗室從事工具的開發。很快,Reductive實驗室發佈了他們的旗艦產品——Puppet。它使用簡單且功能強大,正獲得了愈來愈多地關注,如今不少大型IT公司均在使用puppet對集羣中的軟件進行管理和部署緩存
一. Puppet的介紹服務器
1. Puppet的用途架構
Puppet能夠用來管理UNIX(包括OSX)和Linux平臺,而且最近又添加了針對Microsoft Windows的支持。Puppet一般能夠用來管理一臺主機的整個生命週期:從初始化到安裝、升級、維護以及最後將服務遷移並下架。Puppet被設計爲可以持續與主機進行交互,而不是僅僅提供一個只負責搭建主機卻並無論理它們的工具。
併發
官方的定義是這樣的:Puppet是一個開源的新一代的集中化配置管理工具,它由本身所聲明的語言表達系統配置,經過客戶端與服務端之間的鏈接,維護着關係庫。Puppet的設計目標是讓Puppet成爲一個由富有表現力的語言支撐的足夠強大的庫。這樣只須要編寫短短的幾行代碼的自動化應用程序便可實現設計目標。同時Puppet是開放的,容許添加任何新的功能。
less
一般這樣定義:Puppet是一個跨平臺的集中化配置管理系統,它使用自有的描述語言,可管理配置文件、用戶、Cron、軟件包,系統服務等,Puppet把這些統稱爲「資源」。Puppet的設計目標就是簡化對這些資源的管理以及妥善處理資源之間的依賴關係。ide
2. Pupput的特性工具
許多系統配置管理工具工做的方式很是相似,如cfengine。是什麼讓Puppet不同凡響?Puppet的語法容許你建立一個單獨腳本,用來在你全部的目標主機上創建一個用戶。全部的目標主機會依次使用適用於本地系統的語法解釋和執行這個模塊。舉例:若是這個配置是在Red Hat服務器上執行,創建用戶使用useradd命令;若是這個配置是在FreeBSD主機上執行,使用的是adduser命令。Puppet另外一個卓越的地方是它的靈活性。源於開源軟件的天性,你能夠自由的得到Puppet的源碼,若是你遇到問題而且有能力的話,你能夠修改或者增強Puppet的代碼去適用於你的環境。另外,社區開發者和捐獻者還在不斷加強Puppet的功能。一個大的開發者和用戶社區也致力於提供Puppet的文檔和技術支持。性能
Puppet也是易於擴展的。定製軟件包的支持功能和特殊的系統環境配置可以快速簡單的添加進Puppet的安裝程序中。加密
3. 關於Puppet的版本spa
Puppet版本衆多,通常而言Puppet的最佳版本一般都是最新的版本,如: 0.24.x 0.25.x 2.6.x 2.7.x 3.x 4.x 固然,版本越高,支持的特徵越多,因爲Puppet 0.2x支持的特性很是少,不建議再安裝使用它。對於正在使用此版本的用戶,建議升級成最新版。對於新用戶,建議直接安裝Puppet 3.0版本。對於正在使用Puppet 2.6或2.7的用戶,建設逐步升級,且先升級Master,而後再升級Agent,平滑過渡,以免遇到不可預知的問題。目前Puppet最新版爲4.0,其中增添了許多新特性:
1. 性能提高:目錄編譯採用JSON做爲目錄緩存。
2. 加強操做系統與平臺支持:對Ruby1.9的完美支持,對操做系統Windows、Solaris包和服務的更多支持,Yumrepo對SSL的支持。
3. 使用Rubygems加載插件:能夠經過Rubygems來安裝和使用Puppet的擴展代碼。
4. Server自動發現:經過DNS SRV尋找CA、Master、Report和Fileserver。
5. DSL/config變化:auth.conf增長allow_ip配置選項,unless支持,插件同步默認改成True,更新configure的語法。
6. 其餘BUG的修復:修復了3.0 Agent 與2.7Master工做的問題、kick沒法工做問題、rack安裝啓動出錯問題等。
注意:Puppet 3.x 4.x將再也不支持Ruby 1.8.5如下版本。提示:更多Puppet版本信息可參考: http://projects.puppetlabs.com/projects/1/wiki/Release_Notes)
5. Puppet的工做模式
Puppet是一個C/S架構的配置管理工具,在中央服務器上安裝puppet-server軟件包(被稱做Puppet master)。在須要管理的目標主機上安裝puppet客戶端軟件(被稱做Puppet agent)。
當客戶端鏈接上Puppet master後,定義在Puppet master上的配置文件會被編譯,而後在客戶端上運行。每一個客戶端默認每半個小時和服務器進行一次通訊,確認配置信息的更新狀況。若是有新的配置信息或者配置信息已經改變,配置將會被從新編譯併發布到各客戶端執行。也能夠在服務器上主動觸發一個配置信息的更新,強制各客戶端進行配置。若是客戶端的配置信息被改變了,它能夠從服務器得到原始配置進行校訂。
Puppet擁有一個簡單而且容易理解和實施的操做模型。這個模型由三部分組成:1.部署; 2.配置語言資源抽象層; 3.事務層,以下圖所示:
1.1.1 部署
Puppet一般使用簡單的客戶端-服務端模型進行部署。服務端被稱爲"Puppet master",客戶端軟件被稱爲agent,主機自己則被定義爲一個節點。以下圖:
Puppet master在一臺主機上以守護進程的方式運行,它包含了環境所需的全部配置。Puppet agent則經過一個使用標準SSL協議進行加密和驗證的鏈接與Puppet master進行通訊,而後接收或者"拉取"須要被應用的配置。很重要的一點是,Puppet agent在已經得到了須要的配置或者沒有任何能夠被應用的配置時不會作任何事情。這意味着Puppet只會在須要時對你的環境做出變動。這整個過程被稱爲一次配置運行。
每個客戶端既能夠經過守護進程的方式來運行Puppet(好比使用cron),也能夠手動啓動。一般的作法是以守護進程的方式運行Puppet,並週期性地與master進行通訊,以此來保證配置已經更新到最新而且能及時接收新的配置。不過,也有不少人以爲使用cron或者手動運行Puppet更符合他們的需求。
在默認狀況下,Puppet agent會每30分鐘與master進行一次通訊,檢查新添加的或者已改變的配置。你能夠自行設定這個週期來適應你的環境。固然也存在其餘部署模型。好比,Puppet也能拋開Puppet master以獨立方式運行。在這種模式下,配置放置在被管理的主機上,而後經過手動運行puppet程序來執行和應用這些配置。咱們將在稍後討論這種模式。
關於puppet的配置語言和資源抽象層會在puppet入門與掌握之puppet介紹2介紹到。