Puppet踏上容器之旅，全面支持Kubernetes

一年的時間足以滄海桑田，物是人非了，即使對企業也同樣如此。

今年二月，Puppet Labs公司CEO Luke Kanies曾經在接受采訪時表示，他認為Docker在企業環境下的快速普及基本上只是一種幻覺。“沒有哪種技術能夠在企業當中擁有如此迅猛的傳播速度。我根本不在乎它到底有多出色，”Kanies指出。“大家不可能突然之間就把成百上千萬種生產環境下的工作負載遷移到采用完全不同于以往的軟件包、運行時以及其它組件的虛擬化層當中。”

而就在不到一年之后，Puppet Labs發現自身已經處于非常尷尬的境地——其開始著手將工具轉移至容器化環境當中。就在上周三，Puppet公司公布了一套面向Kubernetes的功能模塊，其能夠幫助這套編排環境接受Puppet代碼的管理。

程序員眼中的Puppet

行業普遍認為Puppet是系統管理員的一套自動化工具，主要用于配置管理工作。而Chef與Puppet功能大致相同，但Chef是面向開發人員的。就在今年早些時候，由VB Insight發布的一份報告對此表示懷疑，它認為二者的本質差異在于Chef允許開發人員實現一系列實驗性嘗試，但Puppet能夠最大力度避免管理員犯錯。

Puppet Labs的英國高級軟件開發人員Gareth Rushgrove作為本次Kubernetes支持項目中的關鍵性角色，當然也非常熟稔關于配置自動化的各類議題。他的主要工作就是切實讓Puppet 成為足以吸引開發人員的選項。他解釋稱，“這是一款編程語言——而且這種定位如今正變得愈發穩固，特別是相較于幾年之前。”

Rushgrove同時提到，過去幾年以來，Puppet已經吸納了一系列開發人員，它希望在一款編程語言中獲得的各類不同水平的工具與支持能力。“我認為區別在于，這是一種聲明性語言而非通用語言，但大家仍然能夠利用它完成既定任務——因為它非常強大，”他強調稱。

市面上確實存在著不少聲明性編程語言，因此Puppet的聲明語義應該足以讓其成為其中的一員。Rushgrove解釋稱，聲明語義能夠幫助操作者（當然，大家也可以根據自己的理解將其稱為‘開發者’）聲明必要的系統狀態，從而實現對容器平臺的支持。以此為基礎，這款插件將在后端實現對 Kubernetes的配置管理。

“配置管理并不僅僅在于對磁盤上的資源及文件進行管理；它的核心作用在于隨時間推移實現高水平管理效果，”Rushgrove指出。“我們的客戶及用戶往往來自大型企業，他們對于流程更感興趣。我們目前的努力方向在于打造相關工具，從而幫助他們在獲得控制能力的同時擺脫手動操作的束縛，即無需對此類流程進行手動管理。”

在大型企業當中，他表示，這些流程包括服務管理與配置管理等隨時間逐漸演變的任務，而且通常會呈現出非常混亂的運作態勢。Puppet致力于了解這些流程的實際價值，他認為這將能夠帶來“難以獲得的智慧”。

不過除了自有設備，這部分企業還需要處理一系列其它流程，包括不同轉換、簽名以及員工間的任務移交等——這些傳輸工作能夠自動完成，但卻無法帶來任何積極效果。這種傳輸方式在固定線路當中僅僅表現為效率低下，但在容器編排環境中則會帶來更大的麻煩。這時我們需要利用安全控制機制幫助企業維護各流程的歸屬權與驗證機制，同時確保其中不摻雜任何人為因素。

非管理員眼中的Kubernetes

“在我們眼中，Puppet總體而言并不屬于那種由管理員編寫代碼以實現原本需要手動完成操作的簡單工具，”Rushgrove指出，“因為它屬于編程語言，所以大家可以將其作為中介，使得個人之外的各團隊與部門也能夠與之交互。大家應該逐步擺脫將系統管理員作為個人看待的固有印象……利用這種中介機制，大家可以從軟件開發實踐當中提取成果——例如持續集成、單元測試以及代碼審查等等。另外，大家也可以建立自己的一套共享模式，并在模式描述當中引入職責分擔這一設計思路。”

這套模式能夠反映出系統隨時間推移的演變情況——而非單純只是一套最佳但卻固定的平臺，其中應當包含特定狀態可能帶來的預期變化。這一切都能夠在 Puppet當中完成（相信管理員已經了解到這一點），因為其會將這些狀態以動態變量的形式進行聲明。在新的Kubernetes平臺之上，此類變更隨后會被自動提出并逐步納入平臺當中。

值得強調的是，我們在自己的說明文檔當中將Kubernetes描述為一套按需狀態系統。“Kubernetes能夠根據用戶提供的需求狀態請求建立起強大的聲明基礎。其擁有多種自我修復機制，具體包括自動重啟、重新調度以及同時面向主動控制器及必要編排流程的容器復制等能力。”

Gareth Rushgrove認為，Kubernetes的強大之處恰恰體現在這些基礎當中。在上周三發布的一篇官方博文當中，他表示Kubernetes對于配置任務的處理能力并不會令配置管理方案走向消亡。

“有些人將配置管理（以及Puppet等工具）單純視為一種實現主機相關資源的管理方式，包括文件、服務、軟件包、用戶或者群組，”Rushgrove寫道。“Kubernetes引入了更為高級的基礎元素，例如Pod與副本控制器，旨在以更為簡便的方式實現分布式與可擴展系統的管理。如此一來，大家將不再需要通過引入新的基礎元素進行配置管理。然而，配置管理是一項涵蓋范疇極廣的學科，其歷史能夠追溯到上世紀五十年代。”

他還列舉了一段Puppet代碼示例，其中使用了YAML，其中結合了同樣使用YAML的Kubernetes代碼元素。通過這種方式，任何熟悉 Kubernetes API的用戶都不需要學習新的技能以運用這些基礎元素——換言之，他們將能夠輕松上手Puppet代碼。“因此大家對Kubernetes越是了解，”Rushgrove告訴我們，“大家就越能夠輕松使用這套模塊。”

更重要的是，他認為負責實現Kubernetes自動化的Puppet腳本也可以被不同類型的用戶所使用——例如那些對Kubernetes并不熟悉，但卻希望借此處理臨時性業務難題的用戶。在這方面，Rushgrove提供了典型的Kubernetes示例——其能夠生成一款簡單的服務器負載均衡Web應用，并被重新編譯為Puppet代碼，這也證明了其中所涉及的編程語法實際非常有限。

通過對這款應用的簡單演示，他解釋稱這部分潛在用戶也完全能夠實現自己需要的簡單調整——例如控制副本控制器中的容器數量，而完全不必勞煩專業用戶幫忙完成。“這意味著同一團隊中的不同成員即使并非全部具備相關專業知識，也同樣能夠使用Kubernetes上的大型應用。他們只需要使用開發人員創造的界面，并在業務層面上進行操作即可。”

原文鏈接：Puppet Labs Automates Kubernetes for DevOps

來自：http://dockone.io/article/923