Puppet: A Beginners Concept Guide (Part 1)

Someone asked me where to start with Puppet learning. I pointed them at PuppetLabs online docs for Puppet, which are actually nice for a proper understanding.

But for someone trying to start with Puppet, that documentation is a bit long to read, similar to a book.

I searched for a few blogs, but didn't find any content (short but enough, fundamentals, but usable) that I was looking for.  Here is what I've created to fill that void...
____________________________________________________

Puppet

Beginners concept guide (Part 1)

What  is it?  When  is  it  required?  (for all new guys, who came here while just browsing internet)

Puppet is an OpenSource automated configuration management framework (which means a tool that knows how to configure all machines to a deterministic state once you provide it the required set of manifests pulling the correct strings).
It has an enterprise level that is sold by an organization called PuppetLabs (http://puppetlabs.com/).

It is useful #1 when you have a helluva-lot of machines required to be configured in a similar form.
It is useful #2 when you have an infrastructure that requires the dynamic scaling-up and scaling-down of machines with a pre-determined (or at least metadata-calculated) configuration.
It is useful #3 to have control over all of your configured machines, so a centralized (master-server or repo-based) change gets propagated to all automatically.
And more scenarios come up as you require it.

_____________________________________


Hello World with Puppet
Install Ruby, Rubygems on your machine where you aim to test it.

$ gem install puppet --no-ri --no-rdoc

Download installers @Windows  @MacOSX :: & :: Docs to installing.

Checking if it's installed properly and acting good...

Now, 'puppet --version' shall give you the version of the installation.
Executing 'facter' will give you a list of System Environment related major information.

Have a quick puppet instance run.  This shall create a directory '/tmp/pup' if one doesn't exist. It creates a file '/tmp/pup/et' with 'look at me' as its content.
{If you're using a platform without the '/tmp' location. Like for Windows, change '/tmp' to 'C:/' or the equivalent}

$ puppet apply -e "file{'/tmp/pup':
                               ensure => 'directory'}
                             file{ '/tmp/pup/et':
                               ensure => 'present',
                               content => 'look at me',
                               require => File['/tmp/pup']}
                           "

_____________________________________


Dumb  usage  structure.
Create a huge manifest for your node with all resources & data mentioned in it. Then directly apply that manifest file instead of '-e "abc{.....xyz}"'.

If the example above is your entire huge configuration commandment for the node, copy all that to a file called 'mynode.pp'.
Then apply it similarly like

$ puppet apply mynode.pp

_____________________________________


How  it  evolves

Now, just as any application with pluggable library components has to be loaded and shared when required, Puppet too has a concept of modules. These modules can have manifests, files-serving and more.

Modules can be created in any design preference. Normally it works by having different modules per system component. To entertain different logical configuration states for any given system component (and also keeping it clean) further re-factoring can be done in the modules' manifest dividing it into different scopes.

Here is an example of a module for 'apache httpd'. For a very basic library, you might wanna structure your module like this

• a directory base for your module:  <MODULE_PATH>httpd/
• a directory in module to serve static files:   <MODULE_PATH>/httpd/files
• static configuration file for httpd:  
  

  <MODULE_PATH>/httpd/files/myhttpd.conf
  AccessFileName .acl

• directory to hold your manifests in module:  
  

  <MODULE_PATH>/httpd/manifests/

• a complete solution manifest:  
  

  <MODULE_PATH>/httpd/manifests/init.pp
  class httpd{
    include httpd::install
    include httpd::config
    include httpd::service
  }

• a manifest just installing httpd:   
  

  <MODULE_PATH>/httpd/manifests/install.pp
  class httpd::install {  package {'httpd': ensure => 'installed'}
  }

• a manifest just configuring httpd:  
  

  <MODULE_PATH>/httpd/manifests/config.pp
  class httpd::config{  file {'/etc/httpd/conf.d/httpd.conf':
      ensure => 'present',
      source => 'puppet:///modules/httpd/myhttpd.conf'
    }
  }

• a manifest just handling httpd service: 
  

  <MODULE_PATH>/httpd/manifests/service.pp
  class httpd::service{
    service{'httpd': ensure => 'running' }
  }

Now, using it

$ puppet apply --modulepath=<MODULE_PATH>  -e "include httpd"

would install, custom-configure and start the httpd service.

  $ puppet apply --modulepath=<MODULE_PATH>  -e "include httpd::install

"
would just install the httpd service.

Coming next... Part 2...