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.

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.

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.

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.

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. 

We use the Red Hat Ansible Automation Platform to configure our infrastructure. It is mainly used to configure the whole activity.

Red Hat Ansible Automation Platform is a good choice when you have different distribution platforms. If you have an infrastructure with Ubuntu, VPN, and Red Hat distributions, Ansible can integrate these platforms through a small inventory file, such as a custom image or file.

The role-based access control (RBAC) feature is the most valuable, especially when used with Azure Galaxy Infinity.

Ansible is good at managing applications or devices on the existing infrastructure but cannot provision those devices.

The tool should allow us to create infrastructure. It has everything when it comes to management, but it lacks the provisioning aspect.

I have been using the Red Hat Ansible Automation Platform for three years. We're using the latest version of the solution

The solution’s stability is good. I rate it a ten out of ten.

I rate the solution’s scalability a ten out of ten.

The customer service and support are good. It is good if you know how to create and operate it, but it can be difficult for someone who does not have the knowledge of how to configure the YAML file. There is some technical difficulty here. 

Positive

The initial setup is straightforward.

We have seen an ROI as we are still using the Red Hat Ansible Automation Platform.

The pricing is okay.  

I would definitely recommend using the solution. Overall, I rate the solution a nine out of ten.

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.

We are primarily using Ansible for automation purposes as it is a configuration management tool. It is utilized for various activities such as DNS activity, changes to web servers, virtual host settings, and other day-to-day tasks, all of which are templated in Ansible.

Ansible allows us to manage a multitude of servers efficiently. We can deploy configurations and changes effectively and gather detailed reports. This means we have substantial control and flexibility in managing our servers.

I can do anything with Ansible. It allows control over thousands of servers, whether virtual or physical. The flexibility to manage deployments, configuration changes, and reporting is highly valuable. Ansible is containerized, making it easy to pull updated containers for automation.

There are challenges in using the graphical interface, particularly in open-source versions. The Subscription model presents some limitations, and there is room for improvement in making the Ansible navigator more flexible for open-source use. Installation can also be challenging, especially for graphical components.

I have been working with Ansible since 2012.

Ansible is very stable. There are no issues concerning the system's stability when managed with Ansible.

Ansible provides fantastic scalability. This tool allows us to manage a significant number of clients without limitations, making it suitable for large-scale operations.

I rate Red Hat's customer support for Ansible at nine points out of ten. Customer support for Ansible is excellent, and any issues we have encountered have been resolved promptly.

Positive

Setting up Ansible is relatively straightforward. Installing the core product takes about thirty minutes to an hour. However, fully setting up Ansible with additional servers might take around two to three hours.

The implementation is handled by myself and one other colleague.

There is a need for more flexibility in the subscription model, but I do not have detailed insights into the pricing and licensing setup.

I'd rate the solution nine out of ten.