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

2015-12-28 17:10:55

云计算 行业普遍认为Puppet是系统管理员的一套自动化工具，主要用于配置管理工作。就在上周三，Puppet公司公布了一套面向Kubernetes的功能模块，其能够帮助这套编排环境接受Puppet代码的管理。

一年的时间足以沧海桑田，物是人非了，即使对企业也同样如此。

今年二月，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上的大型应用。他们只需要使用开发人员创造的界面，并在业务层面上进行操作即可。”

原文链接：http://dockone.io/article/923