### 書寫可重用的跨平臺配置清單 每個系統管理員都夢想著使用統一的、同質的基礎設施，相同的機器都運行相同的操作系統且其版本相同。 正如生活中的其他領域一樣，現實往往是凌亂的、往往與理想情況不符。 你很可能會負責管理一堆使用年限不同、架構不同、運行不同發行版本的不同內核的服務器， 常常是分散在不同的數據中心和不同的互聯網服務供應商（ISP）。 在這種情況下，會造成系統管理員心中對在 for 循環中執行 SSH（"SSH in a for loop"）的恐懼， 因為在每個服務器上即使執行相同的命令，也可能產生不同的、不可預知的、甚至是危險的結果。 當然，我們應該努力將舊服務器進行更新，并將一切盡可能工作在一個單一的參考平臺之上， 從而使管理更簡單，更廉價，更可靠。但在達到這一目標之前，我們可以使用 Puppet， 它可以使我們更容易地應對異構環境（heterogeneous environments）。 #### 操作步驟 1. 如果你有一些放置在不同數據中心的服務器，這些服務器需要略有不同的網絡配置， 例如，使用節點繼承技術來封裝差異： ``` node wreckspace_server inherits server { include admin::wreckspace_specific } ``` 2. 你需要應用相同的配置清單到運行著不同 OS 發行版本的服務器，其重要差別可能在于軟件包名、 服務名以及配置文件的存放位置。可以通過在一個類中使用選擇器（selectors） 捕獲這些差異并設置全局變量的值： ``` $ssh_service = $operatingsystem? { /Ubuntu|Debian/ => "ssh", default => "sshd", } ``` 之后你就不用擔心配置清單其他部分的差異了，當你要提及這些時， 可以放心的使用變量，它會根據具體環境正確的指向相應的正確值： ``` service { $ssh_service: ensure => running, } ``` 3. 我們經常需要配合不同的架構；這可能會影響共享庫的路徑，也可能需要不同版本的軟件包。 同樣地，嘗試在一個單一的 architecture 類中封裝所需要的全局變量的值： ``` $libdir = $architecture ? { x86_64 => "/usr/lib64", default => "/usr/lib", } ``` 之后在需要一個架構相關的值時，你就可以引用這些全局變量的值， 無論是在配置清單中引用還是在模板中引用均可： ``` ; php.ini [PHP] ; Directory in which the loadable extensions (modules) reside. extension_dir = <%= libdir %>/php/modules ``` #### 工作原理 這種方法的優點（可以稱為“自上而下”）是你僅需要進行一次選擇。 另一種是自下而上的方法，使用這種方法，在全部配置清單中你隨處可見 使用 selector 或 case 語句的設置： ``` service { $operatingsystem? { /Ubuntu|Debian/ => "ssh", default => "sshd" }: ensure => running, } ``` 這不僅會產生許多重復代碼，而且使代碼難于閱讀。另外，當需要管理一種新的操作系統時， 你必須在所有的配置清單中進行修改，而不是只修改一處。 #### 更多用法 如果你正在為一個公共的發布（例如 Puppet Forge）編寫模塊， 使其盡可能的跨平臺會讓模塊變得更有價值。盡你所能，在不同發布、不同平臺、不同架構上測試， 并且添加適當的變量，使模塊盡可能的應用到各種情況。 如果你正在使用一個公共模塊，并修改它適應自己的環境， 如果你認為你的修改可能會幫助到其他人，可以考慮向公共版本提交你的更新。 即使你不想發布你的模塊，請銘記：一個模塊可能會在生產環境中運行很長一段時間， 并且可能會對其做許多適應環境的改變。 如果從設計模塊的一開始就考慮到這些，那么你（或者最終維護你的代碼人）的生活將會變得更輕松。 > Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. > > — Dave Carhart #### 參見本書 * 本章的 [使用節點繼承](#ch04sec04) 一節 * 本章的 [使用類的繼承和重載](#ch04sec05) 一節 * 第 9 章的 [使用公共模塊](#ch09sec08) 一節