Red Hat Ansible Automation Platform Reviews

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.

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.

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.

The primary use case is mostly automation. In technical terms, the solution uses a playbook. The playbooks contain code. If you have written all the code in the playbook, you just execute that code. You can automate depending on the environment.

The playbooks and the code the solution uses are quite useful.

It would be good to make the solution more user-friendly for customers who aren't skilled in coding and don't know how to use the playbook's code. If we have many customers and the modules already exist, the user can just plug and play.

I have been using the solution for one year.

We don't have many issues with stability, so I rate the solution's stability a nine out of ten.

I rate the solution's scalability a nine out of ten. We have two customers using the solution.

The technical support is good.

The initial setup is complex, and OpenShift would be much easier. It took a week to deploy the solution. When deploying the solution, you must download the installer and install the solution on the server.

It requires two engineers for maintenance and deployment.

Customers need to pay yearly for the license. The pricing is acceptable. It is not expensive.

If you know the basics of coding for you to write the playbook's code, and if you have a midrange environment with up to 1,000 servers, Red Hat Ansible Automation Platform is a good option to automate daily tasks.

I rate the solution a seven out of ten.

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 to configure operating systems, apply security, and for day-to-day management. Our use cases include collecting information from end nodes, rather than writing shell scripts or any other types of scripts, as was done historically, and rather than even logging in manually and collecting information from the nodes. These days, you write an Ansible playbook and it does things for you. And if you don't have a playbook, you can simply gather the facts from the nodes, and that's available out-of-the-box without writing anything. You simply utilize the Ansible modules.

Our Ansible deployment is for a hybrid environment. We have on-premises services that we use Ansible to configure as well as cloud instances.

Historically, lots of things had to be orchestrated manually. There weren't any great tools to do configuration management across multiple nodes. IT servers were physical but then moved into virtual, and with that change came the need to manage more and more nodes. It became quite time-consuming, and employing people to manage hundreds or thousands of servers wasn't really a great solution. Ansible, as an orchestrator, has filled the gap. It allows you to manage an almost unlimited number of nodes with a single body. That has been a great improvement in the way organizations manage their estates.

In addition, we're able to configure or deliver something to our end nodes step-by-step. You can have dependencies, types of conditions, between steps. For example, if something isn't present or it's not happening on that node, you can skip steps and move to another one. This ability definitely helps. In the past, a lot of things had to be done manually or with a semi-manual script. Ansible automates those things. As long as you've got your playbook written up and tested correctly, you can run it with confidence against your production system.

Ansible also saves us time when it comes to service deployment, moves, and updates. If we consider the effort involved in writing playbooks, and the effort to deploy them, Ansible saves 80 to 90 percent when it comes to the time involved in these scenarios.

Another advantage is that Ansible enables collaboration across teams. We're transparent. Whatever we deliver needs to be backed by the code. That code lives in source control. Anybody who is capable and wants to could grab that code. Playbooks are an example. They could simply apply them against the target. This is a form of collaboration, where one person does something and another can grab it and use it. Obviously you need source control, but multiple people can work on a specific project together and can have influence on that project, providing updates, features, and bug fixes to the project.

We have certainly seen an improvement in automation. With Ansible, you can pretty much automate everything. You work on a desired state. And we have been able to apply current, modern security standards to the estates. From a security perspective, our servers are now fully compliant with modern security standards. We are able to use Ansible to run some benchmarks against them to see if they're fully compliant.

Being a game-changer in configuration management software is what has made Ansible so popular and widespread. Much of IT is based on SSH direct connectivity with a need for running infrastructure in an agentless way, and that has been a big plus. SSH has become a great security standard for managing servers. The whole thing has really become an out-of-the-box solution for managing a Unix estate. Managing a Windows or Microsoft estate via Ansible is a little bit different and I believe that requires the installation of some agents.

Another advantage is that Ansible did not require us to change our existing infrastructure in any way. This issue ties in with the SSH connectivity. You don't have to prepare any infrastructure to use Ansible. When you provision an operating system, that SSH remote connection is available. It's embedded in the operating system. That means you don't have to enable anything. All you have to do is make sure you can reach the nodes, either via SSH, passwordless authentication, or possibly other mechanisms. We've only been using SSH, and it does the job very well.

Some of the modules in Ansible could be a bit more mature. There is still a little room for further development. Some performance aspects could be improved, perhaps in the form of parallelism within Ansible. 

Also, some of the Ansible versioning or backward compatibility, or Python changes, could have been handled a little bit better. 

But all these challenges could potentially be offset by the way you use Ansible. For instance, you could have Ansible Docker-ized and that would make your Ansible environment fixed and static and fully controlled. That way you wouldn't be worried about your server or your local workstation that is used for deployment.

These aren't huge issues, they are just things to keep in mind, but it all depends on how you use the product.

I have been using Ansible for a good few years. I started five to seven years ago, by first writing Ansible playbooks, simply to orchestrate configuration management of the estate at that time. I was mainly using it on Linux servers.

The stability of Ansible is great. Historically, we have had some compatibility issues, such as during a Python change a library had to be downgraded. Other than that kind of minor issue, the product has been very stable.

It's quite scalable. I don't think there are huge limits in terms of what you can do. I have not run any performance benchmarks for Ansible. I don't know how long it would take to upgrade 10,000 nodes compared to competitors. But I feel Ansible could be nicely scalable. An orchestrator would allow you to simply have Ansible containers, perhaps on Kubernetes, and they would run something against the nodes. Having multiple Ansible nodes, or multiple pods of Ansible containers, running code against targets in parallel, would be a scenario in which I could hardly imagine any limits.

We are managing between 1,000 to 2,000 servers.

My team is more of a development team, so we don't run Ansible on a daily basis for operations. We mostly program or develop robots that run Ansible when needed. As for other teams, I'm not sure how they use it, but whenever they need to collect something from these hosts or need to quickly push a similar update to all hosts, I think they would use Ansible. While it's not being used on a daily basis in our organization, it's certainly being used.

The typical Red Hat support, the kind you access via their portal or email, can vary. Sometimes things are not done as quickly as you would want, but it's standard support and you get what you pay for. Moving up a level, if you were to get TAM support, things would improve a bit because you get dedicated technical contacts with whom you speak on a weekly basis. They help push things along. However, you're still tied to the Red Hat backlog and its engineering, which is not always the fastest. Often they have a different view and different priorities. We have had some cases where they have simply said, "We're not delivering this. We're not doing this," but they did not provide a rationale as to why. 

Overall, the results are mixed when it comes to support. It's not that bad, but there's room for improvement.

Neutral

I've used Puppet a little bit, but I quickly moved into Ansible as it became a standard over Puppet, Chef, and perhaps SaltStack. We moved quickly into Ansible. When Ansible was acquired by Red Hat, it quickly became a very interesting product. The first bullet point was the agentless infrastructure for Ansible.

Red Hat's open-source approach was also a factor for me, certainly. I'm an open-source enthusiast. It's a big plus that Ansible is an open-source project, and it's free. They gained popularity from that as well.

When you need to use Ansible, you need to grab the Ansible binary. A typical method in Linux would be to use the Package Manager to install it. You could also use a Python-native method for installing it through pip.

Another good method would be to simply get your Ansible Docker-ized or pull a Docker image from a third-party repository and that image would have Ansible deployed in it. That way, every time you need to run Ansible, you could just an image and that image would provide the binary for Ansible.

The next step is related to your particular use case, what you need to use and how you need to use it. For example, if you want to write a small portion that does something, you simply instruct Ansible to use that code against the targets. By "targets" I mean you need to provide an inventory that you want to run your code against.

Another step that needs to happen in order to use Ansible nicely is to set up passwordless authentication to use SSH keys instead of passwords. That's what should probably happen together with installing or delivering Ansible binaries. Once you have these elements, binaries and authentication, your system is pretty much ready to be configured through Ansible.

Because I'm quite senior and specialized in Red Hat and, in general, a Linux expert, deploying Ansible literally takes me minutes.

Implementation strategy would vary from case to case, but one of the popular ways of deploying Ansible is to have a bastion host that allows you to access your estates over SSH keys and simply have Ansible running from that host. Ideally, you would like to see what Ansible is changing on every run so a good practice would be to have CI/CD orchestration for Ansible, using Jenkins or another CI/CD tool that allows you to keep historical logs on how Ansible behaves, and what has changed in an estate during an Ansible run. That would be the minimal implementation I would suggest for an organization.

We're not paying for it, but if you were to buy it, you would get Ansible Tower. That is what they are charging for, if I recall correctly.

Ansible seems to have been quite well received. There are competitors, or there were when I started using it several years ago, but Red Hat, with community development, has become the easiest to use, compared to Puppet or Chef. That is how Ansible gained popularity across the IT market.

Another element in why Ansible became so popular is the way things are being pushed to the end nodes. We're using existing SSH connectivity, which is a common way to manage Unix servers. That became available out-of-the-box. The competitors usually ask you to install agents and that brings with it challenges, such as how to orchestrate installing agents. Ansible does not suffer from that problem. Every Unix server must have SSH enabled by default and Ansible simply uses that.

It's a great tool. It's easy to use. Do your own research and run a spike to compare Ansible with competitors and simply pick whatever suits you. But a great plus for Ansible is its simplicity.

For doing basic things, or things Ansible was designed for, you probably don't need special coding skills. All you likely need to know is how to properly structure a YAML file, and YAML is now a common language across development. However, if you were to do things that are a little bit more advanced in Ansible, Python would be something that you would want to study or be good at. That would help you write custom Ansible modules or provide further input into existing development to improve them or deliver additional bug fixes and features.

We spike the open-source version of Ansible Tower, and Tower is not difficult to learn if you have experience with Ansible and with Unix. Deployment of it is relatively easy. We have not found a great use case for it, to be honest. At that time, it was more for compliance and, maybe, a Chrome-job type of product, and we had the orchestration for that already.

When it comes to SLAs, I don't think Ansible has created a great change for us. Once you achieve a certain level of automation in an organization, you're probably not going to feel any changes when it comes to SLAs because you have already built that capability. Our SLAs are well maintained and are at a high standard, but I don't feel Ansible has had a huge influence on them because we were mature in that area. But perhaps for some organizations, it would have a significant effect on what they offer. Being able to do more via automation means services are up more than they might have been.

We are using other Red Hat solutions in our environment, including Red Hat Enterprise Linux, Red Hat OpenShift, Red Hat Satellite, and we have also used Red Hat Virtualization. All of these products integrate nicely with Ansible. It's mainly because they're fully backed by variations or just pure Red Hat Enterprise Linux. The integration is great. Whatever you can do on Linux, can probably be done on any other Red Hat products that are based on similar technology. There are no limits.

We use the solution for provisioning on different providers like VMware, and OpenStack because it was so easy to implement. This product is also helpful to create a job workflow including the approval steps.

It also includes DevOps tools for making an easy automation process. 

It brings a lot of time-saving.

The API for exposing all our infrastructure services is the most valuable feature.

I have been using Red Hat Ansible Automation Platform for three months.

It is a stable solution.

It is a scalable solution.

The technical support is very good. We asked the support team about applications, and they answered us. I rate the technical support a nine out of ten.

Positive

We used multiple tools in the past three years, but we did not use any other similar product to Red Hat Ansible Automation Platform.

The initial setup was easy. I was not a part of the deployment process, but my team members told me about the deployment process.

The in-house team asked the support team questions.

It is an open source product but needs a license subscription to use it. The price depends on the number of nodes supported by the platform (the nodes correspond to a host which can be for example a VM or a data center).

The price is really different depending on the customer's needs.

We have evaluated other solutions but this is the one that best meets our need for provisioning automation and addresses the different infrastructure and cloud providers we use

The product can be very easy to use, provided what you are using in it. I did not use the product myself, but it was really impressive when they showed the POC process. I rate it eight out of ten.

We can use the solution for a group deployment if we have an infrastructure where we need to deploy software onto multiple machines at the same time. The tool should be on an Ansible server, and the server should be able to do SSH to the multiple hosts on which it wants to act.

We can automate a few host configurations using the product.

The solution must be made easier to configure.

I have been using the solution for almost five months. I am using the latest version of the solution.

The product is very stable.

The product is scalable. We can use it on multiple cluster levels.

The documentation is quite good. We don’t need to call anyone.

The initial setup is quite easy. The deployment took 15 to 30 minutes. The tool was deployed on a Linux machine. People deploying the solution must have some hands-on experience in Linux.

It’s an open-source tool.

I recommend the solution to others. Overall, I rate the solution a nine out of ten.

Our company uses the solution for clients with private or multi-cloud platforms. The solution automates the process of integrating multi-cloud applications. 

We have more than 1,000 users across our clients. 

The automation manager is very good and makes things easier for customers with multi-cloud platforms. 

Additional features could be added. 

I have been using the solution for two years. 

The solution is stable. 

The solution is scalable and you can go from 100 to 3,000 users with no issues. 

I did not previously use another solution. 

The setup is very easy.

Management is a bit different day to day as you automate. It takes time to realize all the benefits. Two staff people can easily manage the solution. 

We replaced our partner server with SaaS.

The pricing is pretty standard. 

I am very picky about using the solution. For my client base, there are many benefits to use. The solution is the continuous choice. 

I rate the solution a ten out of ten.