每個IT專家都遭受過代碼在生產環境上不能正常運行的困境。有經驗的開發者耗費幾個小時、幾天、乃至幾個星期的時間進行應用程序開發，但在應用發布 之後就不得不持續不斷地為它打各種補丁。質量保證工程師能夠確保應用達到了高性能和低磁盤占用的各種指標……但只限於他們的測試系統環境。運維工程師在進 行每次部署操作都得逐字逐句地仔細對照檢查表，結果發現他們還是得整日整夜地加班工作，才能夠讓應用能夠在生產環境上正常運行（或者說苟延殘喘）。
與此同時，公司的執行長官們則是暴跳如雷。因為他們認為自己已經花了這麼多錢，卻依然得不到滿意的結果。“為什麼新的特性要這麼長時間才能發布，連改一個bug都要這麼久？”客戶們在遠離我們的產品，競爭者的技術已經遠遠領先我們，就連華爾街也留意到了我們的頹勢。
陷入以上這種困境的IT組織通常極度缺乏組織紀律。開發、運維和測試人員的管理各行其是，各自遵循不同的衡量標准和工作目標，他們或許在不同的大樓 裡工作，有些人甚至從來沒有見過面。這些團隊很可能使用不同的技術棧進行工作，各自使用不同的配置。應用程序的代碼或許還算穩健，但除此之外就是一團散沙 了。能夠在開發者的筆記本、或是在QA環境下正常工作的代碼，往往在部署到生產環境後就會出現問題。最糟糕的是：沒人知道問題的根源在哪裡。
Puppet的創始人Luke Kanies曾經也是那些在數據中心中徹夜加班的運維人員之一。正是出於對現狀的不滿，促使他編寫了這套如今被稱為Puppet的軟件。
等一下——我們剛才談論的不是組織的問題嗎？一套軟件怎麼能夠解決組織文化的問題，並促進團隊的協作呢？答案是，軟件確實做不到這一點，至少它本身 是做不到的。Puppet是一個優秀的基礎設施管理平台，可以讓每個系統管理員更高效地完成工作，哪怕是一個封閉的運維團隊也能夠掌握。而對於那些准備提 高團隊的協作能力的組織來說，Puppet能夠為共享的代碼庫提供一種強力的粘合劑，以統一不同團隊的工作。請耐心地聽我介紹Puppet的工作原理，以及它是如何幫助處於各種不同狀況的團隊增強協作能力，以進行軟件開發和發布的——這種工作方式的演變通常被稱做DevOps。
“Puppet”這個詞實際上包括了兩層含義：它既代表編寫這種代碼的語言，也代表對基礎設施進行管理的平台。
Puppet是一種簡單的建模語言，使用它編寫的代碼能夠對基礎設施的管理實現自動化。Puppet允許對整個系統（我們稱之為節點）所希望達到的 最終狀態進行簡單地描述。這與過程式的腳本有明顯的不同：編寫過程式的腳本需要你清楚地知道如何將某個特定的系統轉變至某種特定的狀態，並且正確地編寫所 有這些步驟。而使用Puppet時，你不需要了解或指定達到最終狀態的步驟，你也無需擔心因為錯誤的步驟順序，或是細微的腳本錯誤而造成錯誤的結果。
與過程式的腳本的另一點不同在於，Puppet的語言能夠跨平台運行。Puppet將狀態進行了抽象，而不依賴於具體實現，因此你就可以專注在你所 關心的那一部分系統，而將實現的細節，例如命令的名稱、參數及文件格式等等交給Puppet自己負責。舉例來說，你可以通過Puppet對所有的用戶以相 同的方式進行管理，無論該用戶是用NetInfo或是/etc/passwd方式進行存儲的。
這種抽象的概念正是Puppet功能的關鍵所在，它允許使用者自由選擇最適合他本人的代碼對系統進行管理。這意味著團隊之間能夠更好地進行協作，團隊成員也能夠對他們所不了解的資源進行管理，這種方式促進了團隊共同承擔責任的意識。
Puppet這門建模語言的另一個優勢在於：它是可重復的。通常來說，要繼續執行腳本文件，必須對系統進行變更。但Puppet可以被不斷地重復執行，如果系統已經達到了目標狀態，Puppet就會確保停留在該狀態上。
Puppet語言的基礎在於對資源的聲明。每個資源都定義了系統的一個組件，例如某個必須運行的服務，或是某個必須被安裝的包。以下是一些其它類型資源的示例：
可以將資源想象為構建塊，他們將結合在一起，對你所管理的系統的目標狀態進行建模。
接下來，我們將接觸到Puppet中更深入核心的定義，這些定義允許你以一種經濟的方式將資源進行結合，而經濟正是Puppet的關鍵特色之一。
Puppet將類似的資源以類型的方式進行組織。舉例來說，用戶是一種類型，文件是另一種類型，而服務又是一種類型。當你正確地對某 個資源的類型進行描述之後，接下來只需描述該資源所期望的狀態即可。比起傳統的寫法：“運行這個命令，以啟動XYZ服務”，你只需簡單地表示：“保證 XYZ處於運行狀態”就可以了。
提供者則在一種特定的系統中，使用該系統本身的工具實現各種資源類型。由於類型與提供者的定義被區分開來，因此某個單一的資源類型 （例如“包”）就能夠管理多種不同的系統中所定義的包。舉例來說，你的“包”資源能夠管理Red Hat系統下的yum、基於Debian的系統下的dpkg和apt，以及BSD系統中的端口。
管理員通常來說不大有機會對提供者進行定義，除非管理員打算改變系統的默認值。Puppet中已經精確的寫入了提供者，因此你無需了解如何對運行在 基礎設施中的各種操作系統或平台進行管理。再次聲明，由於Puppet將細節進行了抽象，因此你無需擔心各種細節問題。如果你確實需要編寫提供者，那也通 常能夠找到一些簡單的Ruby代碼，其中封裝了各種shell命令，因此通常非常簡短，同時也便於創建。
類型和提供者使得Puppet能夠運行在各種主流平台上，並且允許Puppet不斷成長與進化，以支持運算服務器之外的各種平台，例如網絡與存儲設備。
下面的一個示例將為你展現Puppet語言的便捷性，它首先演示了如何用shell腳本添加一個新用戶以及一個新的組，這與Puppet中始終一致 的操作形成鮮明對比。而在使用Puppet的示例中，“用戶”和“組”都是類型，Puppet能夠自動找到適用於你的平台的提供者。相比之下，特定於平台 的過程式腳本無論是編寫還是理解都要困難得多。
Puppet語言中的其它元素的主要作用是為資源的聲明提供更多的靈活性和便捷性。類在Puppet中的作用是切分代碼塊，將資源組織成較大的配置單元。舉例來說，一個類能夠包括所有安裝和配置NTP時必須的Puppet代碼。類的創建與調用可以在不同的地方完成。
不同的類集合可以應用在扮演不同角色的節點上。我們將其稱之為“節點分類”，這是一項非常強大的能力，它允許你根據節點的能力，而不是根據節點的名稱對他們進行管理。這種“別把家畜當寵物”的機器管理方式，得到了許多快速發展的組織的偏愛。
Puppet語言文件被稱為清單，最簡單的Puppet部署方式就是一個單獨的清單文件加上一些資源。如果我們為以上示例中的基礎Puppet代碼命名為“user-present.pp”文件，那它就成為了一個清單。
模塊是一系列類、資源類型、文件和模板的結合，他們以一某個特定的目的，並按照某種特定的、可預測的結構組織在一起。模塊可以為了各 種目的而創建，可以是對Apache實例進行完整的配置以搭建一套Rails應用程序，也可以為各種其它目的進行創建。通過將各種復雜特性的實現封裝在模 塊中，管理員就能夠使用更小、可讀性更好的清單文件對模塊進行調用。
Puppet模塊的一個巨大優勢在於模塊的重用性。你可以自由使用他人編寫的模塊，並且Puppet有一個參與者數量巨大的活躍社區，除了Puppet Labs的員工所提編寫的模塊之外，社區成員們也會免費地分享他們所編寫的模塊。你能夠在Puppet Forge上 找到超過3000個可以免費下載的模塊，其中有許多模塊是系統管理員的工作中最常見的一些任務，因此這些模塊能夠節約你大量的時間。比方說，你可以使用模 塊進行各種管理任務，包括簡單的服務器構建塊（NTP、SSH）管理，乃至復雜方案（SQL Server或F5）的管理。
類、清單和模塊都是純粹的代碼，與組織中所需要的其它任何在代碼一樣，它們能夠、也應該被簽入到版本控制系統當中，稍後我們將對這一點展開討論。
完整的Puppet解決方案不僅僅是指這門語言。使用者需要在不同的基礎設施中部署Puppet代碼、時不時地對代碼及配置進行更新、糾正不恰當的 變更、並且時時對系統進行檢查，以保證每個環節的正常運行。為了滿足這些需求，大多數使用者會在某個主機-代理結構中運行Puppet解決方案，由一系列 組件所組成。根據不同的需求，使用者可以選擇運行一個或多個主機。每個節點上都會安裝一個代理，通過一個經過簽名的安全連接與主機進行通信。
采取主機-代理這一結構的目的是為了將Puppet代碼部署在節點上，並長期維護這些節點的配置信息。在對節點進行配置之前，Puppet會將清單編譯為一個目錄（catalog）， 目錄是一種靜態文檔，在其中對系統資源及資源間的關系進行定義。根據節點的工作任務，以及任務的上下文不同，每個目錄將對應一個單獨的節點。目錄定義了節 點將如何工作，Puppet將根據目錄的內容對節點進行檢查，判斷該節點的配置是否正確，並且在需要時應用新的配置。
在常規Puppet運行期間，每個基於節點的代理會定期與某個主機進行檢查工作，Puppet會根據不同結果進行以下各種操作：
Puppet Lab還提供了一個商用版本的解決方案，名為Puppet Enterprise，其中包括了客戶支持服務，並提供了一系列高級且重要的功能：
現在，你對Puppet的工作原理有一個基本的了解了，但你可能仍然會感到疑惑：Puppet怎樣幫助你的組織解決深層次的問題，並簡化人們的協作方式呢？
一切重點在於：在你使用Puppet時，你是在對你的基礎設施進行建模，正如對代碼建模一樣。你能夠像對待代碼一樣的方式處理Puppet，或者從 更廣的意義上說，是對基礎設施的配置進行同樣的處理。Puppet代碼能夠方便地進行保存和重用，能夠與運維團隊的其他成員，以及其他任何需要對機器進行 管理的團隊成員進行分享。無論是在筆記本上的開發環境，還是在生產環境上，開發人員和運維人員都能夠使用相同的清單對系統進行管理。因此當代碼發布到生產 環境時，各種令人不快的打擊就會少很多。 這將大大改善部署的質量，尤其是在我們所見到的組織中更是如此。
將配置作為代碼處理，系統管理員就能夠為開發人員提供獨占的測試環境，開發人員也不再將系統管理員視為礙事的人了。你甚至可以將Puppet代碼交付給審記，如今有許多審記都接收Puppet清單，以進行一致性驗證。這些都能夠提升組織的效率，並點燃員工的熱情。
最重要的一點或許在於，你能夠將Puppet代碼簽入到某個共享的版本控制工具中，這將為你的基礎設施提供一個可控的歷史記錄。你可以實行在軟件開發者中十分常見的結對審查實踐，讓運維團隊也能夠不斷地對配置代碼進行改善、變更和測試，直到你有信心將配置提交至生產環境。
由於Puppet支持在模擬環境或noop模式下運行，你就可以在應用改動之前預先檢查改動會造成的影響。這將大大緩解部署的壓力，因為你可以隨時選擇回滾。
通過在Puppet使用中結合版本控制，以及之前我們所提到的各種優秀實踐，許多客戶實現了持續集成方面的最高境界，能夠更頻繁地將代碼提交至生產 環境，並且產生的錯誤更少。如果你能夠以更小的增量部署應用，你就能夠更早、更頻繁地獲得用戶的反饋，它將告訴你你是否正處在正確的前進方向上。這樣就可 以避免在經過6到12個月開發工作，提交了大量代碼之後，卻發現它並不符合客戶的需要，或是對客戶沒有吸引力這種悲慘情形的發生了。
我們的客戶會選擇與開發人員的應用程序代碼同步對開發、測試以及生產環境上的配置進行變更，這就讓開發者能夠在一個非常接近於真實環境，甚至與生產 環境完全相同的環境中進行工作。再也不會發生由於在開發與測試環境中的配置的不同，導致應用程序在生產環境上崩潰的情況出現了。開發者和QA能夠部署更優 秀的軟件、運維人員不再需要整夜無眠、而執行官們……好吧，就算他們談不上有多高興，至少也能夠對結果感到滿意，從而將關注點轉移到IT團隊的效率以外的 事情上了！
不可否認，我們所見過的多數組織在持續協作方面都遠遠沒有達到一個高水准，更不用說持續交付了。而Puppet的一個優點在於，隨著你的團隊的成長 和基礎設施的規模增加，Puppet也能夠隨之成長。或許你還沒有准備好在整個公司范圍內推行DevOps的實踐，這不要緊。許多客戶都在保守的、循規蹈 矩的行業，例如銀行業與政府項目中成功地將Puppet作為配置管理工具進行應用。這些組織或許對持續交付方面的需求很低，但不管怎樣，能夠將基礎設施作 為代碼進行保存與版本化，這就極大地改善了這些組織的變更控制，以及安全實踐了。
我們建議你首先對某個能夠簡化你工作的任務開始實現自動化。舉例來說，許多管理員首先會對NTP、DNS、SSH、防火牆、用戶和組等實現自動化管理，這些都是日常工作，但又經常會產生各種問題的任務。
當人們逐漸熟悉了Puppet之後，他們就會更進一步，開始編寫更復雜的模塊對服務進行管理，例如Tomcat的監控服務，或JBoss的應用服務 器管理，還有一些人會開始采用Forge模塊。當你做好進一步探索的准備，你就能夠確保數據中心、乃至雲端的所有機器都正確配置了各種任務、並確保這些任 務運行正常，而且整個系統也處於正常運行狀態中，以保證你的核心業務的應用程序正常運轉。
你要記住的一點是，並非所有基礎設施的代碼都要你來編寫，這一點非常重要。在你之前已經有人解決了這些問題，因此你只需對這些工作成果善加利用！我 們之前提到了Puppet Forge上提供了幾千個模塊，你也可以在Puppet社區中尋求幫助，其中的模塊更達到幾萬個之多。你也可以訂閱Google上的Puppet用戶組，或是查看ask.puppetlabs.com論壇上的內容，並與論壇中的活躍人士混熟。你也可以參加當地的Puppet Camp或Puppet用戶小組，與小組成員進行面對面的交流。你還可以利用Puppet Labs上的學習資源，包括免費和付費的版本。在YouTube頻道上和我們的官方文檔中也可以學到各種知識。
當你進入了Puppet的生態系統後，以上這些只是全部學習資源的一小部分。我們期待與你相會，幫助你學習如何使用Puppet改善你的基礎設施、業務和工作生活。
原文：http://www.infoq.com/cn/articles/introduction-puppet
