Profile photo

from miller import blake

Hello, I'm a Seattle-based site reliabililty engineering manager, I get paid to do what I love, I like Python, I'm in an abusive relationship with JavaScript, I'm a fan of good design, and I don't think things always have to be so stupid.
You can follow me @bltmiller, subscribe via RSS, and email me.

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

Copyright © 2020, Blake Miller. All rights reserved. | Sitemap · RSS