Here is puppet your configuration manager

A group of computers in a network is called a cluster. In many organisations, you will find the server being set up in a cluster so that if one machine fails, the process goes on. Even in Hadoop, the data is scattered over the cluster. Maintenance of these clusters is a cumbersome job for the administrator and developers. For example, let’s assume that in a cluster of 1000 nodes (nodes refer to physical machines), there is a software update that needs to be applied on all the machines. Now, if you don’t have a configuration management system, then you have to manually install the software on all the machines. This is really tiring when you have many software updates or configuration changes on a frequent basis.
To ease the job, configuration management systems were created and Puppet is one of them. It allows us to define the state of our IT infrastructure, and then automatically enforces the desired state. Puppet automates every step of the software delivery process, from provisioning of physical and virtual machines to orchestration and reporting; from early-stage code development through testing, production release and updates. Puppet has two solutions – one for configuration management and the other for data centre automation. In this article, we will look at its configuration management feature.
Puppet works in a master-slave design, where all the required configuration is done on the master and is reflected in all the slaves on a regular basis. The slave machine syncs up with the master every 30 minutes to reflect the configuration of the master. I will tell you how to: a) Install the latest version of Ruby; b) Install and configure a central Puppet master server; c) Install and configure a Puppet agent node; d) Sign the agent’s SSL certificate request on the master, and finally; e) Execute a simple test with Puppet.
Ruby is one of the basic requirements for installing and configuring the Puppet agent/master set-up. So let’s install it in on both master and slave. Use one of the following versions of MRI (standard) Ruby: 2.1.x, 2.0.x, 1.9.3 or 1.8.7.

Steps for installing Ruby
1. We first need to install all the required packages for Ruby installation on our system using the following commands:

yum install gcc-c++ patch readline readline-devel zlib zlib-devel
yum install libyaml-devel libffi-devel openssl-devel make
yum install bzip2 autoconf automake libtool bison iconv-devel

2. Download the latest Ruby source file using the following link: https://www.ruby-lang.org/en/downloads/

3. Extract the source file using the commands given below:

gunzip <sourcefile.tar.gz>
tar –xvf <sourcefile.tar>

To configure and install Ruby 2, type:

cd <sourcefile>
./configure
Make
make install

4. Now that the latest version of Ruby has been installed successfully in our server, we can verify the installed Ruby version by executing the command given below:

ruby –v

After Ruby is installed on the master and slave, let’s configure Puppet on the master. The newest version of Puppet can be installed from the yum.puppetlabs.com package repository. To enable the repository, run any one of the following commands that correspond to your OS version.
For, Enterprise Linux 7, type:

$ rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm

For Enterprise Linux 6, type:

$ rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-el-6.noarch.rpm

For Enterprise Linux 5, type:

$ rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-el-5.noarch.rpm

Now run the command below which will install the Puppet master:

yum install puppet-server

Don’t start the Puppet master service now. For now, delete any existing SSL certificates that were created during the package installation using the following command:

rm -rf /var/lib/puppet/ssl

Edit the master’s puppet.conf file with the following content:

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter

[master]

These are needed when the Puppetmaster is run by passenger and can safely be removed if WEBrick is used.

ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

Now include the DNS name at which agent nodes can contact the master. Update the master’s puppet.conf [main] section with the following two lines:

Surname = puppet
dns_alt_names = puppet,<Puppet Master’s Hostname or FQDN>

Create the CA certificate by running the following command:

puppet master --verbose --no-daemonize

Verify the certificate information that was just created with the following command:

puppet cert list -all

Now create the manifest file of Puppet master touch, /etc/puppet/manifests/site.pp. After all this, start the Puppet master service with the following command:

/etc/init.d/puppetmaster start

Once Puppet is installed on the master, let’s move on and customise it on the Puppet slave. Ruby must be installed on the slave now; so copy the repository package from the Puppet master server and enable the repository with the following command:

rpm -ivh puppetlabs-release-el-6.noarch.rpm

Now type yum install puppet to install the Puppet agent. After doing this, update the puppet.conf [agent] with the following line in quotes: “server = <Puppet Master’s Hostname or FQDN>”. Now start the Puppet agent service using the following command:

$ /etc/init.d/puppet start.

After successfully installing the Puppet on the master and client, we have to sign the SSL certificate on the master. The first time Puppet runs on an agent node, it will send a certificate-signing request to the Puppet master. Before the master is able to communicate and control the agent node, it must sign that particular agent node’s certificate. On the Puppet master, run the following command to list all unsigned certificate requests:

$ puppet cert list
+ “<Agent’s Hostname or FGDN>” (SHA256) 21:EF:ED:81:95:F0:ED:6D:A5:1D:05:48:C9:01:5D:A6:FE:0C:FB:A4:89:FF:45:CF:26:53:1C:BB:1F:6D:1E:CC

On the Puppet master, run the command given below to sign the agent’s certificate request:

$ puppet cert sign <Agent’s Hostname or FGDN>

The Puppet master can now communicate and control the agent to which the signed certificate belongs. Now that everything is up and running, let’s execute a simple test with Puppet. In the manifest file of the master, write some code to show the IP address.
Edit the main manifest file (/etc/puppet/manifests/site.pp) on the Puppet master with the following content, and then save it:

file {‘/tmp/example-ip’, # resource type file and filename
ensure => present, # make sure it exists
mode => 0644, # file permissions
content => “Here is my Public IP Address: ${ipaddress_eth0}.\n”,  # note the ipaddress_eth0 fact
}

The Puppet agent periodically checks in with the Puppet master (typically every 30 minutes). It is also possible to initiate the check for a particular agent node manually, by running the following command (on the agent node):

$ puppet agent –test

Then run the following command to print the file:

$ cat /tmp/example-ip

The output looks like what’s shown below (with that node’s IP address):

Here is my Public IP Address: 10.81.89.101.

Thus we can configure the master and this configuration will be reflected in slave nodes. The benefits of this tool are:
a) It frees up time to work on projects that deliver more business value.
b) It ensures consistency, reliability and stability.
c) It facilitates closer collaboration between sysadmins and developers, enabling more efficient delivery of clean code that delivers real business value.