Red Hat Ansible Automation Platform Reviews

It's a catch all. We now have a central way of pushing out updates. As long as we have every name of all the hosts on the network that we want to patch on Linux primarily, we have it covered, from one person logging on and issuing the commands, then looking for the feedback from the servers.

I like being able to control multiple systems and push out updates quickly with just a couple of clicks of a button and commands. I like the automation because it is a time saver.

I have seen indications that the documentation needs improvement. They are providing a "How to Improve Your Documentation" presentation at this conference.

It is stable and reliable. I don't see any problems with it.

We patch every week and have seven different environments, so now we are dealing with about 300 servers. However, we could increase that to 20,000 servers, as long as we have them in our catalog. We could push that out and be fine.

We haven't had to use tech support, but they are there. If we need to, I am sure we could easily reach out to them. We have an account.

We chose this solution simply because we use Red Hat. We trust Red Hat, and whatever Red Hat puts out, it is pretty solid.

The setup was done by another team of ours that we worked closely with. They walked us through setting up our own, and it's pretty straightforward. Once you install it, stand it up, and get all the configuration files in place, it seems pretty straightforward. 

I was surprised that it was so straightforward.

Our use case for it is as an automation tool. For the Linux side, we have very few automation tools. We do have Puppet Enterprise as a matter of fact, and we're looking at tools for automating our day-to-day operations, server builds, configuration management, etc.

We've got a demo version of Tower. We've been playing with it, using it for patching. One of our first goals is to automate patching.

The improvement is going to come in that we are going to be able to maintain configuration management, through the use of both Puppet and Ansible. Currently, in a manual process, hands-on - that is what kills us. When we have a system administrator trying to do his job, that kills us every time. We have 2,500 servers and if a project comes to him, we have 15-minute time-outs. I don't like that. He'll go in there and he'll change it. And we can't control that and we don't know when it gets changed.

The hope is that we automate and then it's there, we know it's there. And then we'll use Puppet to come in at the back, and just maintain it. That is our plan.

If somebody tries to change something through Puppet, we're going to get reports. Ansible is going to be used on the front end, and if somebody comes up and says, "We need this patch pushed out. It's an urgent patch. It's high criticality. We need to do it now," we'll do it through Ansible. We'll write a Playbook or a module and just, boom, get it done.

The most valuable feature is the Playbooks and pushing them out.

We'll probably use it in conjunction with Puppet, because Puppet is more a solution where every 30 minutes it's going to check, whereas as Ansible doesn't do that. You have to push, from my understanding. That's what I thought. I could be wrong.

It has been stable so far.

It's scalable. We're looking at an enterprise configuration, when we get it done. It's a matter of getting it licensed.

So far, in our interactions with technical support, they've been knowledgeable. We're very happy.

The setup looks pretty straightforward. From what I've seen, although it was done by another person, it seemed to be pretty simple. I think it was an RPM.

We have a lot of Red Hat servers in our data center environment, so we use this solution to manage the configuration, deploy and push configuration management. In addition, we use the Red Hat Ansible Automation Platform to automate deployment tasks.

We can manage all the configuration consistency between all our servers. It is a configuration management tool, so we can easily manage our consistent configuration course over different Red Hat or Linux servers. We have not used Windows recently and are using only Linux now.

We like the GUI-based interface for the tower. Before, we only had a command-line interface to run all the Ansible tasks. Now, the Ansible tower provides the complete GUI functionality to run, manage, and create the templates and the Ansible jobs. This includes the code and YAML file we can create. The GUI interface is the added advantage of this solution, including some integration with the different plugins.

It should support more integration with different products. For example, it is for network security automation, and with the VMware product, they don't have an integration for NFTX right now. So they should include this integration capability so we can automate more tasks with this solution.

We have been using Red Hat Ansible Automation Platform since 2021, and we are using version 3.2. It is deployed on-premises.

It is a stable solution. 

It is a scalable solution and is based on your node license. We are using more than 400 servers right now, and it requires one senior system engineer for maintenance and deployment. We plan to increase the usage using Windows automation.

I rate the technical support an eight out of ten. 

Positive

We used a Puppet configuration in the past. We staged with Puppet and then moved to Red Hat Ansible Automation Platform.

The initial setup and deployment were easy, but the first two days of operations were a bit complex. We completed the deployment in-house.

There is a return on investment as a technical person. It has saved time and effort in maintaining the deployment environment. So on the technical side, it's saved lots of time and effort on the configuration.

I believe the cost per node basis is around $125 per node.

I rate this solution a nine out of ten. Regarding advice, for the deployment, I would suggest working on inventory first. They should also consider their use cases and which workflow they want to implement. In the next release, they should have VMware tight interrogation.

We use it for the bot. It helps to keep tracking all the automation processes that are ongoing in your ecosystem

It helps with patching and keeping everything compliant.

Automation tracking is the most valuable feature. 

The SSM connection access needs improvement because right now, they do everything through SSH.

I have been Red Hat Ansible Automation Platform for a few years. 

The solution is very stable. 

If there's some cloud add ons, we would increase the usage. Only admins use the solution. 

We just create a server, and then we use that server to on-premesis.

Ansible has good performance. Overall, I rate the solution an eight out of ten. 

We use the solution for Linux patching automation. Currently, we are using the solution for patching normal configuration-related work. However, we also plan to use it for the provisioning of the servers.

The most valuable features of the solution are automation and patching.

The solution is slightly expensive, and its pricing could be improved.

I rate the solution ten out of ten for stability.

Red Hat Ansible Automation Platform is a scalable solution. Around 300 to 400 users are using the solution in our organization.

The solution’s technical support is very good.

The solution’s initial setup is very easy.

The solution can be deployed within a day if you have all the resources. To deploy the solution, you need to check if you have a proper infrastructure and everything in place.

Users with the right environment, like Linux, should go for Red Hat Ansible Automation Platform. With the Red Hat Ansible Automation Platform, we don't have to do manual things, increasing our efficiency. The solution helps us complete our complex work very easily, increasing efficiency.

Overall, I rate Red Hat Ansible Automation Platform ten out of ten.

We primarily use this solution for network configuration pushes. We use scripts from Ansible to push configurations to specific devices such as routers.

The best features are the orchestration and flexibility of the solution.

It would be helpful to have templates for common configurations. It would make it much easier and faster rather than creating a whole script. The templates would decrease the learning curve as well.

I've been working with Red Hat Ansible Automation Platform for a year.

Red Hat Ansible Automation Platform is quite stable. If you set it up correctly with the right configurations and there are no hiccups during installation and deployment, it will be stable.

I'd give stability a rating of eight out of ten.

It's a scalable solution. The capacity of the single instance is quite enough to hold up an enterprise. From a resilience perspective, you have to have a cluster that actually holds the whole thing.

On a scale from one to ten, I'd rate scalability at seven.

I would rate technical support at nine out of ten.

Positive

Once all of the components are in place, there are no issues with the initial setup. I would rate the initial deployment process at seven out of ten.

The deployment can take two days to a week depending on the requirements and resources available.

Red Hat Ansible Automation Platform is an expensive solution. There may be additional fees to use advanced features.

I would highly recommend Red Hat Ansible Automation Platform, especially to organizations that are moving toward a cloud or hybrid cloud infrastructure.

Overall, I would rate this solution at seven on a scale from one to ten.

The beauty of Ansible is the easy ramp-up to get started.  You really only need Python and SSH access. Configuration is generally done in YAML, which is easy to understand, and there is a progression from ad hoc tasks, to playbooks, then to roles, which means you can start with one server and continue building up to datacenters worth of servers with the same methodology. Also, shared by most configuration management tools, the idea of creating a desired state scales better than trying to specify procedural steps to set up new hosts. There are no agents by default, so adding a new server is a matter of a couple lines of configuration (on a new server and the configuration master).

There is some overhead in setting up the initial playbooks, but it now takes less time to set up 10 servers than it did to configure one in the past. Also, the setup is consistent because there is not the concern that someone forgot to copy/paste a config line or run another command. Whatever is in the playbook gets done.

Because Ansible is establishing SSH sessions to perform tasks, there is a limit on scalability. Speed and the sheer number of open connections start to become issues past a couple hundred servers. There are some workarounds, but that is a key area for improvement. Ansible could also improve support for private package repos, to ensure that new batches of servers are getting the same package versions as earlier batches.

I have been using Ansible for about two years.

SSH is pretty good, but it was not designed for the access pattern of hundreds of connections out of configuration targets. Other tools solve this with a listening agent process, so the initial connection to configure is much faster.

I have not used customer service. Ansible is well established, so there is plenty of documentation, examples, and third-party resources.

Manual configuration and "Golden" templates for virtual machines were used.  The former is tricky to maintain consistency with. The latter seemed to require constant updating and it did not help maintain the configuration of already installed servers.

Initial setup boils down to installing Ansible and ensuring you have SSH access to a target that is running Python. Standard packaging is available on major Linux distros to install some level of Ansible. I recommend following instructions on Ansible's site to get the latest stable release as they have been improving rapidly.

Not applicable.

Although Red Hat has an enterprise add-on to manage Ansible through a web application and offers commercial support, I have not used it. Like many Red Hat products, they have a no-cost version of the web application (AWX, formerly Ansible Tower), but you are on your own to install and it is a little more complicated than just installing Ansible. AWX will probably be required in most shops for the RBAC functionality. With AWX, non-admins can be limited to perform some tasks, but not be allowed free reign with Ansible.

Salt (or SaltStack) is a similar tool, but does have an agent. There are other tools like Chef or Puppet that use languages other than Python. Ansible was chosen based on these characteristics and the others were not evaluated after this initial choice.

I use the product mostly to configure virtual machines.

The solution helps us to have a standard configuration for all the virtual machines. It helps our virtual machines have the same configuration every time they restart. It also helps with automation.

The most valuable feature of the solution is that we don’t need an agent for it to work.

The product could do a better job at building infrastructure. 

The product should add a feature that alerts us if someone changes the configuration.

I have been using the solution for two years.

The product has high stability.

The solution has high scalability. It can be deployed on thousands of machines. Seven people in our organization use the solution.

The initial setup was straightforward.

We use the open-source version of the solution. The product can be used for free.

The tool should be used for server configuration but not for creating resources on the cloud. Overall, I rate the solution a seven out of ten.