|
|
Featured White Papers
- Why choose an Open Source BPM?
- 10 FAQs on Business Process Management
- Best Practices for Getting Started with BPM
- Free Your Devs From The Pain Of Java Redeploys
- Increase Velocity 40% by Using JRebel
- What Developers Want: The End of Application Redeploys
- Developer Productivity Report: Java Tools, Tech, Devs, and Data
- Coding with JRebel: Java Forever Changed
- Utilizing Fast Testing to Transform Java Development
- Do You Really Get Classloaders?
- Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
- Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
- Coding with JRebel, Java Forever Changed
- 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data
Sponsored Links
Sponsored Links
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Review: Puppet Enterprise 3.0 pulls more strings
For the developer well-versed in Puppet, v3.0 brings welcome changes
Page 3 of 5
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.
The detail page of a specific Ubuntu server lists the groups and classes it belongs to and includes graphs of the agent runtimes and status for the past 30 days.
To apply this module to a node, we would then define a new class in the Web UI called ntp, edit a node group or a node itself, and add that class to the group or node. This will cause Puppet to apply that configuration
to the node through the Puppet agent installed on the node.
- Feedback