Based in the South West of England, Alex is the director of Linfratech Ltd, a consultancy company specialising in Linux systems, automation and configuration management with Puppet. An IT professional with over 15 years experience, he has been working with Puppet for the last 6 years and is an active community member. He has served on the Vox Pupuli Project Management Committee since the start of 2018. A regular at DevOps and Puppet conferences, he enjoys sharing his experience and knowledge with others as well as learning from all the great people he meets.
That's not my puppet - Things *not* to do (and some alternatives)!
Whilst best practices do involve over time (and sometimes 'advice' changes completely), there's also the other end of the spectrum where
style-guides are ignored, house 'styles' take over and the anti-patterns and worse prevail.
Fed up with being told 'it works, why shouldn't I write puppet this way?', I present a selection of puppet code witnessed in the wild.
(All from non Puppet Enterprise setups. PE users all write beautiful code and none of it ever looks like what follows, right?)
From just old code, (with better and simple to achieve improvements), to the darn right ugly, stupidly fragile or just plain broken.
- Old constructs (from a land before puppet 4) (create_resource, anchor etc).
- Abuse of hiera
- Too much data
- The super hash. $data = hiera_hash('data') $jdk_version = $data['oracle']['java']['jdk']['version']
- Calling hiera from templates with local scope vars used in the hierarchy
- Abuse of
- Why use a file resource when you can have an exec call
- Replacing an old script with 30 chained execs
- Ruby based facts that shell out to
- Mono repos with forge modules seemingly randomly committed in then modified in place.
- Writing everything from scratch (even when really simple and popular forge modules exist)
Finally, is there anything we can do about this (other than venting frustration at conferences?).