我刚刚开始使用 Puppet。示例演练和教程很好地帮助我理解 Puppet 的实用性和基本工具集，但我很难概念化完整的堆栈。即使是高级教程似乎也没有让我清楚地了解需要发生什么。
有没有我可以学习的 Rails 堆栈的完整示例？
I'm just getting started with Puppet. The example walkthroughs and tutorials were good at helping me understand Puppet's usefulness and the basic toolset, but I'm having a hard time conceptualizing a full stack. Even the advanced tutorial didn't seem to give me a clear picture of what needs to happen.
Are there any full examples of a rails stack somewhere that I could learn from?
发布评论
评论（1）
完整堆栈的例子很难找到。但是，您应该能够找到管理其中一些特定示例的模块示例。一个问题是，创建一个抽象出所有特定于站点的假设并且真正跨平台的模块可能需要大量额外的工作。
http://forge.puppetlabs.com/ 是人们希望共享的模块的规范位置。通过快速扫描，我找到了 nginx、清漆 和 postgres >。
您需要从Puppet 最佳实践开始进行基本设置。
从那里，您将（至少）需要一个用于 nginx、varnish、thin、postgres、memcached、redis 的模块和一个站点模块（可能以您的站点命名）。
在您的nodes.pp 中，每个系统都会有一个相当简单的角色分配。 （“包含角色”）
在您的“站点”模块中，您需要为每个系统角色都有一个子类（我假设您将拥有多组服务器，并且在一组服务器中，它们旨在我还假设您可能包含以上其中一项以上）。您可能还需要一个 site::commonvariables 类（或类似的东西）来存储您在多个其他模块或类中可能需要的内容（例如角色中的服务器列表、密码等）。最佳实践似乎将这些 site::role 内容放在 /services 辅助模块区域中，其名称更像 s_role，因此您可能需要遵循该命名/放置方案。这些角色类将包括这些角色所需的实际组件的类、调用定义等。
对于您提到的 6 个组件中的每一个，您都将有一个模块。在该模块中，您可能想要拥有诸如“服务器”和“客户端”子类之类的东西。客户端和服务器可能包含第三个类，用于两者所需的东西（公共库等）。在服务器子类中，定义了设置特定实例（虚拟主机、数据库等）的定义。 （如果它绝对只是一个服务器，也许可以跳过该级别的子类化）。
例如：
最好让组件模块保持相当独立（并且可重用），并且您的角色类是所有特定于站点的配置发生的地方，但如果您的组件模块包含一些特定于站点的内容，那也不是世界末日。
Examples of a full stack are hard to come by. You should be able to find examples of modules that manage some of those specific examples, however. One problem is that it can be a lot of extra work to create a module that has abstracted away all site-specific assumptions and that is truly cross-platform.
http://forge.puppetlabs.com/ is the canonical location for modules that people wish to share. With a quick scan I found modules for nginx, varnish, and postgres.
You'll want to start with the Puppet Best Practices for the basic setup.
From there, you're going to (at least), want a module for nginx, varnish, thin, postgres, memcached, redis, and a site module (probably named after your site).
In your nodes.pp, each system will have a fairly simple assignment to a role. ("include role")
In your "site" module, you'll want a sub-class for each system role (I'm assuming you'll have multiple sets of servers, and that within a set, they are intended to be basically identical to each other. I'm also assuming that you're likely to have more than one of the above included). You may also want a site::commonvariables class (or something like that) for things (such as lists of servers in a role, passwords, etc) that you may need across multiple other modules or classes. The best practices seem to have these site::role things in a /services secondary module area with names more like s_role, so you may want to follow that naming/placement scheme instead. These role classes will include the classes for the actual components that are needed on those roles, call defines, etc.
For each of the 6 components you mention, you'll have a module. Within that module, you're likely to want to have something like a "server" and "client" subclass. And possibly a third class included by client and server for things needed by both (common libraries, etc). And within the server subclass, a define that sets up specific instances (virtualhosts, databases, etc). (if it's absolutely only ever a server, maybe skip that level of subclassing).
So, for example:
It's best if the component modules are kept fairly independent (and reusable) and your role classes is where all the more site-specific configuration happens, but it's not the end of the world if your component modules include some site-specific stuff.