In this part, you’ve created a safe, risk-free learning environment you can utilize to write and test Puppet manifests. You’ve learned the following things about Puppet:
user
, group
, file
, and so on.You have learned each part of the Puppet configuration language and how to utilize it to create manifests. You’ve used Puppet to apply the manifest on your test system. puppet apply
does the following:
puppet apply
only for testing manifest changes, it can be used at broad scale if a method of synchronizing manifests to each node is available. We’ll discuss the pros and cons of this approach in Part IV.Before moving on to the next chapter, I’d like to remind you of best practices for writing Puppet manifests:
ensure
should be the first attribute in a resource block.strict_variables
configuration setting to catch errors while testing.case
and select
statements.You can find the Puppet Style Guide at https://docs.puppetlabs.com/guides/style_guide.html. All of the examples in this book have been compliant with the style guide.
To expand on what you have learned in this chapter, investigate the built-in resource types provided by Puppet. There are more than we have discussed in this chapter, and you’ll find many of them immediately useful. Here are just a few we didn’t mention previously:
augeas |
A programatic API for managing configuration files |
cron |
Cron scheduler entries |
host |
Host file entries |
interface |
Networking |
mailalias |
Mail aliases |
mount |
Filesystem mount points |
nagios_* |
Types to manage Nagios host, service, contact entries |
router |
Manages a connected router |
sshkey |
SSH key management |
yumrepo |
Package repository |
The complete list of built-in resource types can be found at “Resource Type Reference” on the Puppet docs site.