Over a million developers have joined DZone.

Puppet: A Beginners Concept Guide (Part 1)

· DevOps Zone

Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs

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

Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.


Published at DZone with permission of Abhishek Kumar, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}