## 18.1\. 概述 Puppet 是一個用 Ruby 寫的開源 IT 管理工具，用于數據中心自動化和服務器的管理，用戶包括 Google, Twitter, 紐約證券交易所以及很多其他機構。Puppet 的主要維護者是 Puppet Labs，也就是 Puppet 項目的發起者。Puppet 可以管理從 2 臺到 5 萬臺機器，管理員可以只有1個人或者是上百人。 Puppet 是一個用于配置和維護計算機的工具；通過使用 puppet 的簡單的配置語言，你可以告訴 Puppet，你希望如何配置機器，然后 Puppet 就會按照你的指示來修改機器的配置。之后，如果你改變了需求，比如更新了軟件包，增加了新用戶，或是更新了配置，那么 Puppet 也會自動地隨之更新你的機器。而如果這些機器本來就已經配置好了，Puppet 就什么都不會動。 總的講，Puppet 可以借助任何已有的系統特性來完成它的工作。比如，在 Red Hat 中，它會使用`yum`?來進行包管理，并修改?`init.d`?來管理系統服務；而在 OS X 中，Puppet 則使用 dmg 來管理軟件包，使用?`launchd`?來管理系統服務。Puppet 的一個目標就是讓你或者系統本身都可以通過 Puppet 代碼來明白如何進行工作，所以，必須要能夠遵從各個系統的規范。 Puppet 集成了很多已有工具的傳統。從開源社區的角度講，對 Puppet 影響最大的莫過于 CF-Engine 和 ISconf 了，CF-Engine 是第一個開源通用配置管理工具，而 ISconf 使用了?`make`?來完成所用工作，其靈感來源于顯式地處理系統中所有的依賴關系。在商業軟件中，Puppet 受到了 BladeLogic 和 Opsware （兩者都已經被大公司收購了）的影響，在 Puppet 項目開始時，這兩種工具都在市場中獲得了不小的成功，不過兩者都更加關注于向大公司的管理層來推銷，相反，對于直接為管理員提供一個強大的工具，沒有足夠的重視。Puppet 希望和這些工具解決差不多的問題，但關注的用戶有很大不同。 這個簡單的例子用于解釋如何使用 Puppet，例子中的這段代碼用來確保系統中安裝了 SSH 服務，并配置正確： ~~~ class ssh { package { ssh: ensure => installed } file { "/etc/ssh/sshd_config": source => 'puppet:///modules/ssh/sshd_config', ensure => present, require => Package[ssh] } service { sshd: ensure => running, require => [File["/etc/ssh/sshd_config"], Package[ssh]] } } ~~~ 這個配置確保軟件包被安裝，文件就位，并且服務運行。注意，我們指定了資源之間的依賴關系，這樣，我們就可以確保一定能夠按照正確順序工作。這個類 (class) 可以被關聯到任何一個需要這個配置的主機。Puppet 配置的基本組件是結構化的對象，在這個例子里就是?`package`,?`file`?和`service`。我們將這些對象稱為資源 (resource)，Puppet 配置中的任何東西，最后都會分解為一些資源，以及資源間的依賴關系。 通常，一個使用 Puppet 的機構可能擁有數十甚至上百個這樣的代碼段，我們稱之為類 (class)，我們將存儲這些類的文件稱為貨單 (`manifest`)，這些被按照相關性分組，這些組稱為模塊 (module)。比如，你可能有個?`ssh`?模塊，其中包含了這個?`ssh`?類和一些其他相關類，同時還會有諸如?`mysql`,`apache`, 以及?`sudo`?等模塊。 大部分的 Puppet 交互都通過命令行或是一直運行著的 HTTP 服務進行的，不過有些東西也有圖形界面，比如報告處理。Puppet Labs 還提供了一些 Puppet 的周邊商業產品，這些產品更傾向于使用基于 web 的圖形化界面。 Puppet 的第一個原型寫于2004年夏天，從2005年2月開始成為了一個有全職投入的項目。Puppet 最初由 Luke Kanies 設計并實現，它是一位經驗豐富、寫過很多不足萬行的小工具的管理員。本質上說，隨著 Puppet 的開發，Luke 學著稱為了一位程序員，從程序架構上說，這具有正反兩面性。 Puppet 最初并最重要的目的就是成為一個管理員的工具，讓他們的工作更輕松、更快、更高效，且更不易犯錯。第一個關鍵性的創新就是上面提到的資源，這是 Puppet 的基本元素，它們是跨操作系統可移植的，并且抽象的資源屏蔽了實現細節，允許用戶關注配置的結果，而非具體如何實現這些配置。而這些基本元素本身由 Puppet 的資源抽象層來實現。 在一臺給定的主機上，Puppet 資源必須是唯一的。你只能有一個叫 "ssh" 的包，一個叫 "sshd" 的服務，也只能有一個叫 "/etc/ssh/sshd_config" 的文件。這就避免了你的配置的不同部分之間的沖突，一旦發生沖突，你會在進行配置的最初階段發現它。我們可以通過資源的名稱和類型來指定一個資源，比如?`Package[ssh]`?和?`Service[sshd]`。你可以有一個包和一個服務同名，因為它們類型不同，但不論如何，你都不可以有兩個同名的包或是同名的服務。 Puppet 的第二個重要創新是提供了一種方法，來直接指定資源之間的依賴關系。之前的各種工具的關注點都在于某個孤立的工作是否完成，而非它們之間的各種關聯性；Puppet 是第一種明確地將依賴關系作為配置中的一等元素的工具，而且，必須在建模中明確指出依賴型。Puppet 會根據資源及其依賴型構建出一張圖，在 Puppet 的執行過程中，每件事情都對應于這張圖（稱為目錄, Catalog）和圖的頂點與邊。 Puppet 的最后一個重要組成部分是它的配置語言。這是一種聲明性的語言，其重點在于配置數據，而非編程。很大程度上說，它沿襲了 Nagios 的配置格式，不過也受到了 CFEngine 和 Ruby 的很大影響。 除了功能性組件之外，在 Puppet 開發過程中，還有兩個指導性原則：簡單勝過一切，易用性勝于能力；先做框架，再做應用，其他人可以在 Puppet 的基礎上開發它們自己的應用。可以這么理解，Puppet 框架需要一個殺手級的應用（Puppet 本身）來讓自己獲得廣泛接受，但框架始終是關注的焦點，而非應用。當然，大部分人開始會將 Puppet 作為一個應用來使用，而非其背后的框架。 當 Puppet 的原型剛剛搭建出來時，Luke 還是一個 Perl 程序員，也有不少 shell 經驗以及一些 C 的經驗，主要使用 CFEngine 工作。不尋常的一點是，他擁有為簡單語言寫解析器的經驗，曾經為一些小工具寫過解析器部分，也從頭重寫過 CFEngine 的解析器，來讓它更容易維護（這段代碼從未被提交到上游項目中去，因為有些小的兼容性問題）。 對于 Puppet 的實現，選擇一個動態語言是沒什么爭議的，因為動態語言的開發效率會更高，但是選擇一個合適的語言卻十分困難。最初的使用 Perl 的原型不是非常好用，所以 Luke 開始考慮其他語言。Python 曾經被考察過，但 Luke 發現這種語言和他的世界觀不夠匹配。在朋友的關于語言易用性的言論影響下，Luke 嘗試了 Ruby，4小時之后，他就使用 Ruby 完成了一個可用的原型。在2005年，當 Puppet 成為 Luke 的全職項目時，Ruby 還是一種默默無聞的語言，這個決定顯然有巨大的風險，程序員的開發效率是選擇 Ruby 的決定性因素。相對于 Perl，Ruby 的最顯著的特性是，非常容易構建非層次式的（non-hierarchical）類間關系，這和 Luke 所想的非常匹配，這之后被證明是決定性的（critical）。 ## 18.2\. 架構概覽 本章主要討論 Puppet 的實現架構（也就是我們用來讓 Puppet 來完成我們想讓它進行的工作的代碼），不過，簡要探討一下應用架構（也就是程序的各個部分之間如何通信）也會很有幫助，這會讓我們對實現有所感覺。 Puppet 支持兩種工作模式：客戶機/服務器模式，由一個中心服務器和部署到各個主機上的代理（agent）構成；或無服務器模式（serverless），由一個單獨的進程完成所有工作。為了確保這些模式之間的一致性，Puppet 內部始終是對網絡透明的，這樣，兩種模式可以使用相同的代碼，只是是否走網絡有所不同。每個可執行程序都可以根據需要配置使用本地或遠程服務，除此之外，它們的行為都是完全一致的。注意，你也可以在進行客戶機/服務器使用的情況下使用無服務器模式，只要將所有配置文件推送到每個客戶端上，并讓它們直接解析這些文件即可。本節將集中在客戶機/服務器模式上，因為這樣更易于把各個功能理解為彼此獨立的組件，不過請各位明白，這些實際上在無服務器模式下也是同樣的。 Puppet 架構上的一個設計決策是，認為客戶端不應該直接訪問到 Puppet 模塊；相反，它們應該得到專為它們編譯的配置。這樣做有很多好處：首先，這遵從了最小權限準則，每臺主機只能得到它自己需要知道的（它該如何配置自己），不會知道其他服務器如何配置。其次，你可以將編譯配置的權限（需要訪問中央數據存儲）和實施配置的權限彼此分離。第三，當主機之后每次應用配置的時候，可以處于離線狀態，無需與中央服務器保持連接，這意味著即使是服務器當即了，或者兩者無法連接了（比如，移動客戶端，或是客戶端位于DMZ中等），也可以重復應用配置。 這樣，Puppet 的工作流就比較直接了： 1. Puppet 代理進程收集當前主機的信息，并交給服務器。 2. 解析器利用系統信息和磁盤上存儲的模塊信息，編譯為對這臺機器的一個配置信息，并將這些配置信息返回給代理。 3. 代理將配置應用到本地主機，這將影響主機的本地狀態，之后，將結果狀態匯報給服務器。   這樣，代理擁有訪問它自己的系統信息、配置、以及它自己生成的報告的權限。服務器擁有這些數據的副本，還有訪問所有 Puppet 模塊、后端數據庫和可能用于編譯配置信息的服務的權限。 這個工作流圖中的組件之外，我們后面還會用到很多 Puppet 用來進行內部通信的數據類型。這些數據類型非常重要，因為這些數據中有些是決定了各種通信如何進行，有些公開類型影響到其他工具如何產生或使用這些與 Puppet 交互的數據。 最重要的數據類型包括： * **Facts**: 從每臺機器上收集到的系統數據，用于編譯為配置。 * **Manifest**: 包含 Puppet 代碼的文件，通常被組織為一些稱為“模塊 (modules)”的集合中。 * **Catalog**: 一張包含主機上可管理資源及其依賴關系的圖。 * **Report**: 對于一個 Catalog，在其應用過程中產生的所有事件的集合。 在 Facts, Manifests, Catalogs, 和 Reports 之外，Puppet 還支持 files, certificates （用于鑒權）等服務類型。