Since the inception of R10k there has been a recipe of 1 part branch to 1 part puppet environment for puppet control repos. This concoction has allowed us to create one-off ephemeral test environments that we all love simply by creating a new git branch.
Since R10k was first introduced we have always used the promotion workflow to usher features into environments. While this workflow served us well there is a different kind of code setup that is now possible with R10k that improves upon what we already know.
Coming soon!
In the meantime, read up on these first.
Single branch strategy
Environment strategy
R10k YAML environment docs )
I heard this quote a while back and I keep repeating for all to hear.
The theory is quite simple:
Less is more Reduces complexity Improves performance Reduces loading times No tests needed for the deleted code No documentation needed for the deleted code Readability is enhanced Reduce. Resuse. Delete.
“No code is the best code.”
A client of mine recently had a need to discover that state of a particular package from inside a fact. Ironically, someone else in the puppet-community had a similar need and was asking questions about this. So I thought it would be a good idea to blog about how to query the system agnostically without shelling out in a fact.
The original solution for many of us was to create a fact like the following:
The Puppet Development Kit (PDK) makes it really simple and efficient to work on puppet modules. If you have never used the PDK I would encourage you to try it out especially if you use windows.
The PDK wraps all the annoying tasks so that you don’t have to endure the pain of modifying Gemfiles, spec files, folder structure and other puppet related module development tasks.
But with any good wrapper code, what you gain in efficiency you do so at the cost of control and customization.
What does Puppet and alternative facts have in common?
No, this is not some political rant about how real facts matter. This article is about sub-planting alternative puppet facts provided by custom external FacterDB facts.
But first. What the hell are FacterDB facts? FacterDB facts are artisanal hand-made facter sets from real systems stashed into a filesystem based “database” and searchable via facts. Basically just run puppet facts and save them off into git to get an idea.