While it’s actually a beginners Puppet topic, you can test all Puppet resources at the CLI, without writing a manifest or a module. There are things you can’t (or at least: not easily) test solely via the CLI, but for the basics you can just jump in.
And for anyone who self-taught himself Puppet, this may not be known. Or at least, not often used – but it’s a really powerful feature in Puppet.
Retrieving Puppet Resources
For instance, on a running machine you can get a list of all the services that are available and retrieve them as Puppet Resources.
$ puppet resource service
service { 'atd':
ensure => 'running',
enable => 'true',
}
...
And you can get any Puppet resource this way. Think of hosts, packages, users, groups, … In fact, it’s a great way to make a server inventory and get the Puppet-code auto generated for you.
$ puppet resource user zabbix
user { 'zabbix':
ensure => 'present',
comment => 'Zabbix Monitoring System',
...
}
The syntax is easy: puppet resource $type $name. The $name is optional, if it’s omitted it’ll show all values of the resource type $type.
Testing and Setting Puppet Resource Values at the CLI
You can modify the resources in the same way as they are retrieved, by adding Puppet parameters to them.
$ puppet resource user varnish gid='495'
user { 'varnish':
ensure => 'present',
gid => '495',
}
It’s a useful to test if a parameter you want to set is valid, or not. And it’s usually a lot faster than a vagrant provision.
Just keep in mind that parameter=value pairs cannot have spaces between them, so parameter = value would trigger a CLI error. For string values, enclose them in single quotes.
$ puppet resource user varnish comment='Super Fast Varnsish Cache'
user { 'varnish':
ensure => 'present',
comment => 'Super Fast Varnsish Cache',
}
You can’t test variable inheritance/scoping this way, but it’s a quick way to test the basic parameters of the available resources.