Red Hat Ansible Automation Platform Reviews

We had a lot of manual labor. We had patching that was a manual process, and we had configuration drift. There were a lot of touch points. There were parts of the business where we knew that there could be a faster deployment and much quicker development and production. Ansible has increased our speed of deployment. We have a source of truth now. It has sped everything up, and it has saved a lot of people's time.

We've got on-prem and cloud deployment. We've got it in AWS, and we've got a proof of concept in Azure. We are looking at Azure SaaS, but at the moment, we don't know which way that would go.

We're realizing its benefits on a daily basis now. The biggest issue that we've had has been changing the way people work. We have a lot of people doing the work, and they all had a certain way of working. There were a certain set of tools that they used. We had to gradually migrate all of the tools that they were using to be more automated. There was a lot of code and a lot of tools on people's individual machines or shared drives. For example, User 1 had all of his applications and tools on his machine, and he might also have had some small scripts that he wrote personally on his machine. When User 2 came along, he didn't get to see what User 1 had because all of the scripts were on his machine. By automating more, we've put all of our code into a central repository so that everybody who is a member of that repository can see everyone's code. Nobody is siloed anymore. We have a lot more collaboration. There is a lot more progressive thinking in the way people are working. It is not where a bit of code is written for one specific purpose. It is always adaptable by just changing variables, etc.

It has effectively sped up everything from our sandpit environment to our full CI/CD process and our end deployment. Previously, we had to build everything manually in the sandpit. We had to build everything manually in the test environment, and we had to build everything manually in the production environment. Because we have environments that are matched all the way through, now, after we've built something in the sandpit, we can just promote that code. So, the copying of that code through various platforms has been eliminated with the use of Ansible and our repository system.

It has an easy-to-use interface. It is REST API driven, and it integrates with Active Directory. It provides the ability to grant permissions to other users who would not necessarily have those permissions via the GUI so that they could run other people's jobs. For example, you could have the Oracle team grant permissions to the Linux team so that they can use each of those playbooks or each other's code. It is called shift-left.

Ansible has just been upgraded, and the only issue that we are seeing at the moment is that the user interface can be slow. We're currently investigating the refresh period with Red Hat when you click a job and run a job. It seems that the buffer no longer runs in real-time. We haven't discovered whether that's partially an issue with our environment, but Red Hat has come back and said that they're working on a couple of bugs in the background. We've upgraded to that version in the last six months, and that's the only issue that we've seen.

There should be a more adaptive search feature. For example, if you had the name Mr. Smith, and you type in Smith, sometimes, it doesn't find Smith. You've to type Mr. first and then Smith. The search feature has certainly taken a little bit of a step backward from what we were used to in Ansible Tower.

I feel if we took this to the customer now and asked the customer to start using the product as it is, we'd be getting a lot of pushback because as an automation platform, it feels as if it is very early in its life cycle and development. I know that within Red Hat, a lot of the tests that they perform are automated tests. Somebody doesn't necessarily sit at the GUI. When you speak to Red Hat, they always say that a lot of the customers don't use the GUI. They might have got a front end or some sort of ServiceNow provider that runs all these jobs, but the search and job updates are the main challenges at this time.

It has been five years with Ansible Core and three years with the Red Hat Ansible Tower offering.

Its stability has been good. There are odd glitches within Ansible AAP, but within Core, there are no problems.

It is scalable. We just add more nodes if we need them.

It is used at multiple locations and in multiple departments, and our end users have multiple operating systems. There are probably over a hundred thousand users. We're going to put some more nodes in at some point in the future.

Their technical support has been good. Because we're a big organization, we have our own allocated SME within Red Hat, and we normally liaise with him. The Ansible support itself has been okay if we need to raise a ticket, but we're usually raising tickets just to get something on their system. We normally speak with the SME allocated to us, and he has been excellent. Our SME is called Pat, and I would rate him a ten out of ten. 

I would rate the support team within Red Hat an eight out of ten. The trouble is that if you raise a support case with Red Hat, they don't appreciate how much experience a specific customer has got or how much troubleshooting they've already done. So, the first thing they do is they'll ask for a basic set of files, which is understandable, but when we've already passed that point where we've already done all the checks, instead of going in at the first line, we need to go in at the third line to get something resolved. That's where Pat picks it up.

Positive

We didn't use any other solution previously. There has been a scattering of other automation tools around, but nothing that had physically been a business directive. It was always bash scripts, secure CRT scripts, etc. They were just scattered everywhere. There was no semblance of order. If we had anything, it could be a guy that was working two days a week, but you never knew what day he was working or who was supporting it. We had nothing like that other than Puppet.

The main factor for going for Ansible was that within our environment, there were already a lot of people who had Ansible engine experience or had worked with Ansible Core. Ansible is an easy-to-use language. It is very easy to pick up, and you can start automating quite quickly with Ansible. It is not as complicated as Python or anything like that. There is ease of use. It is not like writing Python code where there is a lot out there, but there is no front-end GUI that we could bring users into quite quickly. It is not as scary because you can look at the GUI, and you can click around and run jobs within the GUI. You don't need to have any deep Python experience or complicated Ansible coding experience. Once you've got a playbook in your repository, you can just run it from the web front end, and we couldn't find anything else that had a web front end like that.

It has got a big community. There are always people out there writing new modules, and you've got Ansible Galaxy, and you've got Ansible Collections where one is vendor-provided and one is community-provided. It is just very progressive. 

It was straightforward. The deployment took about a week.

We liaised with Red Hat. For Tower, we followed the deployment guide, and for the automation platform, we followed the upgrade process. We fed back any issues we had to Red Hat, and they were quick to resolve them.

There are ten people on our team, but not all of them were involved in deployment. It is a two or three-man job. We're all engineers.

In terms of maintenance, we have regular maintenance windows. Whenever there is a new version of AAP, we update it. We obviously run all our Linux patches on a regular basis, and we always sit and wait till we've done some testing on Ansible before we update the Ansible version on that box. There are ten people on our team, and we normally just pick slots between us so that the same person is not doing the same maintenance window all the time. The majority of it is automated, and it is just a case of somebody sitting in and checking that the job has run, and there haven't been any issues.

At the moment, it is just time saved.

I don't see the pricing or licensing features, but from what I understand, it is fairly reasonable.

Don't be narrow-minded. Don't be put off by adopting something that you've never worked with before. There is plenty of documentation out there to help you. It has a thriving community, and there is plenty of information online. Red Hat's documentation is also very good. You can get yourself up and running across a variety of platforms quite quickly by just looking at the Ansible site.

I would rate it a nine out of ten because there are a few quirks with the GUI at the moment. I would've rated Ansible Tower 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 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. 

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.