Puppet Definition, Installation, Configuration and Language

What is Puppet?

      Puppet is Ruby-based configuration management software, licensed as Apache 2.0, and it can run either client-server or stand-alone mode. Puppet can manage a host throughout its life cycle: from initial build and installation, to upgrade, maintenance, and finally to end-of-life, when you move service elsewhere. Puppet is designed to interact continuously with your hosts, unlike provisioning tools that build your hosts and leave them unmanaged.

     The Puppet agents connect to the Puppet master through an encrypted and authenticated connection using standard SSL, and retrieve or “pull” any configuration to be applied. Whenever there is a Puppet check, the master checks for the difference in configurations of the last Puppet check and current check. It will only apply the changes. If there are no changes between the current and last check or catalog, puppet will just ignore it.

puppet

 

Installing Puppet

Puppet can be installed on a variety of different platforms. The master must be running on  some kind of *nix systems; Windows machines can’t be masters.

#) Installing on RHEL and derivatives

1)     To enable the repository, run the command below that corresponds to your OS version:

RedHat 7

$) sudo rpm –ivh  http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm

RedHat 6

$) sudo rpm –ivh  http://yum.puppetlabs.com/puppetlabs-release-el-6.noarch.rpm

RedHat 5

$) sudo rpm –ivh  http://yum.puppetlabs.com/puppetlabs-release-el-5.noarch.rpm

2)  Install Puppet-Server on Puppet Master Server

$) yum install -y puppet-server

Note: Do not start the Puppet Master service yet

Note: if you need to upgrade to the lastest version of Puppet run the following command.

$) puppet resource package puppet-server ensure=latest

3) Install Puppet on Agent Nodes

$) yum install -y puppet

Note: Do not start Puppet service yet.

At this point, Puppet is installed, but it isn’t configured or running. So, what’s NEXT?

 

Configuring Puppet

After installing Puppet on a node that will act as a Puppet Master server, you need to get the master’s names and certificates setup, configure any necessary settings, put your puppet modules and manifests in place, configure a production-ready web server, configure load balancing and CA service routing if you’re using multiple masters, start the puppet master service.

Every settings related to puppet are kept in “/etc/puppet/ which is also called the $config directory. Every puppet install comes with a puppet.conf file which is used to set up all the puppet configurations according to your environment. Puppet.conf file has two sections: The [main] section that has settings regarding  log , ssl certificate, and run directories and [agent] section that has setting related to the agent. Puppet Master has one more section as [master] where all the settings regarding master are defined.

#) Get the Puppet Master’s Names and Certificates Setup

When you install Puppet-Server package on your master  server you make an agreement regarding the DNS names of your Puppet Master Server. If you have the hostname already configured for the server then Puppet automatically sets Puppet Server DNS names to the hostname of the server. It also includes other possible DNS names like puppet, puppetmaster etc by default. But, the setting can still be changed by going to the config file for the puppet which is at /etc/puppet/puppet.conf.

On the [main] section of the puppet.conf file  set the dns_alt_names setting to a comma-separated list of each hostname the master should be allowed to use.

dns_alt_names = puppet, puppet.example.com, puppetmaster01,

#) Start the Puppet Master service and run at startup

$) puppet resource service puppetmaster ensure=running enable=true

#) Joining Agent to the Puppet Master

On the puppet.conf file of the agent add the following entries in the [agent] section.

server = puppetmasterfqdn

listen = true

report = true

pluginsync = true

 

#) Start the puppet service on the agent and run at startup

$) puppet resource service puppet ensure=running enable=true

$) puppet agent --test

The first time start of puppet service and agent test on the agent will generate certificates for the agent which has to be signed by the Puppet Master.

#) Sign the certificates for the agent from the master

$) puppet cert list (will list all the pending certificates)

$) puppet cert sign agentfqdn

OR

$) puppet cert sign --all (if you want to sign all pending certificates)

 

#) Run Puppet Agent Test on the agent

Run puppet agent test on the agent after signing certificates from the master.

$) puppet agent --test

Now your puppet agent should be checking to the Puppet Master. Make sure both the agent and master can ping each other with their host names. To make sure your agent config is pointing to the right puppet master run the following command:

$) puppet agent --configprint server

This will output the name of the puppet master server that the agent is talking to.

To install on other systems follow the documents provided at http://puppetlabs.com

 

Puppet Language

Puppet uses Domain Specific Language (Declarative Language), the Puppet Language, to define your configuration items, which Puppet calls resources.

Everything in puppet is a resource. A resource is the minimal puppet code that can make changes in a system. A class is a collection of these resources.

A resource consists of three parts.  Type, Tile, Attribute and Value

type { title:

   attribute => value,

}

For example:

user { “test”:

   ensure => “present”,

   home => “/home/test”,

   managehome => true,

}

In this example the Type of resource is user, the Title for the resource is “test” and Attributes are ensure, home and managehome with their respective values being “present”, “/home/test” and “true”. There are lots of other attributes for the user resource. If you don’t specify them Puppet takes in the default values.

For more resource type and their attributes check the Puppet website below.

http://docs.puppetlabs.com/references/stable/type.html

Puppet files are saved as .pp extension.

 

Setting Up Puppet Environment

There are hundreds of ways on how to setup your puppet environment. It all depends on you how you want to configure puppet master, certificates, database, modules and data. But, out of those, the most common way is to setup different environments like development, production and have their respective modules. This way you can develop and test modules on one side and have a production environment running on the other side. This also give enough time for developing a dynamic modules as they go through the life cycle that involves design, testing and implementation.

The puppet $conf directory also has environments directory present where the modules are kept. When setting up the environment, the directory needs to have the environment name directory and inside the environment name directory name should be a directory that says modules that will contain modules for that environment. The directory structure is as follows:

/etc/puppet/environments/production/modules/

/etc/puppet/environments/development/modules/

The main manifest:

Inside the $conf directory there is also a directory present called manifests and inside the manifests directory the main manifest is present which is called the “site.pp”. This file must exist. It does not matter if you manage your nodes through site.pp or any other External Node Classifiers(ENC), this file must exist. In a regular environment site.pp is used to manage nodes. This is where you define which nodes gets which classes.

Concept of class

Class in puppet is nothing but a collection of resources.  For example, you could have a class to manage ntp service and that class is likely to include all resources to manage the ntp service as a whole. Classes are simply modules. Let’s assume you have a module open_ssh in development environment as such /etc/puppet/environments/development/development/modules/open_ssh, then the name of the main class must be named open_ssh because that is what the module is named as. Inside the open_ssh directory there will be few other directories like manifests that contains  .pp files, files directory that contains  any files that the code will use as a source, templates that contains .erb files that act as a template that the code can use. The file that will have the main class is always named as init.pp inside the manifests directory.

class open_ssh {

   package { 'openssh-server':

     ensure => installed,

   }

   file { '/etc/ssh/sshd_config':

     source => 'puppet:///modules/open_ssh/ sshd_config',         # this is saying pull the config file from files directory of the module open_ssh.

     owner => 'root',

     group => 'root',

     mode => '640',

     notify => Service['sshd'], # sshd will restart whenever you edit this file.

     require => Package['openssh-server'],

   }

   service { 'sshd':

     ensure => running,

     enable => true,

     hasstatus => true,

     hasrestart => true,

   }

}

 

site.pp structure

The main manifest site.pp contains the node definitions. The file is present in /etc/puppet/manifests/site.pp and the structure looks like the following.

node ‘node1.example.com’ {

     include ntp

     include open_ssh

}

node ‘node2.example.com’ {

     include apache

}

It contains a list of all the node that you want to manage in your environment. No entries are required if you use other node classifiers like puppet dashboard, foreman or any other tools to manage puppet.

 

References:

http://docs.puppetlabs.com/

Krum Spencer, Hevelingen Van William, Turnbull James and McCune Jeffrey. Pro Puppet. 2nd ed.

 

 

 

Leave a Reply