Puppet——Luke Kanies的鋼鐵俠
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-intra社區將其用於Openstack wiki系統,持續集成系統等等的運維管理；此外社區的puppet-openstack項目用於完成Openstack服務的自動化部署和管理，目前已經在stackforge中託管並通過Openstack的Gerrit系統來管理代碼提交；此外，Cisco,RedHat,Miriantis等多家公司的Openstack發行版或部署工具中均使用到了puppet-openstack。目前，Puppet在UnitedStack的日常運維管理和產品的自動化部署中也起到了重要作用。
好了，剛剛還不了解Puppet的讀者們現在已經知道Puppet是一個牛逼哄哄的自動化運維管理工具。可能有人已經下完了軟體包躍躍欲試了，先別急，有關puppet的使用資料在網上可以搜到一大堆，官方的文檔也詳細到了「令人髮指」。關於puppet的使用經驗分享和各種特性的深入探討以及如何使用Puppet管理Openstack部署的方案分析，哦，都不在本文的討論範圍之內。 本文的重點是八卦一下Puppet為什麼可以這麼成功。同時，為避免引起非Puppet程序員感官上的不適，我屏蔽了各種代碼級別的展示和對細節的探討。
故事要從Luke Kanies，這位twitter昵稱與puppet的伺服器端進程名同名的哥們說起，在很久很久以前...
http://www.ituring.com.cn/download/01YdLOjU5f79.small[+]查看原圖
成長：苦逼的學生時代在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收購了，當然這是后話。
http://www.ituring.com.cn/download/01YdLOs85ayL
艱難抉擇: 開發語言和設計哲學隨後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的介紹到此告一段落，咱們再來八一下群眾們喜聞樂見的熱點事件。
投資風雲事情源於兩年前，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誕生的同時代中，都是清一色的命令式或者過程式的配置語言。
免責聲明
本文的所有情節來自本人花費一周的夜生活時間，閱讀了各式各樣的博客，新聞，評論，代碼，勉強拼湊而成，若有與實際不符之處，請一笑而過。
《解決方案》
牛啊。LZ支持你！！
《解決方案》
wenhq 發表於 2013-08-29 20:09 static/image/common/back.gif
牛啊。LZ支持你！！
轉過來的，給有需要的朋友，現在自動化運維確實發展很迅速啊
《解決方案》
:victory:
《解決方案》
讀起來很棒～謝謝樓主分享。
《解決方案》
挺不錯的文章，對了解puppet的發展挺有幫助的，支持！！！
《解決方案》
能在計算機行業做下來，並且有所累積，確實挺實在不錯的
《解決方案》
action08 發表於 2013-11-14 13:56 static/image/common/back.gif
能在計算機行業做下來，並且有所累積，確實挺實在不錯的
算是叼絲的逆襲了吧，這麼久了，終於小公司做大了
