New Puppet Series!

I’m back! Things are changing! Woo-hoo!

In the past, I’ve really only written about writing on this blog. That is,
aside from a few rants early on. Now, though, I’d like to do a series on
something that I’ve recently become passionate about. Puppetlab’s horrible
documentation for Puppet.

To preface this series, I should say that I’ve been working as a sysadmin/
engineer for the past ten years. I’ve done Windows Server support, VoIP,
Linux desktop, Linux server, so on and so forth. Mostly, I’m just trying
to say that I’m not a writer trying to break into tech topics. That said,
Puppet is still pretty new to me. The process of learning what I know now
was extremely painful, and I want to put together a quick series that has
the potential to help folks who stumble upon it.

My goal is to have enough information in one place, and in a clear enough
format, that you can go from nothing to having a nice little environment
put together using roles and profiles. I want to show examples of things
I have learned on my own, from colleagues, and from a bit of formal
training. I’ll walk through building a control repo with profiles that
manage a good variety of basic Linux resources. It’s going to be fun!

Where are we going to start? With the simple things that took me way
too long to find online, like Hiera data. Even after the practitioner
course, I was still a bit confused on where and how it should be stored.
It is understandable that no one wants to tell you exactly what you should
be doing with your environment, but my gripe is that the information
largely exists in fragments. If someone tells you how to format an array
in your yaml file, they may not tell you how you should be splitting up
the data among your files.

I may be wrong, but this is what works for me at the moment. Like I said,
I’m still pretty new to Puppet. These will just be examples to get you
going the first time. To remove the seemingly intentional convolution
and mysticism around Puppet as a whole. Once I have a few more minutes,
probably in my next post, I’ll have my control repo set up and will be
linking to it. For now, here’s what I do with Hiera:

In my repo’s data directory, I have common.yaml, RedHat.yaml, and another
file called something like security.yaml. In my common.yaml, I’ll put
things like my ntp servers. RedHat.yaml contains service names and data
on the yum repositories I’m managing with Puppet. Most of my data usually
goes in my security.yaml. Whether I’m locking down access, disabling
services, or removing packages, there is a lot to do that I consider to
be primarily security related.

When I need a single value stored in Hiera data, I keep it simple:

sshservicename: sshd

If I’m storing data in an array, it will look like this:

   - ''
   - ''

So, the first example would be in my RedHat.yaml, and the second would be
in my common.yaml, both files in my data directory. My hiera.yaml,
which is in the top level directory of my control repo, is going to be as
simple as I can keep it. With the data files above, and using Hiera 5, it
should look something like this:

version: 5
  # Here's where any defaults you want to set go.
  - name: 'Where my data is.'
      - 'common.yaml'
      - 'security.yaml'
      - '%osfamily.yaml'

That will tell Hiera to look in the three files in my data directory. To
test that, you can run the command “puppet lookup sshservicename”.

The goal is to put all of your data in Hiera files, so you aren’t storing
any in your profiles. This keeps them somewhat portable, but also makes it
so you don’t have to dig through a hundred profiles to find the one place
you would need to make a change, if data were stored in profiles. It also
allows you to use cool things that minimize the size of your profiles,
like lambdas. That’s something we’ll save for a later day, but it won’t be
too far off. I really don’t want this series to be spread too thin.

I’d also like to add a quick note. When I first started trying to figure out
Hiera, for some reason I thought that you should use it to assign roles to a
node. While it can be used for that in certain ways, I’ve limited my use of
it, currently, to providing data for profiles. The base role I include in my
control repo is going to be assigned in a simple way, as the default in the
manifests/site.pp file. That’s something we’ll also look at later on.

This is a series I’m very excited about. I hope it helps folks who are new
to Puppet see how easy it actually is to get going. In addition to that,
I want to show that the more advanced topics that they discuss in their
don’t necessarily require the experience they recommend. I was lucky
enough to have two months to dedicate almost all of my time to learning
Puppet. Had information been presented online in an orderly, concise
method, I believe that could have been compressed into a few days.
Hopefully, this series will accomplish that, and anyone who stumbles upon
it will save a lot of time.

If there is something specific you’d like me to post about, drop a comment
below. I’m planning on posting about the things I mentioned above, as well
as Augeas, a few different modules on the forge, and a bit more. I’m sure
there’s something I haven’t thought of, though. Also, if you’ve been using
Puppet for a while, or whatever, and see something that I said that’s
absolutely horrendous, feel free to drop that comment as well. I’m totally
open to criticism and learning, and don’t want to be spreading bad info.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s