SaltStack Review

Configuration file templating limits copying and pasting. Agentless exeuction does not support remote actions that require a sudo password.


Valuable Features

  • Configuration file templating: limits the amount of copy/pasted configuration across services with minor differences
  • Near instant orchestration: no waiting to see if a change worked
  • Well-formatted and detailed command output and logs: make troubleshooting easy and break/fix recovery fast

Improvements to My Organization

Developers and systems engineers could work together more closely.

Room for Improvement

Salt does not support performing remote actions that require a sudo password with Salt SSH (agentless Salt execution).

Ansible does support this feature.

Use of Solution

I have used it for two years.

Stability Issues

I have not encountered any stability issues in the last year.

Customer Service and Technical Support

Official documentation and community support are top notch.

Previous Solutions

We previously used CFEngine 2 and Chef; both solutions have a steep learning curve that requires a ton of domain-specific knowledge. Salt is configured from the ground up in YAML files and Python, so there's less domain-specific knowledge required and no hidden configuration files.

Initial Setup

Salt's initial setup took about two days to go from knowing nothing to having a configured Apache Tomcat server serving our content. That's simple in my book. The complexity comes in when you want to add security policies or routing that aren't ordinary for a horizontally scaling web application; that takes some creativity.

Pricing, Setup Cost and Licensing

Don't pay for it, use the free licensing options unless you don't have the staff to cover your SLAs.

Other Solutions Considered

We also looked at CFEngine 3, Chef, Ansible, and Puppet.

Other Advice

Look at Digital Ocean's guide for initially setting up the Salt server (https://www.digitalocean.com/community/tutorials/saltstack-infrastructure-installing-the-salt-master). Group your configurations by logical components, serve any environment/deployment-specific variables from pillar files, and keep templates as simple as possible (put logic for assigning variables in the *.sls files where there's likely to be other logic).

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Add a Comment
Guest
Sign Up with Email