Puppet簡介

jopen 9年前發布 | 16K 次閱讀 Puppet

原文  http://www.infoq.com/cn/articles/introduction-puppet


每個IT專家都遭受過代碼在生產環境上不能正常運行的困境。有經驗的開發者耗費幾個小時、幾天、乃至幾個星期的時間進行應用程序開發,但在應用 發布之后就不得不持續不斷地為它打各種補丁。質量保證工程師能夠確保應用達到了高性能和低磁盤占用的各種指標……但只限于他們的測試系統環境。運維工程師 在進行每次部署操作都得逐字逐句地仔細對照檢查表,結果發現他們還是得整日整夜地加班工作,才能夠讓應用能夠在生產環境上正常運行(或者說茍延殘喘)。

與此同時,公司的執行長官們則是暴跳如雷。因為他們認為自己已經花了這么多錢,卻依然得不到滿意的結果。“ 為什么新的特性要這么長時間才能發布,連改一個 bug 都要這么久? ”客戶們在遠離我們的產品,競爭者的技術已經遠遠領先我們,就連華爾街也留意到了我們的頹勢。

陷入以上這種困境的IT組織通常極度缺乏組織紀律。開發、運維和測試人員的管理各行其是,各自遵循不同的衡量標準和工作目標,他們或許在不同的 大樓里工作,有些人甚至從來沒有見過面。這些團隊很可能使用不同的技術棧進行工作,各自使用不同的配置。應用程序的代碼或許還算穩健,但除此之外就是一團 散沙了。能夠在開發者的筆記本、或是在QA環境下正常工作的代碼,往往在部署到生產環境后就會出現問題。最糟糕的是:沒人知道問題的根源在哪里。

Puppet的創始人Luke Kanies曾經也是那些在數據中心中徹夜加班的運維人員之一。正是出于對現狀的不滿,促使他編寫了這套如今被稱為Puppet的軟件。

等一下——我們剛才談論的不是組織的問題嗎?一套軟件怎么能夠解決組織文化的問題,并促進團隊的協作呢?答案是,軟件確實做不到這一點,至少它本身是做不 到的。Puppet是一個優秀的基礎設施管理平臺,可以讓每個系統管理員更高效地完成工作,哪怕是一個封閉的運維團隊也能夠掌握。而對于那些準備提高團隊 的協作能力的組織來說,Puppet能夠為 共享的代碼庫 提供一種強力的粘合劑,以統一不同團隊的工作。請耐心地聽我介紹Puppet的工作原理,以及它是如何幫助處于各種不同狀況的團隊增強協作能力,以進行軟件開發和發布的——這種工作方式的演變通常被稱做DevOps。

Puppet是什么?

“Puppet”這個詞實際上包括了兩層含義:它既代表編寫這種代碼的語言,也代表對基礎設施進行管理的平臺。

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語言中的其它元素的主要作用是為資源的聲明提供更多的靈活性和便捷性。 在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代碼部署在節點上,并長期維護這些節點的配置信息。在對節點進行配置之前,Puppet會將清單編譯為一個 目錄 (catalog),目錄是一種靜態文檔,在其中對系統資源及資源間的關系進行定義。根據節點的工作任務,以及任務的上下文不同,每個目錄將對應一個單獨 的節點。目錄定義了節點將如何工作,Puppet將根據目錄的內容對節點進行檢查,判斷該節點的配置是否正確,并且在需要時應用新的配置。

在常規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 CampPuppet用戶小組 ,與小組成員進行面對面的交流。你還可以利用 Puppet Labs上的學習資源 ,包括免費和付費的版本。在 油Tube頻道 上和我們的 官方文檔 中也可以學到各種知識。

當你進入了Puppet的生態系統后,以上這些只是全部學習資源的一小部分。我們期待與你相會,幫助你學習如何使用Puppet改善你的基礎設施、業務和工作生活。

關于作者

Puppet簡介

Susannah Axelrod 2013年辭去了她在Huron Consulting公司所擔任的產品經理總監一職,隨后加盟了Puppet Labs。在加入Huron之前,Susannah曾在Thomson Reuters、Sage Software、Intuit和Intel等公司從事產品領導方面的角色。她樂于分析用戶需求,解決用戶的問題。Susannah具有芝加哥大學的本科 學位,以及賓夕法尼亞大學的沃頓商學院的MBA學位。
 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!