Sunday, November 30, 2014

From DevOps to Puppet Part 2

In part 1, we have looked at DevOps, Configuration Management Tools and a little bit of Puppet.  In this post we will continue to look into other aspect of Puppet.

Declarative vs Imperative
One important thing to know about Puppet is that it is a Declarative Language.  What it means is that user only specify the end state of the system that it is trying to configure.  User does not need to know the system specific.  A Puppet manifest can be applied n number of times and if the end state is already in the desire state, nothing will happen.

Another equally popular Configuration Management Tool - Chef, however, is an imperative language where user write out how to achieve the end result.

Puppet Terminology
Puppet looks at everything as a resource where each resource describes some aspect of a system
  • The block of Puppet code that describes a resource is called a Resource Declaration.
  • Each resource has a type, a title and a set of attributes
Example of a resource will be
  • Linux package such as MongoDB
  • Files
  • Users on a system
  • Services such as /etc/host entries; network interface or Windows registers
Example of a resource declaration:
As we can see there are 3 "file" type but the title and attributes are different.  The first example creates a file /tmp/test1 with content "Hi'.  The second one creates a file /tmp/test2 and the security mode is set to 0644 and the third example creates a symlink /tmp/test3 which links to the file /tmp/test1

As mentioned before Puppet is a declarative language.  If the file /tmp/test1 already existed and with content "Hi", nothing will happen even if user execute the manifest 100 times because the desired end state is reached.

There are built-in types for Puppet:

image source:

If you do not find what you need from the built-in types, take a look a the Puppet Forge and chances are someone else had already did the job for you and had developed a type that you can use or similar to what your needs are.

A Puppet Manifest is a Puppet program with the .pp file extension that contains the resource declaration.These are some of the operation/command that we can have on a Puppet Manifest:

puppet parser validate configWebSrv.pp

puppet apply –-noop configWebSrv.pp

puppet apply configWebSrv.pp

puppet-lint configWebSrv.pp

The "noop" parameter is a very useful command where we can test out the manifest without actually performing the action and Puppet will respond with what is the outcome when this manifest is executed.

Puppet can operate on a standalone device or it can operate on a "Master and Agent" model where the Puppet agent will pull from the Puppet Master on a regular interval.  The default pulling interval is 30 minutes. For emergency application of new configuration, user can trigger the pulling and I believe Puppet Enterprise has the option to trigger the pulling on the console.

Manifest is complied into catalog which is in the format that the Puppet Agent understand.  Puppet will configure the resource according to the content of the catalog to the desired system state.

In a standalone model it works this way:
 image source:

In a "Master and Agent" model, the manifests are stored in the Puppet Master and periodically, the agent will poll from the Puppet Master if there is any configuration changes.  If necessary, we can trigger the poll manually instead of waiting for the next poll interval.
image source:

The difference between a standalone and "Master and Agent" model is how the manifests are store and where the catalog is complied.

Currently under preview is the Puppet Server.  This is to replace the Puppet Master and is to have many advantages in this new model because of a complete re-design.

May be in Part 3 we can look into this new Puppet Server.


  1. Good Post! Thank you so much for sharing this pretty post, it was so good to read and useful to improve my knowledge as updated one, keep blogging…
    Devops Online Training

  2. very informative post you have been shared. really nice blog. before i read this blog i didn't have any knowledge about this but now i got some knowledge about keep on sharing such kind of an interesting blogs.
    Devops Training in Bangalore

  3. Hello Admin,
    I really enjoyed while reading your article, the information you have mentioned in this post was damn good. Keep sharing your blog with updated and useful information.
    Devops Training in Chennai

  4. The great service in this blog and the nice technology is visible in this blog. I am really very happy for the nice approach is visible in this blog and thank you very much for using the nice technology in this blog

    Devops Training in Marathahalli|
    Devops Training in Bangalore|

  5. Hello Admin,
    I really enjoyed while reading your article, the information you have mentioned in this post was damn good. Keep sharing your blog with updated and useful information.

    Devops Training in Chennai

  6. nice blog. thanks for sharing Devops Tutorials. It’s really Helpful for me.

  7. At devops training online, we're fixated on making an incentive for the associations who believe us as the single hotspot for the learning.

  8. Needed to compose you a very little word to thank you yet again regarding the nice suggestions you’ve contributed here"Oracle Training in Chennai".