pg宝石传奇作弊软件怎么用

書名： Puppet 3 Cookbook
作者名： John Arundel
本章字數： 530字
更新時間： 2021-04-09 23:52:27

Using standard naming conventions

Choosing appropriate and informative names for your modules and classes will be a big help when it comes to maintaining your code. This is even truer if other people need to read and work on your manifests.

How to do it…

Here are some tips on how to name things in your manifests:

Name modules after the software or service they manage, for example, apache or haproxy.
Name classes within modules after the function or service they provide to the module, for example, apache::vhosts or rails::dependencies.
If a class within a module disables the service provided by that module, name it disabled. For example, a class which disables Apache should be named apache::disabled.

If a node provides multiple services, have the node definition include one module or class named for each service, for example:

node 'server014' inherits 'server' {
  include puppet::server
  include mail::server
  include repo::gem
  include repo::apt
  include zabbix
}

The module that manages users should be named user.
Within the user module, declare your virtual users within the class user::virtual (for more about virtual users and other resources, see the Using virtual resources section in Chapter 5, Users and virtual resources).
Within the user module, subclasses for particular groups of users should be named after the group, for example, user::sysadmins or user::contractors.
Where you need to override a class for some specific node or service, inherit that class and prefix the name of the subclass with the node, for example, if your node cartman needs a special SSH configuration, and you want to override the ssh class, perform the function as follows:
```
class cartman_ssh inherits ssh {
  [ override config here ]
}
```
When using Puppet to deploy the config files for different services, name the file after the service, but with a suffix indicating what kind of file it is, for example:
- Apache init script: apache.init
- Logrotate config snippet for Rails: rails.logrotate
- Nginx vhost file for mywizzoapp: mywizzoapp.vhost.nginx
- MySQL config for standalone server: standalone.mysql
If you need to deploy a different version of a file depending on the operating system release, for example, you can use a naming convention like this one:
```
memcached.lucid.conf
memcached.precise.conf
```

You can have Puppet automatically select the appropriate version with:

source = > "puppet:///modules/memcached
  /memcached.${::lsbdistrelease}.conf",

If you need to manage, for example, different Ruby versions, name the class after the version it is responsible for, for example, ruby192 or ruby186.

There's more…

The Puppet community maintains a set of best practice guidelines for your Puppet infrastructure which includes some hints on naming conventions:

http://docs.puppetlabs.com/guides/best_practices.html

Some people prefer to include multiple classes on a node by using a comma-separated list, rather than separate include statements, for example:

node 'server014' inherits 'server' {
  include mail::server, repo::gem, repo::apt, zabbix
}

This is a matter of style, but I prefer to use separate include statements, one to a line, because it makes it easier to copy and move around class inclusions between nodes, without having to tidy up the commas and indentation every time.

I mentioned inheritance in a couple of the preceding examples; if you're not sure what this is, don't worry, I'll explain this in detail in the next chapter.

官术网_书友最值得收藏!

Puppet 3 Cookbook

Using standard naming conventions

How to do it…

There's more…