Over a million developers have joined DZone.

Puppet: A Beginners Concept Guide (Part 1)

DZone's Guide to

Puppet: A Beginners Concept Guide (Part 1)

· DevOps Zone ·
Free Resource

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

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...


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:  
    AccessFileName .acl
  • directory to hold your manifests in module:  
  • a complete solution manifest:  
    class httpd{
      include httpd::install
      include httpd::config
      include httpd::service
  • a manifest just installing httpd:   
    class httpd::install {  package {'httpd': ensure => 'installed'}
  • a manifest just configuring httpd:  
    class httpd::config{  file {'/etc/httpd/conf.d/httpd.conf':
        ensure => 'present',
        source => 'puppet:///modules/httpd/myhttpd.conf'
  • a manifest just handling httpd service: 
    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...

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}