SaltStack Reviews

Execution modules. It is designed for system administrators rather than for developers. It covers maximum functionality and makes automation easy.

As it provides maximum functionality, it keeps automation short and sweet. This helps writing automation in a modular format. SaltStack helped us in optimizing infrastructure related tasks, such as operations.

There should be some mechanism to push agents to the target device. Also, it should focus on managing networking devices.

In order to manage Salt minions from a Salt master, we have to install the Salt agent. As of now, there is no mechanism by which we can push and install this agent on a target machine.

For example:

• A - Salt Master
• B - Windows machine

From A, we want to control B. For this to happen, B should have a Salt agent running on it. There should be some mechanism in which we are able to push and install a Salt agent from A to B. This is assuming that we have to provide an IP address and the credentials of B.

For now, there is concept of Saltify, in which we can partially achieve the above scenario.

We have been using this solution for close to a year.

We found some intermittent issues with the Windows minion connection.

The installation is straightforward and is pretty much a simple setup.

We have used the open source version. In open source, you will get good enough functionality.

We have evaluated this product against Puppet, Chef, and Ansible.

As a DevOps engineer, this CM tool is truly made for system administrator usability rather than for the developer.

• Distributed shell: Ability to execute remote commands on all targets at once.
• Package Helper: Upgrades all your machines with one command: The package method of SaltStack allows easy host updates. (See https://docs.saltstack.com/en/... .)

We spent far less time to upgrade and configure all of our hosts. A lot of time was saved.

I'm not aware if a UI exists or not. There are a lot of possibilities, like having a kind of dashboard that would recap all of the states and responses to commands.

I’ve used this solution for four years.

I have not encountered any stability issues.

It is very scalable!

I have not used technical support.

This is the first solution I have used.

The setup was pretty straightforward, especially compared to "legacy" solutions.

It is non-paid product usage.

I evaluated Ansible.

Read the documentation. There is nothing fancy or special to know before using it.

The two most valuable features to us are beacon related. We can use the beacons to alert that a service is stopped, and restart it almost instantly. Also, we can use the beacons to alert based on whatever monitoring metric we see fit. For example, if a server is running out of usable RAM, for example, we can alert on that, and react to it in whatever way we see fit. We could in fact automate any aspect of scaling – all because of SaltStack. Also, it enables you to have a remote CLI on every server in your infrastructure and issue a command to it. Within seconds, you will have the results of that command in an organized list.

We use it to automatically install software on servers with the minion installed – based on the server name. So we can bring any machine up to spec by simply changing the host name. We have plans to automate it even further; it is just a matter of time.

The online documentation is lackluster at best. It usually only gives one example of how to do something. If you want to see all possibilities, you have to look at the Python code for the SaltStack modules themselves. They are commented extremely well, and what isn't there you can write yourself! Anything is possible when you edit the code on your own. We have modified many modules to suit our specific needs.

I have used it for 10 months.

I have not encountered any stability issues.

I have not encountered any scalability issues. It has helped us scale other applications.

We are all self-taught on this product. I have not initiated a call to their support. I will say their online documentation leaves something to be desired; however, that is all made up in the code itself. It is commented really well.

We were previously using SCCM and SCOM. We have brought in SaltStack and it is slowly taking over those two spaces. SaltStack is a great orchestration tool, but not intended to be used for monitoring. We are looking at switching over to Zenoss for our monitoring solution.

The initial setup was complex because we did not think it would be as simple as it was. I can build a new SaltStack infrastructure in a matter of minutes now, but initially it took me longer than I would like to admit. Again, it is hard to make your way through the documentation. I was using YouTube videos for instruction.

We use the free, open-source version. I have no information or experience with their pricing.

We looked at Ansible, Puppet, and SCCM. All were really good at what they do, but SaltStack seemed to be much more feature rich than the competition. I am extremely happy with our decision.

Absolutely, positively, go to YouTube first before looking at the documentation. Documentation gives you a great start of what you need, then you look at the code to see the configurable options.

• Reactors, because of the automation help they provide (reacting to custom events).
• State dependency trees, because a state can be linked to the status of another state, allowing you to particularize the behaviour of the software in some cases. The result of the execution of a system_state can be linked to different other states. For example, you can say: IF Upgrade_Apache is OK then Restart_Apache else Rollback_Upgrade. In that manner, you can create a sort of dependency among multiple desired states.

For example, with automation, before SaltStack, user management to access servers by SSH was done "by hand". The risk was leaving life-long access for some users, who were no longer with the company.

Integration in BASH Scripts: Maybe I’m just lazy, but I've not been able to find a mapping between state execution success/failure and Salt command return codes.

I have used it for 1.5 years.

I have encountered stability issues; they are always resolved by new releases of the software.

I have not encountered any scalability issues.

Technical support is excellent, even by chat.

I did not previously use a different solution.

Initial setup was simple.

I use the community edition, so it is free.

Before choosing this product, I did not evaluate other options.

• Extensibility and flexibility
• Open source
• Active community

Also, the text-based configuration is very important to discern differences in version control. It also means it is easily configured with templates, and easily edited.

Salt lets you run commands on hundreds of servers at once; and sync up software, tools, and scripts across your infrastructure.

The flexibility can hurt sometimes, as there are so many ways to accomplish the same task. I don’t want to give the wrong impression; the flexibility helps more often than it hurts. However, when there are multiple choices to a complex software problem, one can make mistakes, and with a configuration management system, a mistake can get pushed to an entire infrastructure automatically.

I have used it for one year.

Salt has been remarkably stable, and it is simple to send metrics to an external source like Elasticsearch.

I haven’t had any scaling issues.

I would rate technical support very high. Personally, I have posted issues to GitHub that have been responded to the same day or the next day, and closed within a week.

This was our first foray into the configuration management space. Previously, it was a bunch of PowerShell scripts.

Salt has a very straightforward installation.

Salt is free.

Before choosing this product, we were looking at PowerShell DSC, because we were all PowerShell anyway. It was too unpolished; did not seem to fit properly with what we had in mind.

Have a good plan about how you are going to target your infrastructure; a solid naming convention helps a lot.

The most valuable asset is most probably the ability to target the needed hosts, and running commands via modules or a shell on all of them at the same time. This means that mass parallel administration of large server farms is possible.

I am now able to rollout critical updates within seconds on all affected servers, and it doesn't matter if there are five or 500 of them.

So far, everything worked as expected. This means that so far, I heavn't seen anything which needs improvements. The software works as expected and I stumbled across no issues while using it.

The most valuable feature of the product is the automation for services; it’s the basis of my work. It is important because nowadays, in this complex world, services have become the base for everything. Having a large base is needed to better build what you need for your pipelines, as opposed to a few years ago, when the application was king.

We created pipelines for all our products.

The base library is missing some key elements such as networking management (mine is lacking on that front) and some more granularity on the apt part.

I have used it for 12 months.

I have not encountered any stability issues so far.

I have not encountered any scalability issues so far.

Technical support is just about right, in the sense that the product is well documented and information is easy to find.

We previously used Puppet, which was not suited for my current workload. We chose SaltStack because Ruby wasn't the language used by my team and we needed a master-client solution as opposed to a master-less one.

Initial setup was very easy.

Pricing and licensing is perfect the way it is.

Before choosing this product, we also evaluated CFEngine.

Read the docs.

• Simple and flexible YAML/JSON configuration management framework which allows simultaneous configuration of thousands of systems
• “Reactor" for event-driven infrastructure which must be present in any cloud based solutions and in CloudOps itself
• Powerful and flexible DevOps orchestration solution

• We decreased deployment CD times from hours to minutes across different cloud providers on several hundred systems.
• We used a SaltStack agent as a “Convergence” agent which provided us with management, monitoring, and backup capabilities.

• Backward compatibility
• The speed of fixing bugs

We have used this solution for under three years.

With the correct infrastructure design, stability issues probably won’t occur. SaltStack supports several features for high availability and fault tolerance.

In terms of SaltStack code/bug issues, it is a very stable product after four years of development from 12,000 developers.

I did not encounter any issues with scalability.

SaltStack is a very straightforward system with very good documentation. There are different solutions for deployments. Many scenarios and best practices are available publicly on the SaltStack site.

We evaluated Ansible and Puppet. SaltStack provided a much more robust solution.