VMware Aria Automation Reviews

States, pillars, and custom modules have all taken us a long way in achieving our goals. There is great depth to it and we're looking forward to exploring all of its features.

We are moving from managing a handful of individual servers to being able to manage large scale collections. If we need to fit a particular use case, SaltStack makes it very easy to provision a new cloud instance quickly and almost effortlessly.

There are a number of bugs and regression errors that can make it frustrating at times, but given the flexibility so far I have found adequate workarounds.

The GITFS is flawed and requires a lot more work. We were able to construct our own workaround with local clones of all git repositories that are refreshed whenever a new commit or merge is made. GITFS is a feature in SaltStack which allows the salt-master to directly interact with git repositories. In theory, this is an incredibly efficient and useful capability. However, when implemented, we found server processes and load would escalate out of control whenever anyone made a git commit to the GITFS repositories. We were using v2015.8.5 at the time.

After researching the problem with the SaltStack community, we learned that there were multiple problems in the implementation of GITFS and what we witnessed was experienced by other users. Several SaltStack users recommended not using GITFS. As a workaround, I set up our salt-master with its own local copy of all of our git repositories and made use of the salt event reactor feature. When a git commit is made on our git server, a git hook triggers a salt event. Salt-master reacts to the salt event by performing a pull on its local repository copy. Its not as slick as the intended design of GITFS, but it works very well and has proven quite stable, completely eliminating the problems we experienced with GITFS.

At some point in the future we will revisit the GITFS feature, but for now we are satisfied with the current solution.

I have been using the solution for six months.

We have encountered quite a few stability issues with the GITFS option, but its been quite stable since we switched to our workaround solution.

We have not yet encountered any scalability issues.

This is an open source tool so we find out about fixes, patches, and other solutions through the online community and other online resources, such as Stack Overflow.

We did not have a previous solution as we are new to using DevOps management tools, but we researched others before we decided on SaltStack as our tool of choice.

Initial setup seemed so easy, but there is an art to designing pillars, writing state files, and other customizable structures.

This is an open source solution, but there is a paid enterprise option. If you plan to pursue the enterprise solution route, contact SaltStack for details. The open source option is very approachable.

We evaluated Puppet, Chef, and Ansible.

If you are planning to use the open source version, plan to allocate more project time than you think you need. However, once it's in place it will save you a great deal of effort.

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.

• 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.

The most valuable features are:

• Setting configurations options dynamically for servers
• Pulling information about all computers

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.

• Minion-less deployment of SaltStack. Minion is the client-side tool for SaltStack.

It’s a configuration management tool. We are using it for system deployment with AWS, patching of OS and applications. Deploying a patch on 200 systems is now just a click.

Minion-based deployment is not very smooth. Most of the time, many minions were in a stale state and didn't respond to the salt-master.

I have used it for two years.

I encountered stability issues. Minions didn’t work well as they moved to the stall state. In that situation, the salt-master can’t connect to the client servers.

I encountered scalability issues.

Community-based technical support is good. I never took it directly from SaltStack.

I previously used Puppet and found SaltStack to be better in terms of configuration. It’s written in Python, which means easy integration, and the structure is YAML, which is very simple.

Initial setup is straightforward.

Before choosing this product, I evaluated Puppet & Chef, but found SaltStack to be better.

I have no advice; it depends on infrastructure & application.

• Interoperability between operating systems with the ability to perform mass automation with triggering
• Integration with many vendors

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.

• The UI can get complicated very quickly when you start using SaltStack for a large number of machines (100+).
• The organization of the buttons / layout can make it difficult to search for the machine you are looking for. Even with the search function, it's difficult to determine the exact state in the correct order
• The UI should be organized in a more tree-like structure, starting from the initial state (root) with corresponding states being added after (node).

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 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.

• 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

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.

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

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).

• Configuration management
• Remote execution
• Grain & mine

I like knowing what state my machines are in, and I like being able to change their state all at once.

Some of what we do, we could not do without SaltStack.

Sometimes it feels like there are more moving parts than is necessary, and maybe something simpler would do.

I have used it for two years.

As long as the versions matched, we have not encountered any horrible stability issues so far. :)

The opposite: It does better with more nodes than it does with fewer, in my opinion.

The docs, though sometimes cryptic, are excellent and thorough. I haven't personally used their technical support services.

I previously used Puppet. I switched because our shop here likes using Python solutions over Ruby ones.

Initial setup was more complicated than Puppet, but the solution was also more comprehensive. Setup was worth the trouble.

SaltStack is completely open source, though you might consider SaltStack Enterprise as a way to get up and running more quickly.

Before choosing this product, Ansible and Puppet were brought up. Ansible seemed too small of a tool for what we needed and Puppet was written in Ruby, so they were discounted.

Thoroughly research how SaltStack works; that knowledge has helped me a lot.
SaltStack is a one-stop-shop for your datacenter's management, monitoring and state control needs. Using it that way allows you to get the most out of the tool. It is configuration management, but also orchestration, monitoring, and has reactive capabilities.