Red Hat Ansible Automation Platform Reviews

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 it for patching and configuration management.

We are a healthcare institution. We have less than 500 hosts. Ansible is used between the infrastructure and applications, and primarily has Red Hat as the OS.

It has improved our organization through provisioning and security hardening. When we do get a new VM, we have been able to bring on a provisioned machine in less than a day. This morning alone, I provisioned two machines within an hour. I am talking about hardening, installing antivirus software on it, and creating user accounts because the Playbooks were predesigned. From the time we got the servers to the actual hand-off, it takes less than an hour. We are talking about having the servers actually authenticate Red Hat Satellites and run the yum updates. All of that can be done within an hour.

• Ad-hoc commands
• Playbooks
• Setting up and deleting users
• Patching
• Using it for quick and dirty deployment of scripts.
  

The YAML syntax is easy to use, but it takes some getting used to. I feel like Microsoft Visual Studio helps with the YAML syntax, lining it up correctly. However, if you're doing it from the command line without actual spacing, that could be a little problematic. The new version of Visual Studio is quite helpful because Git is integrated with it. The YAML markdowns are also in place. My staff doesn't need special coding skills to use it.

We have multiple Playbooks to configure a server. We can break it up or make one main YAML script to push out all the individual dependencies.

When you set up Playbooks, I may have one version of the Playbook, but another member of the team may have a different vision, and we will not know which version is correct. We want to have one central repository for managing the different versions of Playbooks, so we can have better collaboration among team members. This is our use case for using Git version control.

Collaboration across teams is a great goal to accomplish, but that would necessitate more visibility to other teams of what Ansible is capable of with the database teams and other individual applications. Because we have so many applications, I don't know if they are aware of how Ansible could be beneficial to them. That would necessitate a broader conversation within the IT infrastructure application teams.

While it saves time with fewer moves, there could be still room for improvement because we do not actually manage the VMs. Instead, this is managed by the Windows team, who spins up the VM. Then, once the VM is handed off, we do the security hardening. If we received the request from the application owner to spin up the VM to hand it off, then we could take that entire process and get it streamlined. Whereas, it is handled by a different team right now.

It would be great if we could leverage Ansible Tower and Red Hat Satellites more. 

API integration would help because right now our security team uses Splunk, and they are independent of my team, which is the Unix team. Therefore, if we could tie in Splunk with products, like Ansible, Cylance, and Rubrik for backup, then we could get all that information in a central console. We have not previously raised this suggestion because our Ansible Engine needs to be upgraded so we can get support for the Ansible product.

We have been using Ansible for at least four years.

We have not had any issues with Ansible. One of the projects that we have allocated for this year is to migrate our control station from RHEL 6 to RHEL 7.

We really don't have anyone maintaining it. It was a plug and play solution. We downloaded Ansible and ran it, because everyone knows how to use Ansible on the team at this point. Right now, I am trying to get to the next phase of using Git to set up more version control.

The scalability is excellent.

Four guys use it on the Unix team.

We were previously using Bash scripting. 

We did try BigFix for two years. However, because of costs, Ansible proved to be better cost-wise. The licensing fee was a big issue with using BigFix. Control from the BigFix perspective was a concern, because you were locked into the GUI. With Ansible, we were able to do everything from the command line and touch the entire environment from the command line. Once you use BigFix and an issue, you then have to log out or go into the box from one of the servers, but you were locked into the GUI in BigFix.

It is agentless. All we had to do is set up the control station, then Python was installed on all our Linux hosts. So, it was easy. The deployment took less than an hour.

The SSH keys were already in place. We already had the account, where we tested it out beforehand. Therefore, we knew exactly what we needed to do to deploy it. The keys were the hardest thing to set up and that was already in place (prior to Ansible).

The entire Linux group of four guys was involved in the deployment. We never had to use Red Hat resources to set up Ansible.

Ansible is primarily used for provisioning or hardening our servers. The realization of getting a server from testing to actual production is very short in our environment because the processes have been streamlined. Before Ansible, the processes were a lot more unwieldy. We went from a week to less than a day where you can get your server hardened, provisioned, and handed off to the application owner.

Costs are negligible when using Ansible. The costs are just learning to use the solution's various options. We save time and efficiency versus other solutions.

We have tested out Ansible Tower, but there is a budget issue, so that is in our next phase.

Red Hat's open source approach was a factor when choosing Ansible, since the solution is free as of right now.

We have Red Hat Satellites and looked into Red Hat Insights, which we are still not fully deployed on yet. The integration between Red Hat solutions is seamless.

We looked into BigFix. I also looked at SaltStack and Puppet, but didn't get anywhere with that. I wanted something that had ease from a management perspective. Other solutions besides Ansible needed us to use agents, and I felt that would cause too many problems. Management didn't want a disruption of servers or downtime. I couldn't give them the assurance that installing something with an agent would not cause issues. So, this affected our decision to go with Ansible.

I don't think any product that we looked into could compare to Ansible.

Test the environment because it is easy to use. Once you are proficient with Unix and Linux, it is extremely easy to use it: Setting up the inventory system, YAML files, and SSH keys.

I have no complaints about Ansible. I just wish I had more time to really delve into it.

I think we not using Ansible to its fullest potential, because of:

1. Training.
2. Time.
3. Not knowing all the options available.

I haven't been exposed to Ansible Tower much. I have only tested it out three times. Right now, I am a little rusty on it, so it will take some getting used to again. It is more GUI-based, so it is pretty user-friendly.

The biggest lesson learnt: There are multiple ways of doing the same thing.

I would rate this solution as a nine (out of 10) because of the configuration management for all our servers in the environment. It can be used within the networking field for all devices, such as Cisco switches. The solution speaks to Windows hosts as well. It just takes time to use all the functionality and get it visible across the organization.

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

It helps with patching and keeping everything compliant.

Automation tracking is the most valuable feature. 

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

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

The solution is very stable. 

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

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

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

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 use it mostly for remote execution.

The most valuable feature of Ansible is repeatability because when you're working at the DoD, you want things to be cookie-cutter and replicable.

Red Hat Ansible Automation Platform helps us achieve our mission because it's easy to write.

The Red Hat solutions fit together pretty well and work in conjunction with one another.

Networking needs to be improved.

I've been using Ansible for at least a year.

As long as it can communicate with the target, there's usually no problem with the stability.

We used Puppet and switched to Ansible because it's an agentless solution.

On a scale from one to ten, I would rate this solution at nine.

We primarily use the solution for automation purposes. We also use it for CI/CD plus DevOps. So these are the three main uses. We can use it for operational automation plus DevOps. We handle applications, pipelines, deployments, et cetera.

With this solution, we're able to cover our client's needs. 

The automation is very good. The operational automation and DevOps are the most valuable features for us. 

It's easy to set up.

The solution can scale.

It's very stable. 

Now, there is a GitHub solution that came on the market. GitHub's integration with Ansible is adding value for the customer as GitHub has the capability to push/pull architecture plus it can bring in collaboration and versioning. As long as they continue to develop this integration, it will continue to be useful. What is next is to look into the infrastructure.

The improvement is already there in GitHub's capability. GitHub is already there, however, they can bring something like that into the solution as well too. They can bring AOPs capability. They should think of this product as an end-to-end solution and begin to develop it that way. 

The solution costs a lot. It's not cheap.

I've been using the solution for the last four years. 

The solution is extremely stable. that's why so many organizations end up using it. There are no bugs or glitches. It doesn't crash or freeze. It's reliable. 

The solution can scale well. It works for small or large enterprises. There is no limitation. 

Technical support has been good. We are very satisfied with the level of service we get. They are continuously improving their services as well. As long as they continue to improve we will remain happy.

Positive

The solution is very straightforward. It's easy to set up. It's not difficult at all. 

How many engineers you need to handle the implementation depends on the project and use case. It depends, for example, on how many automations will be created, et cetera. The time it takes to deploy also varies. Different use cases have different deployment times. 

Our company provides the implementation for our clients. We are able to handle the setup ourselves. 

We've seen an ROI. It is reducing the resources needed by the customers.

It's an expensive product. It's costly. 

We're charged between $8 to $13 a month per license. There are some limitations as well, however, specifically in AOPs.

We're partners. 

Which version we use depends on the customer If they have a license the latest is fine. We can also work with an older version. Whatever's possible we can do. We have the list of the scripts available, which can help us do the automation for the customer.

It's on the cloud we utilize Azure and AWS. It can also be used on-premises.

It's an effective tool. We weren't sure about it at first, however, it helps reduce resources and has been helpful to customers. 

I'd rate it an eight out of ten. 

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

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

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

I rate the solution ten out of ten for stability.

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

The solution’s technical support is very good.

The solution’s initial setup is very easy.

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

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

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

We use the Red Hat Ansible Automation Platform for infrastructure provisioning as well as application deployment on Kubernetes and virtual machines.

We don't use Tower very often. We are currently primarily using the Ansible Playbook.

There are new modules available, which help to simplify the workflow. That is what we like about it.

When compared to Terraform, the execution speed of Ansible is very slow due to the way it executes things.

Improvements should be made in terms of execution speed, which is, I believe, the most lacking feature. Aside from that, re-triggering a failed task is another useful feature.

I have been working with the Red Hat Ansible Automation Platform for approximately one year.

I don't remember the exact version we're working with, but it's N-1.

Red Hat Ansible Automation Platform is a stable solution.

I've had no issues with the scalability of the Red Hat Ansible Automation Platform.

Our organization has four to five administrators who use this solution.

We have contacted technical support. I would rate them a four out of five.

Positive

We are also using Terraform.

The initial setup is quite straightforward.

This solution does not require specific maintenance.

The deployment was done in-house.

The cost is determined by the number of endpoints.

A license is required, if you are using Tower, we don't use it very often.

It is slower than other solutions.

Terraform is better for infrastructure provisioning. However, once the infrastructure is provisioned, we don't see any alternatives to Ansible.

I have a partnership with Red Hat.

It's clear and simple, and there's plenty of help available.

I would rate the Red Hat Ansible Automation Platform an eight out of ten.