關於Puppet不得不說的故事

 

Puppet對於作DevOps的同窗來講，是個熟悉的名字，但仍有許多人並不瞭解它。那麼我先來簡單介紹一下：Puppet是由Puppetlabs公司開發的系統管理框架和工具集，被用於IT服務的自動化管理。因爲良好的聲明式語言和易於擴展的框架設計以及可重用可共享的模塊，使得Google、Cisco、Twitter、RedHat、New York Stock Exchange等衆多公司和機構在其數據中心的自動化管理中用到了puppet。半年一度的PuppetConf大會也躋身於重要技術會議之列。AWS的CloudFormation文檔中有一段關於Puppet的介紹，其開頭是這麼說的: Puppet has become the de facto industry standard for IT automation。

        同時，puppet在Openstack中也發揮着重要的做用：Openstack-ci社區將其用於Openstack wiki系統,持續集成系統等等的運維管理(參見http://puppet-dashboard.openstack.org:3000/)；此外社區的puppet-openstack項目用於完成Openstack服務的自動化部署和管理，目前已經在stackforge中託管並經過Openstack的Gerrit系統來管理代碼；此外，Cisco,RedHat,Miriantis等多家公司的Openstack發行版或部署工具中均使用到了puppet-openstack。目前，Puppet在UnitedStack的平常運維管理和產品的自動化部署中也起到了重要做用。

       好了，剛剛還不瞭解Puppet的讀者們如今已經知道Puppet是一個牛逼哄哄的自動化運維管理工具。可能有人已經下完了軟件包躍躍欲試了，先別急，有關puppet的使用資料在網上能夠搜到一大堆，官方的文檔也詳細到了「使人髮指」。關於puppet的使用經驗分享和各類特性的深刻探討以及如何使用Puppet管理Openstack部署的方案分析，哦，都不在本文的討論範圍以內。

       本文的重點是八卦一下Puppet爲何能夠這麼成功。同時，爲避免引發非Puppet程序員感官上的不適，我屏蔽了各類代碼級別的展現和對細節的探討。

Luke Kanies的技術之路

   故事要從Luke Kanies，這位twitter暱稱與puppet的服務器端進程名同名的哥們提及，在好久好久之前...

 

成長：苦逼的學生時代

        在1992年的時候，Luke進入諾思蘭學院成爲了一名化學專業的學生，這是一所位於威斯康辛州的小學校，全美排名在178左右徘徊。

        小夥子很爭氣只呆了一年就跑到了大名鼎鼎的裏德學院，成爲了喬布斯的校友。不過倒黴的是裏德學院被評爲全美十大苦逼學校之一，6年畢業率僅爲75%，也就是有1/4的同窗拿不到畢業證。有別於不少文理學院自由選課的模式，裏德的大一學生必須完成規定的人文必修課程，學習希臘及羅馬的古典文化。這門課程已經有超過50年的歷史，裏德動用了學校最爲強大的師資力量來爲學生奠基文化基礎。這還沒完呢，以後學生還必須在四個拓展領域選課：文學、哲學、宗教、藝術方面;歷史、社科、心理學方面;天然科學方面;還有數學、邏輯、語言學或外語。大三學生必須經過專業測試，大四學生則必須完成專題畢業論文才能畢業。畢業論文並不可怕，可怕的是裏德學院的畢業論文的學時是一年，因此有想出國留學的同窗，請密切關注另外九所大學的名字…

       該來的仍是會來的，1996年，Luke大四了。要想順利畢業的話，他必須得修完這長達一年的論文項目，這意味着在這一年內他必需要動手設計和實現，並用實驗數據證實，最終組織成論文來完成課題。Luke的論文題目是Site-directed Mutagenesis in Soy Cytosolic Ascorbate Peroxidase，我推敲了半天，中文翻譯大體是：大豆抗壞血酸鹽過氧化物酶胞質的定點誘變。

打工：漂泊和積累

       萬幸的是，咱們不用去研究一口氣都念不完名字的論文。扯遠了，Luke畢業後沒去找一份和化學相關的工做而是去了Cypersite當起了Mac系統管理員。在Cypersite的日子裏，Luke使用AppleScript幹着行MacOS的管理工做，不過幹了不到一年還沒轉正的時候，他便跑路了。

       由於在97年的12月份，他在Metro One Telecommunications找到了一份系統管理員的活兒。Metro One Telecommunications當年但是納斯達克上市公司，主要業務是提供電話號碼查詢服務。在其巔峯時，公司在全美擁有7000名僱員，然而在2009年初，在售完最後一部分的經營業務後，該公司還剩餘3人。瞄了一眼Metro One今天的股價：0.01美圓。通訊行業早已經是昨日黃花了，吳軍博士已經在《浪潮之巔》中將這些歷史描述得盡致淋漓。

       又扯遠了，在Metro One的1年零9個月裏，Luke的主要工做是管理分散在全美的30個呼叫中心，包括了呼叫中心計算設備的部署和設置，外加從總部對其進行不間斷的維護。看到這裏，我忽然想到某家startup的創始人以前在電信部門作過相同的工做，後來他去作了一個很炫的可視化部署工具，我猜想通訊行業的部署工做充滿了重複的機械勞動，有一種自動化的強烈需求。這裏提一下，provision曾是電信行業中的一個術語，專指安裝通訊設備前的準備工做，而在devops中常說提起的bare-metal provision是指在計算機上安裝操做系統或者hypervisor的過程。

       在1999年，Luke離開了這家電話公司，在BlueStar擔任系統工程師，BlueStar是一家賣解決方案的經銷商，主營業務有：RFID, Auto ID, POS, Mobility products。Luke主要負責一家DSL ISP服務器端基礎架構的設計和實現。他構建了一套自動化且可集中管理的系統，並負責基礎架構項目的持續開發以及實施和維護。

        Luke在「藍翔」幹了還沒到兩年，又跑去了卡特彼勒融資服務公司擔任顧問，提供系統自動化管理相關的諮詢。我查了下，卡特彼勒公司位列世界500強，成立於1925年，是世界上最大的工程機械和礦山設備生產廠家、燃氣發動機和工業用燃氣輪機生產廠家之一，也是世界上最大的柴油機廠家之一。我在網上沒有查到Luke在這段時間具體幹了些什麼，只能感嘆Luke做爲一個系統管理員是怎麼混進一個高帥富的融資公司擔任顧問的。

創業伊始：對輪子的修修補補

        在卡特彼勒待了兩年後，Luke開始單飛，找人合夥建立了Reductive Consulting（2010年更名爲Puppetlabs），頭銜是獨立顧問，專門從事Unix基礎設施自動化相關的諮詢。他着手研究當前開源的系統管理和監控工具如CFEngine,ISconf,Nagios等等，而且經過二次開發把這些工具聯結成一套知足客戶需求的解決方案。這是一個重要的階段，Luke開始將積累多年的經驗和思考轉變爲對工具的改寫，這期間他的主要工做包括重寫了CFEngine的解析器和開發了ISConf3，這對後來的Puppet開發工做產生了重要影響。

CFEngine簡介

        首先，來講一下大名鼎鼎的CFEngine，這是一款出生於1993年的老牌系統配置管理工具，CFEngine的做者Mark Burgess但願可使簡單的管理任務自動化，使困難的任務變得較容易。它的核心理念是使系統從任何狀態都能收斂到一種理想狀態。

        這樣的工具對當時還在使用零零散散的腳原本管理機器的系統管理員來講簡直就是冬天的棉襖，夏天的雪糕，黑暗中的燈泡，飢餓中的麪包。以後，CFEngine天然而然地成爲了系統配置管理工具中的標杆。

       CFEngine有兩種工做模式：既可使用standalone模式即經過cfagent來完成單臺服務器的配置管理工做，也能夠經過C/S架構（cfservd和cfagent）來管理整個集羣的配置管理的分發工做。

       CFEngine的工做方式是基於腳本分發：在配置文件中有一個參數稱爲shellcommands，用於配置要執行的命令或腳本，actionsequence則用於設置shellcommands的執行順序。

        再來看看CFEngine的版本更新：1993年，CFEngine1發佈；1998年，CFEngine2發佈，而十年後，直到2008年，CFEngine3姍姍來遲，第三版發生了巨大改變，能夠經過使用DSL來定義系統狀態，以致於其不能再兼容舊版本CFEngine2的配置語言。本文談到CFEnigne時，是指CFEngine2。

ISconf簡介

        ISconf則是另一款配置管理工具，它的核心理念是系統的最終狀態是一致的，即便被管理的機器是關機狀態，當它們完成啓動以後，相關命令就會被執行，到達一致的狀態。同時整個系統無需中心節點，命令能夠在任何一臺節點上執行並複製到全部節點上。ISconf總共經歷了4代的演化。ISconf1和2是由shell腳本編寫，Luke在2002年的時候開發和設計了ISconf3，並使用Perl在2的基礎上進行了重寫。ISconf3有三個核心特性：

• 肯定性的執行順序
• 執行中有失敗時當即退出
• 狀態維護

        從上面的特性來看，是一個挺酷的產品。Luke在02年的時候完成了開發，並在03年的LISA（Large Installation Systems Administration）會議上發表一篇名爲'ISconf: Theory, Practice, and Beyond'的paper，談到了ISconf的特性，開發ISconf中得到的經驗和教訓，以及和CFengine的集成，分析ISconf 3的適用場景等等。不過ISconf社區在介紹ISconf3的歷史時對Luke的論文很有微詞，你能夠在ISconf的官網讀到這篇文章。不過，ISconf止步於第四版，最後的版本發佈時間停留在06年8月13日，緣由未知。

萌芽：自造輪子

       隨着Luke的夢想愈來愈大，這些工具集也變得愈來愈龐大。而此時對這些現有的開源工具的修修補補已經不能知足他的需求了。最終，他意識到只有他本身，才能去創造本身想要的工具。做爲一個多年的運維人員，他深深感覺到了苦逼的系統管理員們須要有一個嶄新的工具來使得他們的工做更高效，更便捷。所以，他開始考慮去開發一個新工具，首先這個工具是爲系統管理員而設計的。那麼怎麼才能稱爲得上是爲系統管理員設計的呢？

      先來簡單思考一下系統管理員對於配置管理工具的主要需求：學習成本低，開發高效，跨平臺，代碼可複用，安全，可擴展性高等等。

       最好的狀況就是系統管理員只需關心某個服務或者軟件包的狀態，例如我但願部署一個apache web服務器，我只關心apache的包是已安裝的狀態，服務是運行的狀態，而不要讓我去操心這個apache包是裝在Ubuntu下的仍是Redhat下，而後究竟是要執行yum install仍是apt-get install，而後還要操心這個apache進程究竟是用init仍是upstart管理的。

        此外，還有如何對依賴關係進行處理。先前的配置管理工具都是關注在如何去完成每一項互相獨立的工做，例如配置apache服務就是一段shell腳本而已，而沒有去考慮它們之間是存在關聯的，例如當apache的配置文件發生變動時，是應該重啓apache服務來使之生效，而重啓apache服務的前提是系統已經安裝了apache。

        這對於當時佔據主流的以分發shell/perl腳本的配置管理軟件來講，簡直是天方夜譚。不過Luke就是這麼設想的，他在構思Puppet的設計時，就但願將系統抽象成資源：採用面向對象的概念，將每一個資源類型組成爲一組屬性的集合，每一個屬性都有相應的行爲，並將資源類型和屬性構形成類，最終使用這些屬性來使得資源到達指望的狀態，而不是用資源自己來完成這些工做。同時，將全部資源的依賴關係構建成一張有向圖，經過這種依賴描述，系統管理員們能夠實現複雜的業務邏輯的管理。

        越想越興奮，因而Luke開始動手coding了。Puppet的第一個原型寫於04年夏天，但他並無把此事放在最重要的位置上。因而在9月份的時候，Luke竟然跑去了BladeLogic擔任產品設計，這是一家專門作商業配置管理軟件的公司，它的產品在當時已經取得了成功，然而Luke發現BladeLogic的品味僅僅是想賣軟件給大公司而不是立志爲系統管理員設計偉大的工具。在05年的2月份，Luke下決心繼續搞Puppet的開發工做。因而，在BladeLogic呆夠了7個月後，Luke選擇了離開。BladeLogic也終於如願以償：被BMC收購了，固然這是後話。

艱難抉擇: 開發語言和設計哲學

        隨後Luke回到了Reductive Consulting，也就是Puppetlabs 的前身，開始了Puppet的全職開發。

        不過他遇到了一個棘手的技術問題：身爲一個Perl程序員，Luke痛苦地發現，Perl竟然沒法處理那些puppet類之間的關係。那時Python被認爲是系統開發的最佳選擇，可是Luke同窗接受不了的不是Python的縮進問題，而是print是一個語句而不是函數，len是一個函數而不是方法的事實，讓他感受「眼睛在流血」。這時候，有個朋友告訴他Ruby很酷，因而他在嘗試了4個小時後，就寫出了一個功能原型，今後不可自拔。不過他也有點擔憂，由於在當時Ruby還屬於非主流，由於ROR（Rails on Ruby）都尚未出生，不過鑑於他的體驗，以爲使用Ruby的開發效率很是高，所以他決定冒一次險。

       在這個問題解決以後，Luke又面臨另一個難題：雖然在此以前他已經寫了很多的小工具，積攢了豐富的經驗，不過這些工具沒有一個的代碼量是超過1萬行的。這也意味着在設計Puppet的架構的過程當中，確定得摔很多的坑。所以，Luke在開發Puppet的過程當中始終要求本身和開發團隊遵照兩個指導思想：首先設計儘量地作到簡潔，程序的可用性老是高於新特性；此外Puppet首先是個框架其次纔是一個應用。在解決了語言選型和設計哲學的問題後，Luke開始潛心於Puppet的開發。

而後呢

       而後就沒有而後了，隨着Puppet的發佈和版本的快速迭代，以及社區的火熱發展，Puppet天然而然地就發展成了今天的模樣。下半部分原本是介紹深刻技術細節等等諸多細節，可是應主編和廣大羣衆要求保持純八卦風格的呼聲，下半部分在內部審批時被慘無人道地砍掉。不過對於想繼續深刻了解Puppet的讀者，我會在下篇博文中從架構和層次模型等等方面來講明爲何Luke說Puppet是一個簡單的複雜系統。對於Puppet和Luke的介紹到此告一段落，我們再來八一下羣衆們喜聞樂見的熱點事件。

投資風雲

       事情源於兩年前，VMWare做爲Puppetlabs的6家投資公司之一，向Puppetlabs投了850萬美刀。在今年的2月份，VMWare宣佈提升對PuppetLabs的投資：3000萬。此外，VMware負責雲架構和管理的執行副總裁Raghu Raghuram將進入Puppet Labs董事會。

        這從資本市場的角度說明了Luke和Puppet的成功，叫好又叫座。可是也引起了人們的擔心：一些人認爲Puppet的獨立性是很是重要的，理由是DevOps的成功很是依賴於這個組織選擇什麼樣的工具用於企業基礎設施管理，Puppetlabs做爲IT自動化管理領域裏的領頭羊，然而VMware對Puppet存在強大的話語權，目前Puppetlabs花了很大的精力在Puppet企業版本的開發上(Puppet PE)，用於和VMWare vCloud Automation Center等產品的集成。這並非一件好事，可能會使得社區版本和商業版本產生巨大的差距，甚至可能會發生Oracle和Mysql那樣的故事。

        再看看VMWare的老對手Amazon的反應，即便Amazon在開頭說起的文檔裏認可Puppet是事實上的行業標準，但考慮到它的老朋友VMWare手握對Puppetlabs 2/3的投資，在其新推出的OpsWork服務中清一色地使用了Chef用於系統的配置管理，這是誕生於Puppet以後的另一款開源的配置管理工具。

       再來聽聽其餘人的聲音。Matt Asay與Luke是多年的好友，在Lukes與Andrew Shafer創立Puppet Labs後，Matt 曾經提出了許多商業化建議，包括進行融資，但Luke更但願公司保持獨立。Matt淡定地回答記者：若是你瞭解Luke Kanies這個傢伙，你就知道保持獨立對於他而言是無比重要的事。他在田納西州長大，不是那種出賣靈魂的人。

        Luke在IM上和Matt表達了本身的見解：「向雲端轉換的趨勢將給下一代系統平臺管理工具帶來無限的機會，對VMware如此，對PuppetLabs亦是如此。即使Puppetlabs被VMware掌控，但這些系統仍構建在開源的基礎上，並賦予它們必定的自治權。Puppet擁有活躍的開源生態圈，就像OpenStack同樣，是對投資很好的補充。」

       最後談談個人見解，首先Puppet天生就是開源血統，其社區很是活躍，並且從2.7開始變爲更爲友好的Apache許可證（以前是嚴格的GPL）。所以，即便發生像MySQL那樣的事情，照樣會有另外一家MariaDB出現，更況且還有後起之秀Chef在一旁虎視眈眈，VMWare理應不會下這步昏棋。同時，對於指責Puppet只關注於與VMware產品的集成是有失偏頗的，雖然最近PE的動靜很大，可是Puppetlabs也花費了很大的精力投入到Puppet-Openstack社區中，在以後的Puppet系列博文中會對此進行闡述。因此，我並不擔憂Puppet是否會成爲下一個MySQL。

咱們學到了什麼？

        在前面洋洋灑灑的一堆八卦中，我簡單地談了一些關於Luke和Puppet的故事。每一個人可能都會從中看到不一樣的東西。對我而言，Puppet之因此能取得成功，我認爲有：

• 作本身最擅長的事：Luke擁有豐富的運維經驗和配置管理工具的開發經驗，在此基礎上去開發Puppet是得到成功的基礎之一；
• 取其精華：在調研同類工具和產品時，Luke不僅看到了其中的不足，還吸取了它們的優勢；
• 志存高遠：Luke開發puppet時候的動機是爲系統管理員提供最棒的CMS工具，而不只爲了掙錢，被收購，上市。動機越單純，成功的機率越大；
• 敢想敢作：如今去挑選手機，咱們幾乎不會去考慮手機是否是觸摸屏的而是去看屏幕有多大，PPI多高，由於手機是觸摸屏這是理所固然的，然而在iPhone以前，觸摸屏手機仍是很稀有的東西，你們都在往功能更多的方向越走越遠；一樣，如今在使用puppet時，會以爲使用聲明式配置語言是理所固然的事情，卻不知在puppet誕生的同時代中，都是清一色的命令式或者過程式的配置語言。

免責聲明

       本文的全部情節來自本人花費一週的夜生活時間，閱讀了各式各樣的博客，新聞，評論，代碼，勉強拼湊而成，如有與實際不符之處，請一笑而過。