Red Hat Ansible Automation Platform Reviews

We deploy the production environment using the provisioning for Terraform. We provision the cluster we need. If we need three or four nodes, like provisioning for hardware, OS provisioning, and bootstrap provisioning, we will use Terraform. After Terraform, we have to do any configuration changes. To install some packages, I do the cluster configuration changes and use Ansible with Terraform. I will integrate and deploy products based on the Ansible configuration files by writing playbooks.

There are many configuration management tools currently in the market. If there is a huge cluster, we use Chef. For minimum nodes, we use Ansible.

I'm using the latest version. It's version 2.13.4. The solution is deployed on AWS cloud.

I like the agentless feature. This means we don't install any agent in worker nodes.

The solution requires some Linux knowledge.

I have worked with Ansible for eight years.

The solution is stable.

Scalability is not a requirement for this solution because it's a configuration management tool.

We also use Chef.

Setup is straightforward. There's no complexity. We had to learn some Linux information before setup.

The length of deployment depends on the nodes. It will show if everything is deployed or not, any changes, and if there are any failed nodes.

Security patching is enough for maintenance.

I installed the basic version myself. We also have the enterprise version, which is open source.

I would rate this solution as 10 out of 10. 

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 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 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.

I use the product mostly to configure virtual machines.

The solution helps us to have a standard configuration for all the virtual machines. It helps our virtual machines have the same configuration every time they restart. It also helps with automation.

The most valuable feature of the solution is that we don’t need an agent for it to work.

The product could do a better job at building infrastructure. 

The product should add a feature that alerts us if someone changes the configuration.

I have been using the solution for two years.

The product has high stability.

The solution has high scalability. It can be deployed on thousands of machines. Seven people in our organization use the solution.

The initial setup was straightforward.

We use the open-source version of the solution. The product can be used for free.

The tool should be used for server configuration but not for creating resources on the cloud. Overall, I rate the solution a seven out of ten.

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

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

It brings a lot of time-saving.

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

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

It is a stable solution.

It is a scalable solution.

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

Positive

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

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

The in-house team asked the support team questions.

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

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

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

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

We use Red Hat Ansible Automation Platform in our company to implement a software-defined infrastructure, which involves defining the desired configuration of machines in terms of their components, setup, security, user roles, software deployment, and certificate deployment. With this platform, we are able to set up new environments and manage the lifecycle of instances across various stages, such as development, production, and pre-production. We also use it for routing up and back of new software.

Feature-wise, the solution is a good open-source software offering broad support. Also, it's reliable.

I think some community projects support Ansible Playbooks, but they often break with version updates. It's a difficult problem to solve. DevOps should have a library with common components to make Ansible more productive when there are updates to Ansible and the operating system. What we need is model-driven, declarative software infrastructure management. However, things tend to break with new versions, requiring a lot of work to fix. It becomes a cost-benefit analysis of reusing old Ansible scripts versus rewriting them from scratch after updates. The problem is that it becomes quite fragile over time, and this fragility is a problem.

If the IDE and auto-completion of the solution are based on Checkpt, it is important to ensure that the AI coding tools support writing in a more declarative way. While I have not yet tried coding with this assistance, Microsoft and Keylabs both offer AI coding assistants. The focus should be on improving the support for Ansible in the area of AI coding. It is crucial to see how well they work with the new versions of Ansible.

I have been using Red Hat Ansible Automation Platform for almost five years. My company is an end-user of the solution.

The product's stability is very good. I rate it an eight out of ten.

Ansible is a configuration tool that doesn't have to scale like other tools. So scalability does not apply to the solution. Also, it's not a tool used by thousands of users. I am unsure if it can be used to manage thousands of servers. Small teams, like the DevOps team, use the solution. We service large groups of servers with it using a very small team of about two or three and a maximum of four people.

I have never contacted technical support. We use open-source support.

The solution's initial setup process was simple. The solution gets used in various ways, and it's essentially a configuration tool you run from any node with access to other nodes. It has got server versions as well. So, you can use it either way.

We compared it to other configuration management tools before choosing Red Hat Ansible Automation Platform. We did not choose others since they were not as centralized. It doesn't need a server since you can run it from your clients, and it doesn't need a central deployment service or server.

Red Hat Ansible Automation Platform is a declarative infrastructure management system that works fine if supported by the environments you use to set up. I rate the overall product an eight or nine out of ten.