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.

My use cases with Ansible include configuring network devices. That is what I used it for when I was first learning Ansible. I then automated PKI (public key infrastructure) compliance. That particular domain has different servers and I developed an automation solution, using Ansible, to automate the configuration of the PKI servers. And for the last eight or nine months, I have been working on automating cloud solutions, such as deploying services or upgrading or migrating to a specific version of a product.

I am working on a client network, and that client also has clients who are hiring our client for hosted services, such as websites or internal applications for their employees or for their end-users. All the database-related activities and operations are being handled by our client. What I am doing, in that context, has to do with patches. There are patch releases, or bundles, or package upgrades, but the developers of those packages can't go and directly upgrade the particular sites of every customer. So we have developed an automation solution for them, using Ansible, that can directly trigger these processes. They can point out that "this is the package," and our automation in the backend, using Ansible, takes care of it.

It's a tool to automate different domains and Ansible can reduce human efforts for two domains in particular. One is DevOps and the other is network automation.

It's a total automation tool. Where you might need 100 employees to do a certain type of work manually, by developing Ansible modules, that type of work can be done by one employee. It just requires a simple SSH to the target nodes and then you can do whatever you want.

We had a scenario, the public key infrastructure project, in which there were multiple components. Some of my colleagues had automated some domains, such as a firewall domain. We then needed to integrate components, the firewall servers and the PKI servers, so that they could communicate with each other, and for security purposes. Ansible helped with that.

When you compare a process done by Ansible with human effort, there is a large time-reduction ratio. In a scenario involving networking, if it is done manually, the human effort will involve logging in to the system, entering user credentials, installing software, and configuring it to make the system ready. If there are 100 such systems, we would need to do the same process to all 100 systems, one by one. Whereas with Ansible, you just need to configure the IP addresses of those systems and, with one click, your job is done.

And when we integrate Ansible with a CI/CD tool, like Jenkins or Bitbucket, that reduces service deployment time by more than one hour. Also, we have site deployment where we require multiple servers. For example, when we have a database server, it needs many other components as well. When we deploy all those services manually, using a UI or a console in the cloud, it takes more than 10 hours to deploy one site. With Ansible, we automate that task once and it can do it in an hour, and the site will be provisioned successfully.

One of the most valuable features is that Ansible is agentless. It does not have dependencies, other than Python, which is very generic in terms of dependencies for all systems and for any environment. Being agentless, Ansible is very convenient for everything.

If you are good at Python and willing to customize Ansible modules, you can develop Ansible modules and, at one go, you can automate whatever you want.

When I started learning Ansible, I didn't know Python or any other programming language. But even so, I was easily able to understand what Ansible is doing and how I should write a playbook so that Ansible executes its tasks properly and the results are met, per my requirements. It's a simple English language and YAML script. Even folks with a non-IT background can write Ansible playbooks.

I have also been using Ansible Tower for about six months. It is nothing but a GUI version of, or experience with, Ansible. Ansible itself is a simple CLI tool, but with Ansible Tower there is a GUI, similar to Windows and Linux. There are a number of Ansible Tower servers, so if you want to run playbooks on multiple systems or you want to run multiple playbooks at the same time, you can do so using Ansible Tower. It is very dynamic. It's very easy to use. Even a non-IT employee or a non-IT student can understand Ansible Tower. The UI is very simple. Moreover, it has LDAP, Active Directory, and many other integrations, by default.

Suppose you have set something up, that you have pushed some code to the repo. Even your colleagues can test it using Ansible Tower. Or suppose I have run an Ansible Tower job and I am facing an issue with it. I can give a colleague the job ID and ask them to have a look and help me resolve it. That type of process is very easy, as Ansible Tower is like a common infra for employees to work together. 

Ansible Tower provides a central solution for automation. For example, in the previous project I worked on, we were automating some domains. Then we provided the sandbox URLs to the client for them to test whether the code the vendor had provided was working properly. They were able to run it in different ways with Ansible Tower. They used the Ansible Tower jobs with which we tested things for reference. Ansible Tower is a kind of UI dashboard for Ansible end-users. That is an added advantage of Ansible Tower: Whatever Tower jobs you have run are saved in Ansible Tower.

The area which I feel can be improved is the custom modules. For example, there are something like 106 official modules available in the Ansible library. A year ago, that number was somewhere around 58. While Ansible is improving day by day, this can be improved more. For instance, when you need to configure in the cloud, you need to write up a module for that.

I have been using Ansible for approximately one and a half years.

I believe no other tool can match the stability of Ansible. It is an agentless tool; it is SSH. Other comparable tools, like Puppet, Salt, and Chef, all require some kind of agent on the target node. Ansible only requires a Python dependency, which is very common in any operating system.

It's very scalable. If there were a graph showing scalability, Ansible would be at the peak on that graph.

I have not used Red Hat's technical support specifically for Ansible, but when learning Ansible I used their partner program and I felt it was the best.

When I started in automation, Ansible was the first tool I used.

The initial setup of Ansible is very straightforward. There are no dependencies. You just run a simple, single line command and your Ansible is ready. It hardly takes two minutes.

If you only need to use Ansible, it's free for any end-user, but when you require Ansible Tower, you need to pay per Ansible Tower server.

Apart from the fact that Ansible is agentless and open source, it's the best because you only require an IP and the credentials of any target server, and half of your work is done.

Ansible is an open-source tool, so it can be integrated with any of the cloud services, including AWS, Google Cloud Platform, Azure, very easily.

Based on my experience, I would suggest that anyone starting out with Ansible be familiar with SSH commands and Linux administration. That should be more than enough for Ansible beginners.

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. 

We use Ansible for infrastructure code. We also use CloudFormation. 

Ansible provides a central solution for automation for our customers.

We deploy this solution on AWS. We are a cloud company so that is why we don't have anything on-premises. We prefer a cloud approach, and we have almost everything in GCP or in AWS. The solution hasn't required us to change our existing infrastructure. We are using the server version 17. We use Ansible plus Ansible Tower, which is Ansible AWS.

The solution is user-friendly for our staff, although some activities are unique and are not being repeated several times, so we need to do those things manually.

We have around 25 people doing this same job. Before using this solution, we had more than 100 people for the same amount of work. This solution has definitely helped us to reduce and optimize our efforts.

One of the most valuable features is automation. We are doing automation infrastructure, which allows us to automate regular tasks. This solution provides us with a service catalog, like building new services and automating daily tasks.

The language is very intuitive. The solution is easy to learn. The solution enables us to deliver incrementally. We are able to expand this facility by implementing more templates and using them digitally.

We are an international company, so we use this solution with a collaborative approach internationally. 

The solution enables us to enforce the same security settings, so it's quite easy to maintain. There can be human mistakes, which can make security unreliable, so that is why we prefer this security policy.

We would like support for the post-integration of this product before cloud frameworks because right now their approach is to avoid using on-premises activities and move everything to the cloud. This is why we choose Ansible, but we would like Ansible to stay as close as possible to recent trends coming through AWS, for instance. We have a chance to automate those processes by using Ansible, so there is interoperability of those products.

I have been using this solution since 2015.

The solution is stable.

The solution has reduced the amount of downtime for users. It can automate some maintenance activities, which are out of operating time. If those activities can be automated, that can dramatically reduce downtime. If those activities can't be re-automated, then it's semi-automated, which would mean human effort plus automation together. In general, yes, we can automate maintenance or downtime activities, but that depends on the input for this. If there is some sort of disaster, then there would be a different approach.

Technical support is very good, especially from Red Hat.

We have used Red Hat Satellite and Red Hat CloudFormation.

CloudFormation is like a showcase of our service catalogs. We provide that to our customers. It's tightly integrated with Ansible and frameworks. The customer can choose from the service catalog, and if it's automated, the customer can see how much it was from a cost point of view. CloudFormation reduces work activities on the ground.

Initial setup was complex.

To deploy everything from the Red Hat portfolio took one week per customer.

Our strategy combines very closely with cloud, which is why our approach is complex. We are trying to persuade and migrate customers to the cloud, AWS, or GCP, and as an additional value, we can automate and more or less migrate it to an environment to bring new approaches and make this cloud solution beneficial to customers.

Yes. We saw ROI three or four years after implementing the solution.

You don't need to buy agents on servers or deploy expense management when using the solution, which affected our decision to go with it.

We also bought this solution because it was better than some competitors, like Puppet and Chef, and because of the automation.

It has helped our organization save time when it comes to service deployment, moves, and updates. We used to have 120 employees, and now we have just 25 for the same amount of activities.

I would give this solution 10 out of 10. 

The lesson I've learned is that automation is the way because without automation, it's quite impossible right now to maintain a very large environment, especially in public clouds like AWS or GCP.

We're quite unique because we use the public cloud environment together with one product.

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.

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.