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. Box building time The solution to my dilemma was to learn how to use Vagrant and to make my own base boxes for it. Their site does a good job of listing the minimum specs and Puppet Labs publishes the recipes for their base boxes that are built using Veewee on GitHub. Between these two » Read more

 genebean        

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. *My First Puppetized Apache Server * One of the things my first node needs is an Apache install that can serve CGI files via httpand https… seems simple enough, right? To facilitate this I see from the module’s docs that it makes a default vhost for httpand, optionally, can do so for SSL too. I took at the default values for the module’s parameters and decided they weren’t going to cut it so I » Read more

 genebean        

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 » Read more

 genebean        

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 » Read more

 genebean        

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. » Read more

 genebean