Review: Puppet 3.0 pulls more strings
Version 3.0 of Puppet Labs' configuration automation tool shines with speed boosts, orchestration improvements, and deeper support for Windows servers
By Paul Venezia
Senior Contributing Editor, InfoWorld |
These quibbles and pitfalls aside, the initial configuration is very straightforward, requiring DNS for all nodes and (obviously) clear network connectivity. Once the Puppet Master is installed, each node is configured essentially the same way, by running an installer for that node's platform, which generates a certificate and contacts the master server for approval. When the node is approved, it becomes configurable through Puppet and can be added to groups or bound to classes through the Web UI or CLI.
Then comes the harder part: configuring Puppet to make changes to those systems. This is done through modules, either custom-coded or downloaded from the Puppet Forge site and customized.
Puppet in action
As a very simple example of how Puppet works, let's look at how we would use Puppet to make sure that the NTP (Network Time Protocol) service is properly configured and running on a selection of nodes.
Assuming we already have the nodes approved, we need to download a module, such as the third-party erwbgy-ntp module, written by Keith Burdis. We do this by installing the module from the command line:
puppet module install erwbgy-ntp
This downloads the module and places it under /etc/puppetlabs/puppet/modules/ntp. We then take a look at the file /etc/puppetlabs/puppet/modules/ntp/manifests/init.pp. It contains a number of configuration options for the module. For this example, we only need to modify the NTP server we want to use, so we modify the $servers variable:
$servers = [ '192.168.32.10', '192.168.16.10' ],
This will cause the module to add those two servers to the ntp.conf file. The init.pp file includes the services.pp file, which reads thus:
class ntp::service {
service { 'ntpd':
ensure => running,
hasstatus => true,
hasrestart => true,
enable => true,
require => Class['ntp::config'],
}
}
This defines a subclass to handle the ntpd service itself. These variables control whether or not Puppet ensures that the service is running and enabled.
Another included file called install.pp handles package installations:
class ntp::install {
case $::operatingsystem {
'RedHat', 'CentOS', 'OracleLinux': {
if ! defined(Package['ntp']) {
package { 'ntp': ensure => installed }
}
if versioncmp($::operatingsystemrelease, '6.0') > 0 {
if ! defined(Package['ntpdate']) {
package { 'ntpdate': ensure => installed }
}
}
}
default: {
fail('Currently only works on RedHat-like systems')
}
}
}
This code checks to make sure it's running on a compatible distribution (Red Hat, CentOS, or Oracle Linux in this case), and if it is, will cause the ntp package to be installed. It will also check to make sure that ntpdate is installed if required. Otherwise, an error will be thrown.
Taken all together, when applied to a target node, this module will install the ntp package if it's not already installed, will add lines to the configuration file to define NTP servers as 192.168.32.10 and 192.168.16.10, and will start the ntpd service if it's not already running.
