SaltStack Best Practices Cheat Sheet
By design, Salt is not opinionated. That means that its flexibility allows you to create your own patterns and designs for concepts where it makes sense. The best practices outlined here are meant to be suggestions – not doctrine. Thus, this is a living document that evolves over time as your infrastructure’s needs change.
For anything not covered under this guide, defer to Salt Best Practices.
States are atomic and seldom change
Static – the way you install and manage, for example, Vim isn’t likely to change much over the years. Install the package, enforce its config file, ensure that it’s in the system PATH, etc.
Atomic – a State does not require dependencies external to its relevant SLS files.
Idempotency at all costs
The power of Salt means doing a state.apply at any time should never be a problem.
Use Pillars for basic templating
Because we already said that our States are atomic and mostly static, we should move variables out of States and into Pillars. Your States top file says that a target should have NTP, Vim, Nginx, and Tomcat installed, but Pillars should fill in the version numbers, path, passwords, etc.
Go easy on the templating
Templating is great, until it isn’t. Avoid premature optimization because boiling the ocean is an easy way to lose sight of the real problems that need solving. Favor readability.
Maintain local consistency
Global consistency is nice, but don’t be blinded by it:
[…] take a few minutes to look at the code around you and determine its style. If they use spaces around all their arithmetic operators, you should too. If their comments have little boxes of hash marks around them, make your comments have little boxes of hash marks around them too.
The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you’re saying rather than on how you’re saying it. We present global style rules here so people know the vocabulary, but local style is also important.
comments powered by Disqus