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是開放的，允許新增任何新的功能。

通常這樣定義：Puppet是一個跨平臺的集中化配置管理系統，它使用自有的描述語言，可管理配置檔案、使用者、Cron、軟體包，系統服務等，Puppet把這些統稱為“資源”。Puppet的設計目標就是簡化對這些資源的管理以及妥善處理資源之間的依賴關係

2. Pupput的特性

許多系統配置管理工具工作的方式非常類似，如cfengine。是什麼讓Puppet與眾不同？Puppet的語法允許你建立一個單獨指令碼，用來在你所有的目標主機上建立一個使用者。所有的目標主機會依次使用適用於本地系統的語法解釋和執行這個模組。舉例：如果這個配置是在Red Hat伺服器上執行，建立使用者使用useradd命令；如果這個配置是在FreeBSD主機上執行，使用的是adduser命令。Puppet另一個卓越的地方是它的靈活性。源於開源軟體的天性，你可以自由的獲得Puppet的原始碼，如果你遇到問題並且有能力的話，你可以修改或者加強Puppet的程式碼去適用於你的環境。另外，社群開發者和捐獻者還在不斷增強Puppet的功能。一個大的開發者和使用者社群也致力於提供Puppet的文件和技術支援。

Puppet也是易於擴充套件的。定製軟體包的支援功能和特殊的系統環境配置能夠快速簡單的新增進Puppet的安裝程式中。

3. 關於Puppet的版本

Puppet版本眾多，一般而言Puppet的最佳版本通常都是最新的版本，如:0.24.x0.25.x2.6.x2.7.x3.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介紹到。

轉載於:https://blog.51cto.com/blief/1757957