Puppetinabox is a new software project to allow easy development of a puppetized network by Puppet novices and experts alike. I talk about the genesis of the project and some of the surrounding technologies before giving a live demonstration of Puppetinabox
5. WHYPUPPET?
• 5 Things About Configuration Management Your Boss Needs To Know
• 2014 DevOps Report
• Why Puppet?
• Fastest Growing Tech Skills
• Razor: Bare Metal Provisioning
9. PUPPETINABOX
Environment
• Linux nodes, requires template with Puppet (example)
• Network 10.0.0.0/8
• DNS entries for provided services
• 10.0.0.100-150 DHCP dynamic entries
• Local user ‘padmin’ and sudo access
It’s a starting point - everything can be customized!
Provides sample code and data examples.
Tonight, I’m using 10.0.1.0/8.
10. LIVEDEMO!
Let’s do this!
More Detail:
Roles and Profiles Pattern (Designing Puppet – Roles and
Profiles)
R10k
• Official Workflow Guide
• New Module
• Existing Module
Q&A
11. ACKNOWLEDGEMENTS
Acknowledgements:
Puppet Labs (@puppetlabs): Puppet
Adrien Thebo (@nullfinch): R10k
Gary Larizza (@glarizza): Shit Gary Says
Matt Brender (@mjbrender): 12 Days of Commitmas
vBrownBag (@vBrownBag): professionalvmware.com
Community Rocks! Thanks for listening!
Editor's Notes
Hello everyone! My name is Rob Nelson and I’m a security and systems administrator at AT&T. You can follow me on twitter as rnelson0 or on my blog, rnelson0.com.
Tonight, I’m going to demo a new project I released last week called 'puppetinabox'. Puppetinabox gives you all the puppet components you need to stand up a small network using some common patterns and best practices from the Puppet community. You don't need to know much about Puppet to use it, but it helps! Jeremy Adams covered puppet in another vBrownBag, please go view his excellent talk for an in-depth primer on Puppet itself. You can find it on professionalvmware.com under the DevOps series.
I’m going to first address why I use Puppet, talk a little bit about the 12 Days of Commitmas and how that led to Puppetinabox, explain how it works, and then I’ll finish off with a live demo. There should be some time at the end for Q&A, but feel free to ask a question at any time in the chat window or on twitter with the #vBrownBag hashtag. A majority of our time will be spent on the demo, so let’s keep our fingers crossed for that
Let’s take a look at Configuration Management and Version Control.
As many of you are probably aware from this DevOps track, the use of configuration management, or CM, is a vital component to high performing IT groups. Version control is also extremely important. Together, they help ensure the consistency of system state, help audit and diff changes, and allow you to return to previous states as needed. You need to do this for everything – the application itself, the application’s configuration, OS configuration, network, DNS settings, etc. Usually we think of the software, but the config files are just as important. Having your configuration files in version control is another leading indicator for high performing IT groups, and that’s where we all want to be. I use Puppet for configuration management and git for version control.
There are a lot of CM tools. Why do I use Puppet? Easy: Because it’s popular!
Puppet’s popularity is very strong reason to choose Puppet. It’s one of the fast growing tech skills, which means you’ll be able to hire people who already know Puppet. There are over 3,000 publicly available modules on the Forge, Puppetlab’s module repository. If you need to do something, someone else has probably already done it, or at least started. There’s a great community on Twitter and IRC. If you need help figuring out how to do something with Puppet, help is a few keystrokes away.
There are more reasons than just popularity, of course. It can do bare metal provisioning with Puppet Razor. It can manage your networking gear, if it’s on the compatibility list, of course. VMware has invested heavily in Puppet. If you need more reasons, google “Why Puppet?”, or check out my blog post called “Why Puppet?”
Remember, there are more CM tools than you can ever evaluate. Choosing one will free up enough time that if you decide to change tools later, you’ll have the time. I might be talking about Puppet tonight, but I don’t really care if you don’t use it, as long as you use some CM tool! Get started sooner.
Here are some links about why you should use CM and Puppet. These slides will be posted to slideshare, so you’ll be able to find them there tomorrow.
The next question might be, why git? Again, because it’s popular! If you’re not familiar with git, you can easily find plenty of documentation on how to get started, common workflows, common issues – and fixes! – and how to integrate it with your existing tools. It’s not tied to a vendor or specific IDE or platform. And it’s social coding. With sites like GitHub, you can easily share your projects, like puppetinabox, with the rest of the world with very little friction. I highly recommend taking some time to learn git, it’s a skill you’re absolutely going to need within a few years no matter what your role in IT is.
To help people with git and social coding, vBrownbag’s own Matt Brender did a git presentation earlier in the DevOps track and followed it up with 12 Days of Commitmas this past holiday season. The goal was to encourage learning and familiarity with git by committing to using it for 12 days in a row. Don’t worry that the holiday season is over, you can still check out Matt’s GitHub repo at any time and have your own “12 Days of Crappy Winter Weather”, or whatever works for you!
I took part in Commitmas, and I can tell you that after a few days, you’re looking for something else to use git with. My home network needed some upgrades, but I had been putting it off for a while because lovingly hand crafting new VMs really stinks.
I was using Puppet in my home network, which is where my vSphere lab is, but I had quite a few VMs that pre-dated my Puppet setup. I decided that I could partake in Commitmas AND refresh my home network at the same time. As I mentioned earlier, you need to config manage and version control all the things, not just the software. I spent most of Commitmas, and some time afterward, documenting my home network’s services and crafting Puppet manifests for each service. My initial goal was to make it so that I could simply shut down my old VMs, spin up some new VMs, and the spice, er, streaming media would continue to flow, because maintaining SLAs at home is just as important at work. In spite of my planning, I wasn’t entirely successful in meeting the SLA – there were a few hours one day without DNS and an hour or so with no DHCP – but I made it through. I’m really happy with my end result and I’m confident that NOW I could burn down any one of the VMs and replace it in less than 30 minutes.
After I finished working on my home network, I had a rare thought – This was difficult and I bet there are other people in the same boat! And thus, Puppetinabox was born! If your home network needs a refresh, you need to stand up a proof of concept lab at work, or you just want to play with Puppet, Puppetinabox makes this quick and easy.
It does what it says on the tin. The “box” contains Puppet and enough config to provision some common services. All that’s missing is a gateway to the rest of the world. Puppet, DNS, and DHCP are mandatory. The build and yumrepo nodes are optional. A build server is where you’d create software and do your coding – not necessary for everyone, but it’s centrally located if you need it. I work on a few different machines and it’s very comforting to me to know that I just ssh to the build server and all my software and git repos are there. The Yumrepo is where you’d store any software you’ve packaged and serve it to clients, usually the puppet-managed nodes.
Puppetinabox should work with any Enterprise Linux based distro and has been tested with CentOS 6.5 and 6.6. You need a linux template with puppet on it. If you don’t have such a template, you can create one quickly with a kickstart setup as I’ve described on my blog.
The provided network setup is 10.0.0.0/8 and the sample data is based on this, including DNS zones and DHCP scopes and reservations.
There’s one ocal user, padmin, who is a member of wheel and has sudo access, so you can follow best practices and not use root as your primary login.
This can all be customized, you’re not locked into it. In fact, it’s mostly there to provide samples with correct syntax. You’re also not restricted to managing nodes within this network, so long as the nodes outside the network and the Puppet server can communicate with each other.
To show you how easy it is to customize this setup, I’m using 10.0.1.0/8 tonight, because guess what, 10.0.0.0/8 is my existing home network.
It’s time for the demo. I’m going to show how it works, then show it in action. As I go through it, I’ll be talking about the Roles and Profiles pattern and R10k software. Again, these links will show up in slideshare tomorrow, but if you want to follow along, google for “designing puppet roles and profiles” and the first link on Craig Dunn’s blog is the one you want. For r10k, just go to github.com/puppetlabs/r10k.