我应该和木偶一起走多远？

Question

我想先说我是 puppet 的新手。我一直在通过vagrant 使用它，并且开始觉得编写清单很舒服，但我可能缺乏可以回答我的问题的经验或直觉。

我试图掌握 puppet 的作用域以及画线的位置。我对这如何应用于模块及其创建和使用特别感兴趣。

一个更具体的例子：puppletlabs-nginx 模块。因此，假设我正在愉快地进行，为给定的服务器角色创建清单；说这是一个非常简单的静态文件网络服务器，我想使用nginx。该模块显然会帮助我解决这个问题；有try_files 支持等等。我什至可以通过这个模块升级到反向代理。但是，如果事情变得更加棘手怎么办？如果我想以编程方式做一些我不能用模块做的事情怎么办？

好吧，也许简短的回答是自己修复它，提出拉取请求，然后按照我的快乐方式行事。但这在哪里停止？社区木偶模块的目标是支持给定软件包的各个方面吗？这似乎无法控制。另一方面，这不是创建了一堆完全基于用例构建的模块吗？

然后，有一个与 Android UI 类似的例子：我认为大多数 XML UI 定义都有 setter 方法。在木偶中，如果感觉相似。您可以通过编程方式构建配置文件，或者通过填写 ERB 模板来创建它。换句话说，我觉得 puppet 中的配置文件的程序化创建和配置文件的模板化创建之间的界限是模糊的；我发现 Android 没有最好的方法，所以我不知道哪个是 puppet 的方法。

那么，问题来了：什么是理想的 puppet 模块？它应该更多地依赖模板吗？在清单上？是否应该考虑所有配置场景？

从更偏僻的角度来看，我似乎想要一些更有主见的东西。 Puppet 的强大之处似乎在于灵活性和抽象性，但现有的模块感觉不一致且不够充实。

感谢阅读...

Answer 1

感谢马克。在短短的一小段时间里，我转而与 Chef 一起玩，并且模块似乎更好地解决了我表达的许多问题。

Answer 2

简而言之，我可以为你解释一下 puppet。

Puppet 只不过是一种 IT 自动化工具，我们可以通过在主机上创建清单（配方或脚本）来在其他机器上安装软件，以便将这些软件安装在目标机器上。 这里 master 表示软件的 puppet manifest 的实现。 目标机器表示要安装软件的代理。

Puppet 模块由以下结构组成，我们在 master 中执行此操作。

master中进入modules目录的路径是/etc/puppet/modules，你已经提到了puppletlabs-nginx模块。所以现在我们可以以这个模块为例。

在modules目录之后，我们要创建文件和manifests目录。此外，在manifests目录中，我们将创建.pp文件。例如，install.pp，uninstall.pp。这就是模块结构。我们通常运行这些使用包、服务、文件、exec 等少量资源编写脚本。

模板在 puppet manifests 中扮演次要角色，只是为了硬核价值观。它不是 puppet 的主要部分。manifests 在 puppet 中非常重要。

对于使用 puppet 自动化任何软件，我们可以遵循上述结构。

谢谢。

Answer 3

这里的 PuppetLabs 解决方案是为每个功能使用不同类型的模块——组件、配置文件和角色。请参阅演示文稿Designing Puppet: Roles/Profiles Pattern 了解更多信息。

PuppetForge 提供的模块属于“组件”类型。他们的目的是尽可能灵活，同时专注于单一的逻辑软件——例如，apache httpd 服务器或 apache tomcat，但不能两者兼而有之。

您可能编写的用于包装其中一个组件模块的模块类型将是“配置文件”模块的完美示例。这可以将 apache httpd 与 tomcat 和 jboss 以及其他一些组件（如 mysql 和 php）联系在一起。但它是一个逻辑堆栈，包含多个组件。或者也许你有一个 LAMP Profile 模块，以及一个单独的 tomcat+jboss Profile 模块。

下一个级别是“角色”模块。除了指向相应配置文件模块的“包含”语句之外，它们不应包含任何内容。

有关更多详细信息，请参阅 PuppetLabs 演示文稿，但此逻辑与 Chef 世界中的“包装食谱”非常相似。