In March 2014 post, agent42 at Enigmabox discovers CFEngine is 10 times faster, uses less memory and has simpler policy for JSON-driven configuration than other software; and is delighted by awesome support.

agent42’s post reminded me what sealed the deal for me when I was evaluating which configuration management tool to use.

I started by surveying the configuration management field. I picked CFEngine to examine closer because:

a) CFEngine had been around the longest, since 1993, so I expected it would be mature, and

b) CFEngine ran on the widest range of UNIX-like systems so I thought it would be a good career investment.

I read the manual cover to cover and tried every language feature to get familiar.

I asked for and got plenty of help on the mailing list, sometimes directly from the author within 24 hours.

I reported a performance-related bug. The author fixed it promptly, and, following discussion over private email, advanced the release date for the next version so I could put the fixed version onto my production systems. Mark said, “Things are a bit hectic here.” I had no idea what was going on. This was February 2008. The CFEngine company was formed in June 2008 and CFEngine 3.0 was launched in April 2009.

The author was highly responsive, cooperative, and kind. I got the “warm fuzzy feeling”, that, together with the product meeting my needs technically, allowed me to commit.

So when agent42 at Enigmabox discovered an issue and “a benevolent developer sat down and fixed it immediately”, I remembered Mark Burgess’s awesome support.

Agent42 asked, “Have I already mentioned that the guys at CFEngine are awesome?”

Yes, the people at CFEngine are awesome! And so is the CFEngine community. I especially want to tip my hat to Neil Watson and Ted Zlatanov who helped me get started and are helping users still and contributing to the community and the product.

To the entire CFEngine community: very well done, and continue!

Over the years, I’ve had more than one student come up to me on break or after course to tell me they wish they came earlier as it would have saved them time and trouble.

I’d like to share with you some real-life student comments (emphasis mine):

Last week I attended VSA’s CFEngine Policy Writing Workshop taught by Brian Bennett.

I wanted to take a quick second to thank Aleksey for putting this on and Brian for teaching. It was very helpful. I only wish I had taken it when I first started working with CFEngine.

And:

Aleksey (trainer) was one of the best hands-on teachers I’ve experienced in a long time. He is very knowledgeable about the subject, patient and keeps the class focused. His course materials including documentation, examples and exercises were very comprehensive. I certainly could have gained from his teachings and materials greatly at the onset of my learning CFEngine many months ago.

And:

Training has helped me improve my troubleshooting skills of CFEngine 3. I have understood some of the design goals and now clearly understand the syntax of CFEngine promises.

Email me now to organize professional CFEngine training for yourself or for your team.

A sysadmin I’m mentoring through the LOPSA Mentorship program has learned a lot on the job but is not sure what he is missing. He asked for help identifying what he knows, and where he should learn more.

I suggested he look at LPI’s page outlining what the LPIC-1 certification covers and follow this program:

1. Print the page

2. Check off the items that you are certain you know how to do / how to use

3. That will leave the ones where you should learn more. Starting from the top down, learn about and practice (get actual hands-on practical experience) until you feel confident you are familiar with this knowledge and can use it, then you can check it off too and move on, until you know everything on the list.

Configuration Management tools have become a critical part of our infrastructure. We expect and depend on these tools being robust.

For the tool makers I offer my notes on Dr. Holzmann’s talk on how NASA/JPL builds robust software. The first part introduces and describes the challenge, the second part contains the solutions.

Use Syntax Highlighters

Highlighting syntax is a big time server. Color highlighting lets you save time and trouble by catching errors early in the development process.

Use a syntax plug-in for your editor!

Revision control system hooks.  Code review.

You can set up a precommit hook to validate syntax before accepting code into your VCS repository; or you can use Jenkins to syntax-check new commits and move them to another branch if they validate.

knife-spork from Etsy is a workflow plugin from Etsy to allow multiple users to work on the same Chef repo/server without stepping on each other’s toes. Spork integrates with graphite and IRC. Good for big teams!
https://github.com/jonlives/knife-spork

Gerrit is a Web-based code review system based on git.
https://code.google.com/p/gerrit/

Use Vagrant to test your code.

http://vagrantup.com/

• Vagrant has provisioners for Ansible, Chef, CFEngine, Puppet and Shell.
• You do have block out or disable external dependencies (since Vagrant is encapsulated).
• SSDs pay for themselves. VMs come up much faster.
• Matt Barr keeps a local copy of CentOS DVD mounted to provide the full repo to his Vagrant VMs. He also deploys new code to VMs automatically.
• Sinatra is a web development framework for minimalists. You can use it to quickly build simulators of external web services inside your Vagrant environment.
• Jenkins can deploy your code into Vagrant VMs

Testing

foodcritic, puppetlint and cf-promises check syntax. But how do you check the output (the modified system)? The answers are unit testing, integration testing and user acceptance testing.

Use Jenkins, TravisCI, etc.

rspec is a Ruby testing framework. You can write tests for your configuration in it.

http://rspec.info/

For Chef, chefspec is an extension to rspec for unit-testing. Also, minitests and test-kitchen (http://www.opscode.com/blog/2012/08/17/announcing-test-kitchen/ and https://github.com/opscode/test-kitchen)

For Puppet: serverspec + rspec do functional checks of remote systems.

User acceptance testing

You can deploys to test VMs first (like Matt does).

You can deploy to “canary” servers (a limited production deploy, AKA “toe-in-the-water” deploy).

External monitoring can be done with traditional tools, such as Nagios.

cucumber-nagios lets you describe how a system should work in natural language, and outputs whether it does in the Nagios plugin format
http://www.cucumber-nagios.org/
http://fooforge.com/2012/11/06/Analyzing-my-OSMC-2012-talk-on-BDI.html