本文轉載自朱雙印個人日誌，連結為：https://www.zsythink.net/archives/201

前文已經說過，puppet是C/S架構的，有服務端，也有客戶端，管理員可以通過puppet服務端（master），管理每一臺被管理的伺服器，但是需要puppet客戶端作為中介，也就是說，puppet客戶端作為代理（agent），接收來自puppet服務端的配置資訊，按照服務端（master）傳送過來的配置資訊，對被管理伺服器進行配置，真正執行配置操作的是puppet客戶端，puppet服務端只負責將配置資訊準備好，傳送給puppet客戶端，以便客戶端執行具體操作，puppet客戶端還有另一個作用，就是向puppet服務端傳送報告，當客戶端按照配置資訊執行完成相關配置以後，會將執行資訊傳送到服務端，比如執行成功與否，執行結果等，預設情況下，每30分鐘，puppet客戶端會向puppet服務端發起一次請求，請求受管理伺服器的配置資訊， puppet服務端將配置資訊傳送給客戶端，客戶端根據反回的資訊進行判斷，判斷被管理伺服器是否符合管理員定義的配置，

當然，puppet也可以不在master/agent模式下工作，我們可以在受管理伺服器上只安裝puppet客戶端，使用客戶端手動執行對應配置檔案，相當於配置檔案中的資訊並不是通過puppet服務端傳送過來，而是通過本地的配置檔案獲取，也是可以的，我們暫且稱這種不需要puppet服務端的工作模式為單機模式，我們在學習puppet時，可以使用單機的模式進行練習，但是在生產環境中，一般都使用master/agent的方式使用puppet。

還記得我們在文章的開頭提到的場景一嗎，我們就拿場景一做例子，比如，管理員想要在100臺伺服器上同時建立一個名叫”liuhaoran”的使用者，我們該怎樣使用puppet解決這個問題呢，我們來描述一下，首先，管理員需要在puppet服務端建立了一個配置檔案，這個配置檔案的作用就是在被管理主機上建立一個”liuhaoran”使用者，當管理員寫好配置檔案以後，通過puppet服務端，將準備好的配置檔案傳送到puppet客戶端，puppet客戶端會解析這些配置，然後判斷，被管理伺服器上是否存在”liuhaoran”使用者，如果”liuhaoran”使用者不存在，則建立liuhaoran使用者，如果”liuhaoran”使用者已經存在，puppet則不會建立這個使用者。

上面這段話會引出兩個概念，”資源”與”目標狀態”。

我們先說 “資源”的概念，在上述描述中，我們所要建立的使用者”liuhaoran”就算是一種資源，可以理解為”使用者資源”,如果我們把上述場景稍微改動一下，變成 “管理員想要在100臺伺服器上同時建立一個名叫play的組”，那麼，”play組”在puppet中也被稱之為”資源” ，我們可以這樣理解， puppet中把要操作的物件稱之為資源，說的通俗一點，就是如果我們要建立使用者，使用者就是資源，如果我們要刪除組，組就是資源，如果我們要使用puppet在多臺機器上安裝應用，應用就是資源，如果我們想要通過puppet啟動服務，那麼服務就是資源，如果我們想要使用puppet批量上傳某個檔案，檔案就是資源，”資源”在puppet中是一個抽象的概念，所以，我們可以把puppet將要操作的物件理解為資源。那麼我們經常使用puppet操作哪些資源呢，換句話說，常用的資源如下（並非全部）：

通過檢視上述列表中的常用資源，你可能已經推測出了某個結論，我們平常使用puppet，就是圍繞著檔案、軟體包，服務，命令等工作展開的，我們會通過puppet批量的操作這些資源，以免重複的工作。

我們再來聊聊”目標狀態”的概念，我們在上述建立liuhaoran使用者的例子中提到，puppet客戶端會判斷被管理伺服器上是否存在”liuhaoran”使用者，如果”liuhaoran”使用者不存在，則建立liuhaoran使用者，如果”liuhaoran”使用者已經存在，puppet則不會建立”liuhaoran”使用者, 這就是”目標狀態”的概念，我們在配置檔案中定義的最終目標是建立”liuhaoran”使用者，如果在被管理伺服器上已經存在liuhaoran使用者，那麼被管理伺服器的當前狀態與我們預期的”目標”相同，所以puppet不會再次執行建立使用者的操作，如果被管理伺服器上當前並沒有liuhaoran使用者，那麼puppet則認為被管理伺服器的當前狀態並不符合我們預期的”目標狀態”，這個時候，puppet則會執行建立使用者的操作，從而讓被管理伺服器達到我們指定的”目標狀態”，puppet通過”目標狀態”的概念，體現了puppet執行操作時的冪等性。

好了，聊完了場景一，我們來聊聊場景二，還記得場景二嗎，我們重複一遍場景二，以便大家能夠回憶起來。

場景二：公司新買了一堆雲伺服器，這些伺服器最終可能要提供相同的服務，現在需要管理員在這一堆伺服器上安裝一些相同的應用，而且安裝完成後，還需要這些伺服器上的應用自動啟動，怎麼辦，我們會推薦你使用puppet解決這個問題。 根據我們之前提到的概念，場景二中最起碼會使用到兩個資源，一個是package資源，一個是service資源，因為我們最起碼要將應用程式包安裝上，才能啟動對應的服務，於是，管理員開始定義配置檔案，配置檔案的最終目的就是安裝上對應的package，啟動對應的服務，那麼應該怎樣寫配置檔案呢，管理員只需要按照固定的語法，將資源按照一定的格式和順序寫在配置檔案中即可，我們會在後面的實際應用示例中，為大家展示怎樣寫配置檔案，配置檔案中可能包含了一個或多個資源，具體有哪些資源，會根據你的應用場景發生變化，就像場景二中，我們需要安裝應用，啟動服務，所以在配置檔案中最起碼有兩個資源，”配置檔案”在puppet中有一個專業術語，它被稱為”manifest”，翻譯過來就是”貨單”、”清單”的意思，其實想想，也很形象，可以這樣想象，我們把要操作的資源列在一個單子上，puppet根據這個單子執行對應的操作，最終實現我們的目標，這個被稱為”資源清單”或者”清單”的東西，其實就是我們的配置檔案。

但是，需要注意的是”清單”並不會被puppet直接執行，因為清單從本質上來說，是一個人類易讀的文字檔案，puppet會將清單進行進一步的處理，把它變成puppet可以理解的”機器語言”，而被處理過的清單被稱為”catalog”,也就是說，puppet會將清單先編譯成catalog，最終執行catalog。

我們說過，生產環境中，puppet往往是以master/agent的方式執行的，那麼，puppet服務端（以後簡稱master）與puppet客戶端（以後簡稱agent）到底是怎樣協作的呢，或者說，它們之間的內部工作流程是什麼樣子的呢，我們還是看圖說話，方便理解，為了更簡明的描述master與agent之間的工作流程，我們假設目前只有一臺master，並且只有一臺被管理伺服器，如下圖紅線標註的場景:

那麼，我們把上圖中的兩臺伺服器拿出來，詳細說說它們之間的具體工作流程，但是此處我們需要說明，在master/agent模型下工作的puppet的工作流程比我們總結的要複雜一點，但是為了入門方便，我們只取出其中的一部分核心的流程進行總結，在後面的實際應用中，我們會不斷的豐富這些流程，此處先給出一個簡化過的流程圖，如下圖所示。

• 1.客戶端puppet agent請求catalog，我們已經說過，catalog其實就是被管理伺服器對應的配置檔案（經過處理過的配置檔案），服務端master收到agent的請求，然後找到對應被管理伺服器的”站點清單”，或者被稱為”主機清單”，因為一臺”被管理伺服器”可能同時擔任多個”角色”，每個角色可能都會對應一個”manifest”（也就是清單），所以，我們可以為每一臺被管理伺服器配置一個”站點清單”，站點清單也可以理解成為一種”清單”，只是它是針對一臺伺服器而存在的一種清單。

• 2.服務端master找到被管理伺服器的站點清單後，根據站點清單，找到對應伺服器需要哪些”清單”，因為一臺伺服器可能會需要多張”清單”，上圖中為了示例，只畫出了一個清單，但是這不代表必定只有一個。

• 3.master將找到的所有”清單”進行處理，處理為catalog。

• 4.master將處理過的catalog傳送到agent端。

• 5.agent收到master傳送過來的catalog，然後，agent會查詢”被管理伺服器的當前狀態”，看看伺服器的當前狀態是否符合catalog中定義的目標狀態。

• 6.如果”被管理伺服器的當前狀態”與”catalog中定義的目標狀態”一致，那麼資源對應的操作將不會執行，如果”被管理伺服器的當前狀態”與”catalog中定義的目標狀態”不一致，那麼資源對應的操作將會執行，以便讓”被管理伺服器”達到管理員指定的”目標狀態”。

• 7.經過上一步的”狀態判斷”，執行對應操作，不管執行是否成功，都會生成對應的報告資訊。

• 8.agent將生成的報告資訊傳送給master端。

上述過程，就是puppet在master/agent模式下的工作流程，我們說過，預設情況下，客戶端每隔30分鐘向服務端請求一次配置資訊，然後根據服務端返回的配置資訊，判斷當前伺服器是否處於管理員定義的目標狀態，如果被管理的伺服器不處於管理員定義的目標狀態，則需要執行對應的操作，使得被管理主機最終處於管理員定義的目標狀態，我們也可以不必每次都等待30分鐘，我們可以從master端推送catalog到agent端，主動告訴agent端，配置已經發生了改變，請執行對應的操作。