Red Hat Ansible Automation Platform Reviews

We primarily use it for network automation and security or CVE resolution.

We save thousands of hours a year doing security updates and configuration updates. We save our administrator's time by pushing updates. It is a one-click solution, and all they have to do now is pull down whatever they need for their configs. It saves about 4,000 man hours a year.

If you imagine Tier 1, 2, and 3 administrators, I am sitting more at the Tier 3 level. We are able to push out more complicated configurations. We can do just an SSH push to thousands of devices. It saves the time of our administrators from having to go into the console of every device. They do not have to SSH into every device and manually type in those configs. We can resolve security issues within a matter of minutes rather than days.

You have the initial big push to get Ansible set up and running in the environment, but once it is there, any tweaks or changes involve just edits to the code base, and you are good to go. It is not at all intensive.

Red Hat Ansible Automation Platform has not reduced the training required to learn how to automate things. We are starting from scratch, so there is always going to be a learning curve associated with it. The more you peel that onion, the more involved it gets, and the more you have to learn about it.

Red Hat Ansible Automation Platform helps connect teams, such as developers, operations, or security so that they can automate together. It is hard to get anything done if all of those players are not talking. Knowledge bases are not siloed anymore. Previously, we did not have a cross-talk or sharing of information. Now that we have the platform, we have to share knowledge back and forth where we are pushing an update and they are telling us what is broken. There is constant feedback. There is a good feedback loop.

Red Hat Ansible Automation Platform has helped to reduce the time we spend on low-value or repetitive tasks. It is hard to quantify the time savings because of the mass scale at which we use it, but it would be within thousands of man hours a year.

My guess is that Red Hat Ansible Automation Platform has saved us costs, but I am not in a position to see those numbers.

When you have an enterprise-level number of network devices, the ability to quickly push out security updates to thousands of devices is the biggest thing.

At this time, I do not have anything to improve. What we struggle with is the knowledge base, but that is more about us having to go and find it and learn the platform on our own rather than an actual Ansible issue.

I have been using Red Hat Ansible Automation Platform for the last eight months. 

It is pretty good. Usually, if we have any issues, they are user-induced. When Ansible goes down or there is an issue like that, it is usually something we have done at the backend rather than Ansible itself.

It is very scalable. The way we use it is that we tie it in with another app to touch all of our devices and to deploy any configurations or whatever we need to push. Our code base sits on Git, and then we use another company for monitoring our devices. With one tower, or two for redundancy, we are able to push to more than 5,000 devices.

It has been good so far. There have been a few cases for which we reached out to them to get some help. I have not interacted with them personally, but I have heard good things. I would rate their support an eight out of ten.

Positive

I have not used any similar solution.

I was not there when we set it up. In terms of the deployment model, we still have one that is in the VM, and we are also using the containerized version. It is still Ansible Tower.

It has saved us thousands of man hours.

I was not there when we set it up. We have been using it for about four years. I am not sure about what happened before then.

I would rate Red Hat Ansible Automation Platform a nine out of ten.

So far, the main thing we've been doing with it is using it to automate our monthly patching of servers. Since we have the whole inventory, we can patch this project's servers. We can use the exclude, exclude others, and, in one hour, do a patch that would take people one night to do.

Managing our inventory is a big pain point. Right now, we have Satellite, but we can tie it in with Satellite, so we can actually manage things and automate the entire deployment stack, instead of trying to grab things from tickets, then generating Kickstart, and using that to get things in Satellite. That doesn't work well. We can do the whole deployment stack using the inventory share between Tower and Satellite.

I've been doing patching from the command line, but for other people, it's nice to have the Dashboard where they can see it, have it report to our ELK stack. It's far more convenient, and we can trigger it with API and schedules, which is better than doing it with a whole bunch of scripts.

• I like the inventory management. It's a very nice, simple, concise way to keep all that data together.
• The API allows us to use it even for things that are not Ansible.

On the Dashboard, when you view a template run, it shows all the output. There is a search filter, but it would be nice to able to select one server in that run and then see all that output from just that one server, instead of having to do the search on that one server and find the results. It would be nice to just be able to view per-server. Sometimes the server has some problems that we're going to find in some places. It would be nice not to have to search for them.

Less than one year.

We haven't had any issues with its stability or with bugs, so far.

I think it will meet our needs going forward. We're going to put, not a whole lot of servers, just 3,000 servers, and that's going to be spread out. We're going to do an HA Tower. Right now, we're only doing 350 servers for our trial runs. We haven't had any problems with that, we just keep them all up at once.

I actually haven't had to contact tech support on any issues. My colleagues have worked with them for OpenShift, but for Tower, we haven't had a reason yet.

I felt the setup was really straightforward. The set up is with the Ansible Playbook. I just skimmed through that and I found that it does everything I need. And then I just ran it.

I did an upgrade two weeks ago. That was simple: Download the new one, run it. I did a back up before, just in case, but everything went smoothly. No problems.

Puppet is the main configuration management we have right now. The goal is that Ansible will do all the administration and deployment, and do all things with a baseline, to meet our standards. Then Puppet is going to be taking care of a lot of the rest of the configuration for all the different projects.

Our company use the solution to automate IT for many government use cases. 

The solution is capable of integrating with many applications and devices in comparison to BigFix. 

The infrastructure and user controls are much easier to use than BigFix. 

Community support is always available so it is easy to get direct information. There is a lot of basic, enterprise-level, and governance-level support. 

The governance features could be improved. 

I have been using the solution for four years. 

The stability is okay for our project. 

Large organizations like us have workloads for 55,000 people so need enterprise-level features. We are with the government so we have a lot of important data. 

The solution is scalable up to a point. There are some issues at the enterprise level. 

Technical and virtual support are top notch in any issue. There is a lot of community support available at all levels. 

The initial setup was a bit complex. Some of the web addresses were not working on the technical or management levels. Our team was very focused on policies and secure environments. Our team level is different from company management. 

We implemented the solution in-house. 

The solution is inexpensive compared to other products. 

The solution is not the best fit at the enterprise level because there are issues with reporting and websites when handling 24,000 servers. In this scenario, I rate the solution a six out of ten. 

The solution is a good fit for smaller or medium-sized businesses with up to 10,000 servers. In this scenario, I rate the solution a nine out of ten. 

I use Red Hat Ansible Automation Platform for automating some administrative tasks. Specifically, I utilize it for system administration tasks.

Red Hat Ansible Automation Platform is valuable due to the simplicity of the YAML language. It makes it simple to develop Ansible playbooks and roles, which aids in simplifying my daily administrative tasks.

I would like to see improvements in the dashboards. More detailed dashboards would be beneficial because there is a lack of dashboards on Red Hat Ansible Automation Platform.

I have been using Red Hat Ansible Automation Platform for three years, while using satellites for about three or four years.

It was easy to set up Red Hat Ansible Automation Platform, not too complicated.

I have not really encountered any stability issues with Red Hat Ansible Automation Platform.

I have not tested the scalability of Red Hat Ansible Automation Platform, but I believe it is a mature product and can handle scalability.

I have not worked with other automation tools. Currently, I am only testing Red Hat Ansible Automation Platform.

The initial setup was easy. It took approximately one day.

I implemented the solution by myself, in-house.

I know Red Hat Ansible Automation Platform costs money since I am using a trial license. The pricing is high, and since I'm not using all functionalities, it would be better if the price depended on the functionalities used.

I did not evaluate any other solutions before going with Red Hat Ansible Automation Platform.

I rate Red Hat Ansible Automation Platform as seven out of ten.

On-premises

We mostly utilize Ansible for deployment automation and CI/CD pipelines.

I have used some of the Ansible libraries for some of the deployments. The way conditions are handled in Ansible, such as skip conditions or failure conditions, can be complex with multiple conditions, but there is support for using them. 

Additionally, the automation capabilities streamline deployment processes, providing reliability and reducing manual intervention and errors.

More library support for microservices architecture and Kubernetes would be helpful. There is also a need to improve the handling of conditions, which can be tricky and require the use of flags.

I have been working with Ansible for about six to seven years.

Ansible is quite stable. There are infrastructure-wise reliability and fewer issues, although network issues might cause some failures.

Ansible can face scalability issues, such as limitations when trying to scale up infrastructure. It might struggle with connection dropping or spawning additional VMs under certain conditions.

I have used both Ansible and Terraform. Ansible can lag when compared to Terraform for certain microservice deployments.

The initial setup can be challenging and is not very intuitive. A person needs to be knowledgeable in Ansible, and it should be well documented.

The benefits include the maintainability of the existing environment, especially a hybrid infrastructure. Ansible makes scripting and learning processes better and easier.

There is a pricing associated with Ansible, however, I find it reasonable.

I would recommend Ansible. That said, it depends on the infrastructure and whether an off-premises or on-premises cloud is used. 

I would rate Ansible between eight and nine.

Hybrid Cloud

Other

We can use it to configure or to change the configuration in a large number of servers. Also, if there are some issues in comprehension, for example, permission or ownership, we can fix that with the Ansible label. 

We can use other advanced features. Currently, for example, we are using BigFix for automation. We use Ansible since it doesn't need agents to install on every server. For BigFix, in contrast, you do need to have a BigFix agent for every server. Not having to do that with Ansible is a benefit for us.

The Ansible automation platform helps us achieve our goals. It is easier to handle and easier to understand. We can learn it easily, and we can share it with colleagues also very easily.

New colleagues and new people can understand the solution very well, making it quick for onboarding. 

It is easy to manage. If we make a playbook, we do need to have some skills in scripting or skills for the AML file. However, once we do, we can easily handle the issue.

We are just starting to use the solution. I can't speak to improvements, really. So far, I am more comfortable with this product than the previous one. Once we start using it heavily, maybe we will see issues.

I've been using the solution for one year.

The solution is stable. Some colleagues and other companies use it and comment that it is easy to use, easy to understand, and offers good features. They're very positive when discussing Ansible. 

The solution can scale. It can cover large amounts. Many other companies also use it successfully.

We have more than 600 Linux servers. We are using it on all the servers. 

We use Red Hat a lot. I open tickets for the Red Hat cases, however, with Ansible, I haven't opened any cases. My manager worked with them a bit.

If we have a problem with some file and we need to get Red Hat to analyze the issue and the file is 100GBs, we'll have an issue since we need to provide a log file for them to analyze. If it is around 12GB or 13GB, we can easily upload it to the Red Hat portal. With more than 100GBs, it will fail. I heard it should cover up to 250GB for an upload, however, I find it fails. Therefore, Red Hat needs to provide a way to handle this.

Positive

We also use BigFix. However, we need to have an agent on every server with BigFix, which is not the case with Ansible. 

Our manager had already implemented Ansible, and we were using it in the lab previously. In the lab, we saw it running very smoothly. Some of the production servers also use Ansible as well.

I was involved in the initial setup. I use it in the lab server for now, and it is good. It is going to be in production soon. However, we already deployed it in lower environments, like the QA and development servers.

We might see an ROI soon. 

Previously, we had BigFix and considered other solutions. However, when Ansible came in, and we studied it a bit, we felt that it would be easy to understand and easy to implement. The learning curve was small. 

We are a contractor of the client. We support the client, so whatever the client needs, we use and provide. Our client owns Red Hat, and therefore we use it.

Our operating system is Red Hat. We chose it due to the fact that it is open source. In Red Hat, we can use VMware or physical servers or the cloud and find Red Hat to be easy to use, secure, and user-friendly. Also, if we use all RHEL products, they are all compatible with each other. If we use a third party, we might have issues. With RHEL products, it is already tested on the RHEL side, so we don't generally see issues. 

It's one of the best products to use. It is easy to understand and easy to manage. You can use it if you have a cloud, physical server, or VMware. It is very good and offers operational efficiency.

I would rate the solution nine out of ten. We like it, and we feel good about its capabilities. 

Public Cloud

Microsoft Azure

We use it for any sort of automation. We started using Ansible about 18 months back. But then we realized, as we expanded Ansible, that we needed controls around it. We didn't want people just running around crazily running Playbooks. And that's where Tower came in. We bought licenses and it's kind of worked out, though we expect a lot more. I did have a meeting yesterday with the Product Manager for Tower. I did give some suggestions. It's worked out but we've got more expectations, and I hope they work out as well.

Some examples of the tasks we've automated include OS patching to begin with - everyone does that. We have been using Ansible and Tower for a lot of data collection, for auditing, collecting data from across different servers: network, OS, Windows, Linux, etc. That's one of our major automations. In addition, AWS and various clouds, if we have to spin something up.

We're not using it for compliance yet. I saw a demo about that yesterday and we'll probably explore that.

In terms of staff or the amount of effort involved, Ansible is great. That Tower uses Ansible is amazing. Creating Playbooks takes less time. Tower has its own features. If there were more that would be great. But because Tower uses Ansible, it's not a lot of effort and we can get things done quickly.

• The Organizations feature, where I can give clear silos and hand them over to different teams, that's amazing; everybody says that it's their own Tower. It's like they have their own Tower out there.
• RBAC is great around Organizations and I can use that backend as our lab.
• Ingesting stuff into the JSON logs, into any sort of logging collector; it works with Splunk and there are other collectors as well. It supports Sumo and that helps. I can go create reports in Sumo Logic.
• Workflows are an interesting feature. I can collect a lot of templates and create a workflow out of them. 
  
• Also, the fact that Tower exposes APIs so other Playbooks can consume the APIs, it does complement other programs we use internally.

We are not using the Dashboard a lot because we have higher expectations from it. The default Dashboard from Tower doesn't give that much information. We really want to get down into more than if the job succeeded or what was the percentage of success. We want to get down to task-level success. If, in a job, there are ten tasks, we want to see this task was a success, and this one was not, and how many were not. That's the kind of granularity we are looking for, that Tower does not give right now.

There could be more stuff in the workflows. I hope that if I have ten templates with different services on it, workflow could auto-populate all the template-based services.

One to three years.

It's definitely stable and reliable.

Regarding scalability, we had issues initially. The biggest issue we ran into is, while yes, the documentation says if you want to run on 100 machines you need to have this many CPUs and this much memory - and we started following that - if my job template has 50 tasks in it and I enable verbosity and I run it on 1,000 servers, I am out of memory right away. The moment I have to expand to 1,000 or 2,000 or 3,000 servers, I cannot run verbosity. That has been one of the major problems that we have faced.

Scalability-wise, if I'm not enabling the debug log, it's good. Normally I do that. I have to cut down the list, shorten the number of target hosts, and then I can enable debug. That's been a problem.

Technical support has been good with the limited number of things that are supported in Tower. The Tower modules are not supported by Red Hat, which was disappointing. If I have to do updates to Ansible Tower, not somewhere else, I have to call the API, look at the right JSON, and post the JSON. If I had the module, and I had the feature of the module, I could use it. Right now the modules available on community don't have all the features. If Red Hat was supporting it they would have added those features. So there are things that are still missing.

The initial setup was pretty straightforward.

In addition to the developers who use it most, we hand over job access to different teams. Security needs some data, we clear jobs for them, we hand it over to them. But most of it is with Operations and the Development team.

I rate it a seven out of ten because there are a couple of things which I expect from Tower which are not there yet. As I mentioned already, things like services being populated from templates, job tags are not there on workflows right now, I have to go to another tool like Splunk or Sumo or some other logging tool to look at graphs. If those were possible in Tower it would be amazing. Anybody could run a job and go and look at a graph and see what happened, instead of having to log into another tool. There are things which I think can be added to Tower, but it's a good tool.

We use Red Hat Ansible Automation Platform for the automation of our servers and applications. We also use both Terraform and Ansible to automate our infrastructure.

Red Hat Ansible Automation Platform has saved our time and reduced errors in our processes. It used to take us two months to provide a server in our organization, and now it only takes a few minutes to have the same server. Automation has ensured that tasks are done in the same way every time, reducing the likelihood of errors.

The capacity to install products on the operating system is very valuable. Ansible is better at handling the final configuration of servers. We prefer Terraform for creating multiple resources in a project, but Ansible is better for final configurations.

Ansible's centric idea of servers needs to be changed. In modern infrastructure, there are more than just servers. The initial server-centric approach in Ansible is a bit strange. It should improve its functionality with cloud resources like Azure, AWS, or Google Cloud. 

Ansible could also improve its capabilities in managing several resources at the same time, similar to Terraform. Moreover, more integration with other tools would be beneficial.

I have been using Red Hat Ansible Automation Platform for about three to four years.

The stability of Ansible is rated high, around eight to nine on a scale of ten.

We haven't experienced any problems with Ansible's scalability. We use it at the project level and create around ten to 20 resources. We haven't tested it with thousands of servers, so it's difficult to say how it would perform in such scenarios.

We are using the free version of Ansible, and so far, the support has been very high, considering that it is a free version. We are in discussions with Red Hat and IBM about possibly purchasing the commercial version when we start using Ansible for patching servers.

Positive

Before Ansible, we used BladeLogic from BMC. We switched to Ansible as it was easier to use, had more functionality, and there were more people in the market who knew Ansible compared to BladeLogic. Overall, Ansible is a much better product.

The setup of Ansible is easy. It's faster to start working with Terraform. However. Ansible's setup is also straightforward. The basic installation process is quick and effortless.

I recommend using both Ansible and Terraform for automation, especially now that both are under IBM.

I'd rate the solution eight out of ten.