Home » Devops » PUPPET PART 3: Nodes, Packages and Services.

By now, most of us agree that Puppet is the worlds greatest boon to System Admins. For those of you who still disagree, and think its possible in other scripting language, my suggestion would be to read this article with few bottles of beer.

Nodes

Node declarations in Puppet  identify a specific machine by its hostname, and explains Puppet which resources should be applied to that node. Any resources that are not part of a node declaration will be applied to all nodes. A simple example is given bellow,

node ‘slave’ {

    file { ‘/tmp/hello’:

    content => ‘Hello, Worldn’,

    }

}

Slave$ puppet apply Node_Example.pp

When you run the Puppet apply, puppet looks at the hostname of the machine (“Slave” in this case) and tries to find a node declaration that match it. And it will apply everything within the node ‘Slave’. Further articles will introduce you more about nodes.

Packages

The common type of resource you’ll manage with puppet is packages. Packages often occurs together with services and configuration files.  Puppet’s package resource will install, update, or remove a package for you, using the system native package management tools. If you were setting up a server manually, you might run a command in Ubuntu, that’s the Advanced Package Tool (APT)such as:

 Slave$ sudo apt-get install nginx

In Puppet you can give a resource declaration like,

package { ‘nginx’:

    ensure => ‘installed’ ,

}

Slave$ puppet apply Package_Example1.pp

Puppet will take the necessary actions by running the apt-get behind the screen and it have a strong impact with respect to the nodes, you can rewrite the above script like this to install the package specifically to ‘slave‘  hostname.

node ‘slave'{

    package {‘nginx’:

        ensure => ‘installed’,

    }

}

Slave$ puppet apply Package_Example2.pp

To update the installed packages,  you can change the “ensure => installed” to “ensure => latest”. To install Multiple packages on the same node

node ‘slave'{

    package { ‘screen’:    ensure => ‘installed’}

    package {‘shutter’:    ensure => ‘installed’ }

    package {‘nmap’:       ensure => ‘installed’ }

}

Slave$ puppet apply package_Example3.pp

How To Remove Packages Using Puppet?

Occasionally you need to make sure a package is removed entirely from a machine, to avoid conflicts. If you’re using the Nginx web server, for example, it’s a good idea to remove the Apache package that ships with Ubuntu by default. If Apache is running, Nginx can’t start, because Apache will grab the web server port. So to remove the apache package, here is the script

node ‘slave'{

    package { ‘apache2.2-common’:

        ensure => ‘absent’,

    }

}

Slave$ puppet apply Package_Example4.pp

Using “ensure => absent” will remove the package if it’s installed.

Services

There are certain services that should always be running and if they ever stopped, it should start again.  By setting the ensure property to “running”  puppet will check for the presence of the service on each run and restart it when it’s absent.

service { ‘lightdm’:

    ensure => ‘running’

}

Slave$ puppet apply Services_Example1.pp

To start the services on boot time in specific node, you need to ensure the service start when the host boot. In Puppet you can accomplish this by setting enable property,

node ‘slave'{

    service { ‘lightdm’:

        enable => ‘true’

    }

}

Slave$ puppet apply Services_Example2.pp

To disable the same service on boot time, you can change the ensure property to false that is ” enable => ‘false’ “. If you want to ensure a service is down and have puppet stop it whenever it discovers it running.

node ‘slave'{

    service { ‘lightdm’:

        ensure => ‘stopped’

    }

}

Slave$ puppet apply services_Example3.pp

Its obvious that the service requires a restart when its config file changes, but how to keep track of the config file changes? , Puppet allows to deploy a new config file without providing a way to restart a service to take advantage of the change. Using the “notify” metaparameter we can tell a resource to signal another resource, often a file notifying a service, and cause it to refresh, which in the case of a service causes a restart.

#Specifying The Service To Restart

service { ‘nginx’:

    ensure => ‘running’,

    enable => ‘true’,

    require => package[‘nginx’],

}

file { ‘/etc/nginx/nginx.conf’:

    notify => service [‘nginx’],

    mode => 600,

    owner => ‘root’,

    group => ‘root’,

    require => package [‘nginx’],

}

Slave$Puppet apply Service_Example4.pp

It’s good that not to use this for larger premises like DMZ because service like mysql  where a small white space change in a config file could cause a restart of your mysql database and that pull you back on other things.

This is where I have to leave you on this article, let me come up with new things in Puppet on next article, until then stay connected with puppet and leave your feedback and quires as comment.

Leave a Reply

Your email address will not be published. Required fields are marked *

CAPTCHA Image

*