如上圖所示，puppet的工作流程如下：（1）客戶端puppetd調用facter，facter探測出主機的一些變量，例如主機名，內存大小，ip地址等。pupppetd 把這些信息通過ssl連接發送到服務器端； （2）服務器端的puppetmaster 檢測客戶端的主機名，然後找到manifest裡面對應的node配置， 並對該部分內容進行解析，facter送過來的信息可以作為變量處理，node牽涉到的代碼才解析，其他沒牽涉的代碼不解析。解析分為幾個階段，語法檢查，如果語法錯誤就報錯。如果語法沒錯，就繼續解析，解析的結果生成一個中間的“偽代碼”，然後把偽代碼發給客戶端；（3）客戶端接收到“偽代碼”，並且執行，客戶端把執行結果發送給服務器；（4）服務器端把客戶端的執行結果寫入日志。
puppet工作過程中有兩點值得注意，第一，為了保證安全，client和master之間是基於ssl和證書的，只有經master證書認證的client可以與master通信；第二，puppet會讓系統保持在你所期望的某種狀態並一直維持下去，如檢測某個文件並保證其一直存在，保證ssh服務始終開啟，如果文件被刪除了或者ssh服務被關閉了，puppet下次執行時（默認30分鐘），會重新創建該文件或者啟動ssh服務。
3. 軟件安裝
不推薦使用apt-get命令進行安裝，因為該命令下載的puppet存在bug。可直接從源代碼進行安裝，需要安裝的軟件有ruby，facter和puppet。
3.1 安裝步驟
編輯/etc/host以修改主機名，因為puppet是基於證書的，證書中包含主機名；
在master和slave上依次安裝ruby、facter和puppet，安裝facter和puppet時，要使用ruby install.rb。
3.2 安裝後的目錄結構
(1) 安裝目錄
安裝目錄默認存為/etc/puppet，該目錄下的manifests存放manifest文件。
其他可執行文件在/user/sbin下，主要有：
puppet： 用於執行用戶所寫獨立的mainfests文件，如：
puppet -l /tmp/manifest.log manifest.pp
puppetd： 運行在被管理主機上的客戶端程序，如：
puppet –server servername –waitforcert 60
puppetmasterd：運行在管理機上的服務器程序，如：
puppetmasterd –debug
puppetca puppet認證程序，主要用於對slave的證書進行認證，如：
查看需認證的slave：puppetca –list
對這些slave進行認證：puppetca -s –a
puppetrun 用於連接客戶端，強制運行本地配置文件，如：
puppetrun -p 10 –host host1 –host host2 -t remotefile -t webserver
(2) 配置文件
puppet.conf
Puppet的主配置文件，如果是root用戶，配置文件為/etc/puppet/puppet.conf，普通用戶，配置文件為：~user/.puppet/puppet.conf
具體配置參數，參見：
http://docs.puppetlabs.com/references/stable/configuration.html#configuration-files
fileserver.conf
puppet文件服務器的配置文件。用path配置文件路徑，allow/deny配置訪問權限，具體參見：http://docs.puppetlabs.com/guides/file_serving.html
3.3 驗證安裝是否成功
選定一個slave與master進行驗證，假設slave的host為slave00，master的host為masterhost，在slave00上輸入：
puppetd –test –server servername
然後在masterhost上查看待認證的slave：
puppetca –list
如果沒問題的話，此時可以看到slave00，對該slave的證書進行簽名：
puppetca -s -a
這樣slave00通過了證書驗證，可以與master進行進一步交互了。
在masterhost的/etc/puppet/manifests目錄下編寫site.pp文件，內容如下：
復制代碼代碼如下:
node default {
file {
“/tmp/test”:
content=>”hello\n”,
mode => 0644;
}
}
同時在slave00上輸入：puppetd –test –server servername， 查看slave00的/tmp文件夾，生成了一個新文件test，裡面的內容是hello，該文件的權限是-rw-r—r—。這樣，便證明puppet安裝成功，如果出現錯誤，查看第六節。
4. 配置腳本編寫
本節介紹puppet的配置腳本編寫方法，主要是指puppet的manifest編寫方法。puppet把需要管理的內容抽象成為資源，每種資源有不同的屬性，因此puppet語言就是描述這些資源的屬性以及資源之間關系的語言。
為了便於管理，puppet將資源模塊化，即每個功能模塊的manifest單獨放在一個目錄下。每個模塊包含一個主要的manifest文件（init.pp，它是模塊的入口，類似於C語言中的main函數），裡面包含若干個class對該模塊的資源進行封裝，常見的資源有file，package，service等，每種資源由自己的屬性，如file有屬性name，owner，mode等。
本節主要介紹puppet中manifest的編寫方法，將依次介紹資源屬性，資源，節點管理，函數和模塊的編寫方法。
4.1 資源屬性
資源屬性有兩種，一種是資源專屬屬性，另一種是資源共同屬性，對於資源專屬屬性，將在下一節介紹；而資源共同屬性是所有資源共有的屬性，主要有：
before
用於控制不同對象（資源）的執行順序關系，表示某個對象（資源）在另一個對象之後發生（require與之相反，它表示之前發生）。如：
復制代碼代碼如下:
file { “/var/nagios/configuration”:
source => “…”,
recurse => true,
before => Exec["nagios-rebuid"]
}
exec { “nagios-rebuild”:
command => “/usr/bin/make”,
cwd => “/var/nagios/configuration”
}
這段代碼保證用make編譯之前，所有代碼都是最新的。也可以before多個資源，如：
before => [ File["/usr/local"], File["/usr/local/scripts"] ]
subscribe
檢測某個資源，當它發生變化時，該資源會重新加載，如：
復制代碼代碼如下:
class nagios {
file { “/etc/nagios/nagios.conf”:
source => “puppet://server/module/nagios.conf”,
alias => nagconf # just to make things easier for me
}
service { nagios:
ensure => running,
subscribe => File[nagconf]
}
}
當檢測到文件nagconf被修改時，服務nagios會相應的更新。需要注意的是，目前支持subscribe的資源只有exec，service和mount。
更多資料，參見：http://docs.puppetlabs.com/references/latest/metaparameter.html
4.2 資源
常用的資源主要有以下幾個：
file：文件管理
package：軟件包管理
service：系統服務管理
cron：配置定期任務
exec：運行shell命令
(1) file資源
更詳細資料，可參見：http://puppet.wikidot.com/file
(2) package資源
更詳細資料，可參見：http://puppet.wikidot.com/package
(3) service資源
更詳細資料，可參見：http://puppet.wikidot.com/srv
(4) exec資源
更詳細資料，可參見：http://puppet.wikidot.com/exec
(5) cron資源
更詳細資料，可參見：http://puppet.wikidot.com/cron
4.3 節點管理
puppet如何區分不同的客戶端，並且給不同的服務端分配manifest呢？puppet使用node資源做這件事情，node 後面跟客戶端的主機名，例如：
node ‘ slave00 ‘ {
include ssh
}
node ‘ slave11 ‘ {
$networktype=”tele”
$nagioscheckport=”80,22,3306″
include apache, mysql, php
}
資源node中可使用變量，也可直接通過include把其他manifest包含進來。
更詳細資料，可參見：http://docs.puppetlabs.com/references/latest/type.html
4.4 類和函數
類可以把多個相關的資源定義在一起,組成一個類。類可以繼承，具體參見：http://docs.puppetlabs.com/guides/language_guide.html#resource-collections
函數（在puppet中稱為“defination”）可以把多個資源包裝成一個資源，或者把一個資源包裝成一個模型，便於使用。例如，在debian裡面管理一個apache虛擬機非常簡單,把一個虛擬主機的配置文件放到/etc/sites-available/裡面,然後做一個符號鏈接到/etc/sites-enabled目錄。 你可以為你每個虛擬主機復制同樣的配置代碼，但是如果你使用下面的代碼就會更好和更簡單：
define virtual_host($docroot, $ip, $order = 500, $ensure = “enabled”) {
$file = “/etc/sites-available/$name.conf”
# The template fills in the docroot, ip, and name.
file { $file:
content => template(“virtual_host.erb”),
notify => Service[apache]
}
file { “/etc/sites-enabled/$order-$name.conf”:
ensure => $ensure ? {
enabled => $file,
disabled => absent
}
}
}
然後,你就可以使用這個定義來管理一個apache虛擬主機，如下面代碼所示：
virtual_host { “reductivelabs.com”:
order => 100,
ip => “192.168.0.100″,
docroot => “/var/www/reductivelabs.com/htdocs”
}
4.5 模塊
一個模塊就是一個/etc/puppet/modules目錄下面的一個目錄和它的子目錄，在puppet的主文件site.pp裡面用import modulename可以插入模塊。新版本的puppet可以自動插入/etc/puppet/modules目錄下的模塊。引入模塊，可以結構化代碼，便於分享和管理。例如關於apache的所有配置都寫到apache模塊下面。一個模塊目錄下面通常包括三個目錄：files，manifests，templates。manifests 裡面必須要包括一個init.pp的文件，這是該模塊的初始（入口）文件，導入一個模塊的時候，會從init.pp開始執行。可以把所有的代碼都寫到init.pp裡面，也可以分成多個pp文件，init 再去包含其他文件。files目錄是該模塊的文件發布目錄，puppet提供一個文件分發機制，類似rsync的模塊。templates 目錄包含erb模型文件，這個和file資源的template屬性有關。
puppet安裝好以後，modules目錄是沒有的，自己建立一個就行，然後在裡面可以新增加你的模塊。
5. 編程實例
5.1 Hello World
本節介紹了一個非常簡單的編程實例：一個slave從master中獲取其manifest，該maniftest要求slave依次做以下工作：安裝gcc，創建文件夾/home/dxc/test，下載文件hello.c程序，編譯hello.c。
(1) 代碼結構組織
Master上代碼的目錄結構如下：
|– auth.conf
|– fileserver.conf #puppet文件服務器配置文件
|– manifests #puppet主文件所在目錄
| |– modules.pp #puppet各個模塊匯總
| |– nodes #各個slave要處理的模塊
| | `– execHello.pp #hello模塊對應由那些slave處理
| `– site.pp #puppet主文件（入口文件）
|– modules #puppet的各個模塊所在文件
| `– hello #hello模塊
| |– files #該模塊對應的文件資源，可能是要發送給slave的配置文件等
| | `– hello.c
| `– manifests #模塊的manifest文件
| `– init.pp #模塊入口文件
`– ssl #puppet的證書文件目錄
(2) 程序執行流程
代碼調用順序是：
Slave發起連接請求 à site.pp à nodes àmodules à init.pp
首先，slave向發起master連接請求，進行證書驗證；
接著，證書驗證通過後，master會直接找到入口文件manifests目錄下的site.pp文件，該文件可能包含一些全局變量，參數缺省值（當各個模塊沒有設置這些參數時，它們的缺省值）以及其它pp文件的調用（在該例子中，會調用modules.pp和nodes下的各個pp文件）；
然後，master通過nodes下的各個pp文件定位到該slave要執行的模塊（init.pp是各個模塊的入口），匯總這些模塊代碼返回給slave；
最後，slave根據master發過來的manifest，配置信息。
(3) 代碼解釋
直接在此處下載代碼。
5.2 一個更復雜的實例
本節介紹了一個更為復雜的某個公司正在使用實例，puppet代碼布局與上一個實例一致，只不過該實例涉及到更多模塊，更復雜的依賴管理。代碼具體內容本節就不解釋了，具體參見代碼。
6. 可能遇到的問題
Q: puppet的證書機制
A: puppet證書問題是初學者最容易遇到的問題，這裡講一下怎麼處理。puppet服務器端在安裝或者首次啟動的時候，會自動生產一個根證書和服務器證書，證書和主機名相關，因此如果證書生成後友改了主機名，那就會出問題。 puppet客戶端在首次啟動的時候，也會自動生成證書；但是這個證書需要得到puppet服務器端的簽名才行，因此；puppet客戶端第一次連接服務器的時候，會發送一個證書請求；服務器端需要對這個證書進行簽名。puppet客戶端在下次連接服務器的時候就會下載簽名好的證書。
Q:Ubuntu下面的證書出錯，怎麼解決?
A:本方法是提供給初學者的測試環境，生成環境不建議這麼做。首先在puppetmaster(服務器端)刪除/var/lib/puppet/ssl目錄;然後啟動puppetmasterd；然後在客戶端也刪除/var/lib/puppet/ssl目錄。把puppetmaster機器的主機名和對應的ip地址寫入客戶端機器的/etc/hosts。
然後執行：puppetd –test –server server.example.com. 把server.example.com替
換成你自己的服務器主機名。 執行這個命令，會有提示信息，不用理會。
然後登錄到puppetmaster服務器機器，執行puppetca –list 命令，看看是否有客戶端的證書請求；如果沒有，請檢查前面的步驟是執行正確，以及網絡連接是否正常。 如果puppetca –list 能看到請求，那麼執行puppetca -s -a 命令；對所有的證書請求簽名。最後回到puppet客戶端機器，執行
puppetd –test –server server.example.com.
就能建立連接了，如果你的site.pp寫好了.就可以測試puppet了。
補充：如果客戶端和服務器端的時間不一致也會導致證書認證失敗，因此出現證書問題的時候需要檢查兩台機器的時間是否一致，如果不一致用date命令或者ntpdate命令讓兩台機器的時間一致。
Q:出現錯誤[Puppet Users] err: Could not retrieve catalog; skipping run
A：可能是由於安裝了兩個版本的ruby或者facter的原因，解決方案見：
https://projects.puppetlabs.com/issues/5279
7. 總結
隨著服務器集群規模越來越大，自動化配置和部署這些服務器能夠使管理變得非常容易並大大減小管理部署成本，因而得到IT公司的高度重視。
本文檔介紹了puppet，一種新型的軟件自動化配置和部署工具。本文主要內容涉及puppet的架構，安裝和使用方法，並給出了兩個使用實例。
在大規模的生成環境中，如果只有一台puppetmaster會忙不過來的，因為puppet是用ruby寫的，ruby是解析型語言，每個客戶端來訪問，都要解析一次，當客戶端多了就忙不過來，所以需要擴展成一個服務器組。puppetmaster可以看作一個web服務器，實際上也是由ruby提供的web服務器模塊來做的。因此可以利用web代理軟件來配合puppetmaster做集群設置，具體參見：http://puppet.wikidot.com/puppetnginx。
8. 參考資料
puppet官方網站：http://www.puppetlabs.com/
puppet中文wiki：http://puppet.chinaec2.com/
puppet中文博客：http://www.comeonsa.com
9. 代碼下載
(1)5.1節實例代碼下載
(2)5.2節實例代碼下載
原創文章，轉載請注明：轉載自董的博客
