Welcome back to our Puppet series. I apologize for the extended hiatus and thank you for sticking around! As an added bonus, in addition to inlining files, I’m including links to the corresponding files and commits in my PuppetInABox project so you can easily review the files and browse around as needed. I hope this is helpful!
Today, we will look at improving our build server. The build role is a centralized server where we can do our software development, including work on our puppet code and creating packages with FPM. When we work with git, we have to run git branch to see what branch we’re in. If you’re like me, this has led to a few uses of git stash and in some cases having to redo the work entirely once you start committing on the long branch. To help, we’re going to add the currently-active branch name of any git directory we are in to the PS1 prompt. We also are doing a lot of edits of *.pp files and we don’t have any syntax highlighting or auto-indenting going on. We can fix that with a few modifications, and we’ll discuss where additional customizations can be made.
In my 2015 Goals, I originally had a goal of submitting a talk to VMworld. As the year went on, it became clear that a Puppet-oriented talk was more fitting and I submitted an abstract to the PuppetConf Call For Papers. I’ve very proud to announce that my abstract was accepted and that I’ll be presenting at PuppetConf 2015 this October in Portland, OR! My talk is tentatively titled Puppetizing your Organization: Taking Puppet from a Proof of Concept to the Configuration Management Tool of Choice (PyO:TPfaPoCttCMToC will probably be shortened!) and aims to help you move from buy-off on your proof of concept toward buy-in from your entire organization.
PuppetConf’s call for papers works is similar to many other conferences: you present an abstract and if accepted, you have a few months to flesh the abstract out into a full presentation. One of the concepts in my abstract is to share with and learn from others, and this talk is no different. I need your help to make sure I include multiple perspectives and lessons, not just mine. Please take a look at the abstract and let me know both what you’d like to see me cover, and any tips you have to share with others. You can leave your comments here or on twitter. I’ll make sure to acknowledge you during my presentation, unless you let me know otherwise.
I’m eagerly looking forward to meeting everyone in the Puppet community this fall! Make your reservation now using this 35% off link and be sure to attend my presentation!
The final phase of Visible Ops is Enable Continual Improvement. To really succeed with our efforts, we need to make sure that the resources we have are allocated optimally toward our business goals. With most of our fires put out and significant efforts into avoiding future fires, we have the time available to do this right. To determine where our resources should be allocated, we need to look at metrics.
Phase three of Visible Ops is Create a Repeatable Build Library. This phase’s focus is to define build mechanisms, create system images, and establish documentation that together describe how to build our desired infrastructure from “bare metal” (I’ll continue to use “bare metal” throughout for consistency, but “bare VM” may be more appropriate in today’s virtualized IT). This allows us to treat our infrastructure like fuses. When a fuse pops, it is discarded instead of repaired and a new fuse is inserted in its place; likewise when a system fails, it is removed from service and a new system is provisioned in it’s place. All high-performing IT organizations, not just the unicorns of IT, use this technique. This chapter focuses on how to achieve that goal.
In the second phase of Visible Ops implementation, our goal is to Catch & Release and Find Fragile Artifacts. This phase focuses on creating and maintaining an accurate inventory of assets and highlighting those that generate the most unplanned work. The various configurations in use are also collected in order to start reducing the unique configuration counts, the focus of Phase Three. This is the shortest chapter in the book at 6 pages, though it may take significant time to complete the work efforts.
The Issues and Indicators lays out the issues being tackled, including moving from “individual knowledge” to “tribal knowledge” (a shared knowledgebase the entire organization can access, rather than in people’s heads) and preventing the “special snowflake” syndrome where every node in the network, even those in clusters or farms, are similar but still unique.
The first phase of implementing Visible Ops is Stabilize The Patient and Modify First Response. This first order of business intends to reduce our amount of unplanned work significantly, to 25% or less, to allow our organization to focus on more than just firefighting. When the environment is stabilized, efforts can instead be spent on proactive work that stops fires before they start.
The chapter, like all chapters in Visible Ops, begins with an Issues and Indicators section, describing the issues with both a formal statement and a narrative example. The issues are familiar to anyone in IT, from how self-inflicting problems create unplanned work to the inconvenient, but predictable, timing of system failures during times of urgency. The narrative example provided helps to relate the formal statement to the experiences we all share.
A few months ago, I purchased The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps, by Kevin Behr, Gene Kim, and George Spafford and published by the IT Process Institute (ITPI). Those names may sound familiar, as these are the same authors of The Phoenix Project. Where The Phoenix Project is a novel that teaches us general concepts through storytelling, The Visible Ops Handbook is a set of instructions to help us implement the changes that are now so vital to the DevOps movement – it’s all about executing! The Visible Ops methodology it teaches is one of many precursors to DevOps, and it’s a wonderful foundation that I feel should be explored by all.
Visible Ops has a nice structure. There are five sections describing the four steps of Visible Ops (70 pages) followed by a few appendices (30 pages). The content is a result of studies done by the ITPI (contemporary equivalents of today’s State of DevOps reports) and the implementation of Visible Ops, before it went to print, by IP Services. In those 100 pages, the lessons learned from the studies is codified using ITIL terminology. The writing is very accessible, but also very dense, and is worth referencing repeatedly as you work through the included steps. The target audience is decidedly technical, but everyone in an IT organization can benefit from the material.