Configuration-Management on The Comfy Seat

Configuration Management Part 3: Vagrant & Packer

Sun, 27 Apr 2014 00:00:00 +0000

To facilitate developing my Puppet code, the Pro Puppet book suggests using Vagrant. Seeing as I’ve been meaning to get around to learning it for a while I decided now was the time to finally do so. The only problem is that, being a responsibly paranoid SysAdmin, I was never a fan of using a base for my work that I didn’t know the contents of. I also never liked the idea of basing my work off of something I didn’t understand (a Vagrant box) or that could go away at anytime.

Configuration Management Part 2: puppetlabs-apache & puppet-lint

Wed, 23 Apr 2014 00:00:00 +0000

Today was a good day. I installed puppet-lint and ran it against a custom module I’m writing for my first node and found lots of issues that it was kind enough to tell me exactly how to resolve. I then got down to using my first module from Puppet Forge: puppetlabs-apache Installing it was a piece of cake but understanding how to use it took a bit of trial and error.

Configuration Management Part 1: The Restart

Tue, 22 Apr 2014 00:00:00 +0000

As mentioned in my last post, I’ve decided to start over on my journey to doing configuration management in an environment where we treat our infrastructure as code. Today I kicked things off by setting up a new Puppet Master on CentOS 6.5. Once my usual setup was applied to the system via a PXE boot & Kickstart installed Git and the puppetmaster package and was off.

Version Control
One of my main goals is to track everything in Git so my first task was to change the group ownership of /etc/puppet to my puppetadmins group and give them write access. Then I needed to initialize a repo in that directly, tell Git that it’s a shared repository so other admins can work in it too, and tell Git to ignore the modules folder. I then applied the group permissions to everything inside the folder, did setgid on modules & manifests, and lastly I did a setfacl on modules & manifests so that us admins would retain rwx on all files and folders. Lastly I cloned my first module from our GitLab instance into a folder under modules.

Foreman: Too Much Voodoo

Mon, 21 Apr 2014 00:00:00 +0000

I finally got around to setting up Foreman at work and managing my first node with it. After digging around I found that I felt really boxed in using this setup because so much of the work is done behind the scenes in some magical way. One of my main goals is to facilitate the concept of infrastructure as code and, like my code, track changes via git and store them in our GitLab instance. The Foreman, as best I can tell, takes and hides everything it does inside a database which prevents me from being able to apply any version control to it’s settings. This is an unforeseen and unfortunate reality because the developers have made a really good looking product that can do a lot of really cool things. For me though, this is too much voodoo at this early of a stage of us doing configuration management and I think I’m going to back out my install and start over with a different approach that defines nodes in pain text .pp files. I’m sure I’ll take advantage of pulling in data from some external source like Hiera and / or other systems we have to help make decisions dynamically but I don’t think I want the configs themselves in a db… who knows; guess I’ll try it out and see.

Puppet, Factor, Dashboard, MCollective, Hiera, Foreman... Where does it end?

Sun, 27 Oct 2013 00:00:00 +0000

I want to setup a system based around the open source Puppet software stack… I am just not sure what the stack contains. My goal is a system that is holistic where Puppet, VMware vSphere, monitoring, revision control, and continuous integration all play well together. I also want to bring Vagrant and Packer into the mix for development environments. I’ve gathered so far that all the stuff listed in the title will be useful but what else is needed? Please comment below and I’ll also post again as I find answers.