Salutations

First of all, hello from sunny and hot New York. I’m on engagement for my company doing some Puppet goodness in the Northeast.

In my downtime at night, Ive been wrapping up some work I’ve had on my plate for awhile (my Puppet module destined for the Puppet Forge) and generally studying for various topics if for no other reason than to get better.

As I was preparing my new module, Puppet releases the Puppet4 Enterprise release that now follows new semantic versioning schemes, and follows the scheme:

Puppet Enterprise YYYY.VV

where “V” is version number.

Puppet Enterprise

As many of you know, I’ve been maintaining a project for Puppet prototyping and working with development and testing over a Vagrant instance for some time. I created what I have because I needed something I could share with customers to help facilitate coding and iteration without their touching the production instance unless absolutely necessary.

Thus, my projects were born.

Vagrants. Vagrants Everywhere.

In a nutshell, I configure a Vagrant environment on a modern OS. I create 4 nodes. One is the Puppet Master itself and the remaining three are Puppet agents that check in with the master and are in three faux envirnments: “Production”, “Testing”, and “Development”. As a result, you can code for DEV and iterate the heck out of it. Once you like it, you can merge up the tree into testing and finally to production.

These releases have been followng the format:

[OSNAME]|[VERSION NUMBER]-[PUPPET][PUPPETVERSION]

So, for instance, a release for CentOS5 running Puppet Open Source 4.0 would look something like this:

centos5-po4

Make sense?

Well, as of today, my new release will be CentOS7 with Puppet Enterprise 2015.2. It can be found here.

Puppet Forge Module

I’ve also been working on two separate modules for the forge here recently. The other I’ve been working on longer, but this one was just ready first. I call it “PuppetDev”.

The idea behind the PuppetDev module is that sometimes a company who needs to do Puppet Development has corporate policy against using a tool like the Vagrant instances (i.e. virtualization on the desktop) mentioned above. As a result, the company often will set up a centralized development host that people can login to for developing Puppet code.

Often times, though, when starting out, a user can feel overwhelmed at the simple command line in front of them, and even if they get into an editor, they may not know where to start with syntax highlighting and the like.

It was from this need PuppetDev was born. You simply apply the module to a node, and supply the user/group you want to apply the module to as parameters, and it whirls away and sets up their development environment.

Among the toys they get with the release are syntax highlighting, an easier to read colorscheme, a Vim plugin infrastructure, and all manageable by the Puppet Administrator for the site.

I know it’s a rather narrow use case, but there it is… feel free to check it out here, or if you’re so inclined, on your Puppet master you can simply run puppet module install cvquesty/puppetdev.

That’s all I have for this update, but hope to be a little more active here shortly with my next Forge module.