The most valuable features are:
- Setting configurations options dynamically for servers
- Pulling information about all computers
The most valuable features are:
We are able to control updates on servers to streamline the process
There is still development for states and pillars. The software is open-source so it allows for extreme customizability. If there is something that you think could be improved, you can code it. Our company is currently working on a few projects to help improve and support SaltStack. I would like to see more training on how to use the many different options. There is a lot of of information to go over and it’s hard to keep it all straight. Other than that, if you put the time learning SaltStack, it is a pretty easy and very powerful tool.
We used this solution for a year and a half..
We have not had issues with stability.
We have had no scalability issues so far.
I don’t have experience with their support, but I heard they are helpful. There is a IRC chat that you can join to get help from your peers.
I was not a part of the setup, but from what I have read, it is pretty simple.
The software is open source. One has to pay for support.
Read the documentation to learn as much as you can.
SaltStack allows me to answer user requests in a very efficient manner.
I guess the only downside of SaltStack is the limited user base, which leads to poorer documentation because of the lower use.
On a features side, maybe some more security around the API would be good, so it can be used as a central automation tool.
I haven't kept up with latest releases for a while, though, so don't quote me on that.
I have used it for two years.
I have not encountered any stability issues.
I have not encountered any scalability issues.
It's open source and the community is very helpful as usual.
I previously used multiple solutions combined; harder to manage. Salt is easy to use and manage.
Initial setup was straightforward; worked out of the box .
It's open source.
Just install it and use it for remote execution at first. You'll see how powerful it is.
The most valuable feature is Salt Cloud due to its ability to tie into VMware, as well as Salt Orchestration, because it allows us to script the process of setting up an entire infrastructure.
This product has saved us time in standing up new servers, as well as allowed us to automate the deployment of these servers and the applications that run on them.
I have used it for 1.5 years.
Occasionally minions would time out and not return a response, although the Salt state would still run. Increasing the timeout helped, but this is more of a design concern than an overall stability issue.
So far no issues with scalability were encountered.
I haven't utilized technical support. The forums seem to be somewhat helpful in suggesting workarounds to issues caused by lack of features, but more detailed steps on implementing those workarounds would be helpful (e.g., setting a static IP on Windows VMs setup with Salt Cloud).
I've used Puppet at a previous job. Salt is the tool that was in place at my current job.
Salt is open source.
The product was already in use.
Define the scope of what you need a configuration management tool to use and then look at all available options and the potential drawbacks of those options. Nothing can beat hiring a sys admin with experience in different technologies.
These features are valuable because I need them to complete the work assigned to me.
The GUI is clunky and hard to use. It could be more user friendly.
I have used it for six months.
I have not encountered any stability issues.
I have not encountered any scalability issues.
I recommend SaltStack because, for SysOps or DevOps users, automation is a key part of getting your product out and allows for faster time to market.
The ability to programmatically describe the desired state of a single, or an entire fleet of servers, on-premises, and in a cloud environment.
SaltStack gave us very useful automation tools that allowed us to standardize our environment, move at a much faster pace through repeatable deployments, and self-documentation of our infrastructure.
It allows us to describe the desired state of our entire fleet of servers through simple to understand syntax and templates all available at a single place.
This is great for things like documenting what a single machine or a group of machine does and how they are configured. It is also good in the event that one of them is lost and a new one needs to be provisioned quickly.
Instead of setting it up by hand, we end up telling it "you are this type of machine" and SaltStack will take care of ensuring that the machine becomes what is expected.
It also means that any machine of "this type" will be setup in a consistent manner thus avoiding unexpected surprises that could potentially become the cause of outages.
Each new version seems to bring a new set of bugs to the table and upgrading is risky, especially for a tool at the core of the operations and infrastructure.
A hardened set of tests would be much appreciated.
We have encountered many bugs during upgrades in the past and it seemed to me like those could have been caught by the developers at a much earlier stage then after doing a widespread release.
We have used this solution three years in production
We have encountered several issues when we upgraded to 2015.8. Some of those were eventually fixed by the community and through fixes we submitted to the project.
We have managed a fleet of hundreds of servers without any scalability issues on the horizon.
We have not requested technical support.
We evaluated Chef, CF Engine, and Puppet and we ultimately decided on SaltStack because:
The initial setup was simple enough to get started and see the benefits that the solution brings. There are many tutorials available to get someone started.
Unfortunately, our experience is limited to the open-source (community) version. We have no information in regards to the enterprise offering.
We evaluated CF Engine, Chef, Puppet, Capistrano, and Fabric.
Take some time to learn the types of problems it can solve and you will easily see the benefits that it can bring.
Jinja/Python + wide range of embed functions for various platforms and purposes.
Jinja is based on Python, which is a fairly handy and comfortable programming language. They make it simple to create Python-based templates and, when necessary, create functions for actions that are not covered by the Jinja engine.
Centralized administration and orchestration of severs and services.
Support: It's not bad or poor, but there are some issues. On the one hand, it's about development and progress; on the other, there were some issues that took too long to get fixed by the SaltStack team and forced users to invent workarounds.
Documentation: I'd say it's a little bit complicated for beginners, some topics are not clear and so on. So, one will have to massively use search engines when it comes to complex setups and solutions.
I have used it for ~7 months.
I have encountered any stability issues.
I have not encountered any scalability issues.
Technical support is good (4 of 5).
I did not previously use a different solution.
The initial setup was neither straightforward nor complex; it required some effort.
It's OSS.
Be patient and you'll get a great solution.
Agentless application deployment is the main reason for faster setup and easy deployments.
We have been using this solution for three months as part of a PoC.
I did not encounter any issues with stability.
I did not encounter any issues with scalability.
We used open source community support.
The installation was straightforward, especially the master and minion configuration. This configuration was time saving and led to a faster, automated application deployment.
We didn't go for pricing model, as we chose to do a PoC using an open source version.
We evaluated Ansible.
This product is in good shape now and the community support is vibrant. I learned a lot from them while implementing it.
Developers and systems engineers could work together more closely.
Salt does not support performing remote actions that require a sudo password with Salt SSH (agentless Salt execution).
Ansible does support this feature.
I have used it for two years.
I have not encountered any stability issues in the last year.
Official documentation and community support are top notch.
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.
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.
Don't pay for it, use the free licensing options unless you don't have the staff to cover your SLAs.
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).
Thank you, George! This is quite an interesting comparison between SaltStack compared to Ansible and Puppet.
I encourage you to read up further on our community members' own product comparisons between SaltStack and other solutions, such as Oracle Enterprise Manager Cloud Control --
www.itcentralstation.com
I'd be interested to know your thoughts on which attributes of each solution contribute most to the comparison.