Does each file need to be copied within a separate resource - file

Question

I'm still getting to grips with puppet (feels like I'm drinking from a hose pipe at times) so I've attempted to keep my configuration and environment simple initially. I've started by having puppet deploy files to my clients. However, I get the feeling that the way I'm deploying the files isn't the most efficient way of doing so. For every file, I'm specifying like this:
file { "/etc/ntp.conf":
owner => 'root',
group => 'root',
mode => '0444',
source => 'puppet://basxtststinfl01/files/etc/ntp.conf',
}
file { "/etc/snmp/snmpd.conf":
owner => 'root',
group => 'root',
mode => '0644',
source => 'puppet://basxtststinfl01/files/etc/snmpd.conf',
}
I have up 15 files I'd like to deploy. Is this the correct approach?
Thanks.

Answer 1

File in modules is a good keyword.
Generally, to solve the problem of repetitive resource, you can wrap them in a defined type.
define deployed_file($ensure = 'present',
$owner = 'root',
$group = 'root',
$mode = '644',
$recurse = '') {
if $recurse != '' { File { recurse => $recurse } }
file {
$name:
ensure => $ensure,
owner => $owner,
group => $group,
source => "puppet://basxtststinfl01/files${name}",
}
}
Your resources from above can then be written as:
deployed_file {
'/etc/ntp.conf':
mode => '444';
'/etc/snmp/snmpd.conf':
}
You can add more parameters to make the URL customizable.
Note that I added the recurse parameter for posterity. file has lots of attributes, and if you need for the deployed_file to support them, you should add them in this manner, so that they get passed to the wrapped file if specified, but ignored otherwise.

Answer 2

I suppose the question of whether this is the ‘correct approach’ comes down to what you’re doing exactly, but since ‘it depends’ is sometimes an annoying thing to hear, theres a few general points that can be made ...
This is an approach that will work - it would deploy the 15 or so files that you have declared exactly as you specify them.
It does however come at the expense of requiring the exact maintenance of your files as they are written in basxtststinfl01
Since these are static files, you might find it restrictive if you come to running puppet code to provision many different servers.
So to options! The examples you have given there can be considered from the context of puppet modules - reusable code to configure a particular service or logical unit of your system
In your ntp case, there is an ntp puppet labs module which contains logic within it to create an ntp.conf file and takes variables as parameters to configure it. This shortens the puppet declaration and allows you to reuse it for provisioning more servers. An example of how to configure this is given in the documentation of the puppetlabs-ntp module.
class { '::ntp':
servers => [ 'ntp1.corp.com', 'ntp2.corp.com' ],
}
More often that not, someone has written a module that will provision a part of the system that you want, see the Puppet Forge
Decomposing your system requirements into units and using modules means you can specify your config files dynamically according to variables that might vary from system to system.
Best thing to do is work through the excellent documentation on the puppetlabs website:
Some resources:
Learning Puppet (you may already have seen)
Basics of modules