本文轉載自朱雙印個人日誌：https://www.zsythink.net/archives/306

這篇文章將會解釋puppet在獨立模式下的工作流程，並且初步的介紹”提供者”的概念。

我們回顧一下puppet在master/agent模式下的簡化過的工作流程，如下圖：

上圖中的工作流程為puppet在master/agent模型下的工作流程。我們說過，puppet也可以工作在單機模式下，也就是說，只需要agent端即可完成工作，不需要puppet master，這種情況下，agent就無法從master端獲取catalog了，那麼agent所在的伺服器上必須存在對應的”清單”，以便能過通過清單獲取配置資訊，所以，單機模式下，puppet的工作流程如下圖所示。

從上圖可以看出，單機模式下，puppet客戶端的工作流程並沒有發生多大改變，唯一不同的就是puppet agent從本機獲取了manifest而已，所以，如果我們沒有接觸過puppet，完全可以使用單機模式學習puppet，這樣會讓我們的學習曲線不是那麼陡峭。

我們需要考慮一個問題，當puppet工作在master/agent模型下的時候，如果我們使用明文傳輸協議，那麼被管理主機的配置資訊有可能會被”不懷好意”的人獲取到，所以，我們不應該使用明文傳輸，而puppet為了確保傳輸的安全性，使用的https協議進行傳輸的，所以，puppet中會有自建的CA存在，以保證資料加密傳輸，而當我們在單機模式中使用puppet時，卻不存在這些問題，這樣會方便我們學習puppet，所以，當我們開始動手實際操作puppet時，就從單機模式開始。

我們再來思考一個問題，作為運維工程師，我們管理的伺服器上可能安裝了各種各樣的作業系統，他們有可能是redhat/centos，可能是windows server，也可能是unix，當我們想要使用puppet在這些伺服器上批量安裝同一個應用時，我們應該怎樣怎樣做呢，我們知道，在linux中，我們可以使用rpm包直接安裝，也可以通過yum源安裝應用，雖然本質上yum源也是使用rpm包進行安裝，但是yum源會自動解決依賴關係並且下載對應的安裝包， 而在windows中，我們可能會手動的點選一個字尾名為exe或者msi的檔案進行安裝，那麼puppet能知道被管理伺服器是windows還是linux嗎，答案是肯定的。

當我們使用puppet安裝某個應用時，puppet會自動判斷被管理伺服器的系統平臺，並且會選擇對應的預設方法安裝對應的檔案，puppet針對不同的作業系統以及發行版，準備了對應的預設的安裝方案，我們只要告訴puppet，安裝哪個檔案，檔案在哪裡即可，因為puppet把這些問題通過”中間層”的概念解決了，這個”中間層”負責判斷伺服器上具體的作業系統是什麼，這個中間層在puppet中被稱為”資源抽象層”，資源抽象層會自動匹配作業系統的種類與發行版，然後選擇對應的預設的provider對作業系統進行操作（provider又稱提供者），rpm、yum、apt、msi這些”東西”在puppet中都被稱為provider(提供者)，而管理員只要工作在”配置語言層”即可，我們只要按照配置語言的語法，將配置寫入配置檔案（清單）中，而資源抽象層根據我們的配置，選擇對應作業系統的預設的provider，並且通過provider執行對應的安裝操作，但是某些情況下我們需要指定”提供者”，就拿centos為例，我們在centos中，既能使用rpm包安裝，也能通過yum源安裝，它們都屬於centos系統的提供者，但是puppet預設情況下使用yum作為redhat/centos系統的提供者，如果在沒有yum源的情況下，我們可以通過清單，指定使用rpm作為提供者，當然，如果預設的提供者能夠滿足我們的需求，我們就更加方便了，只是通過上面的文字描述，可能不太容易理解，不過沒有關係，這些只是純粹的概念，我們在後面的使用中，會更加清晰的理解它們，此處我們不用細究，這並不影響我們繼續學習puppet。

好了，說了這麼多理論，我們該動動手了，剩下的沒有涉及到的理論等到用到的時候，我們再根據實際情況進行總結。