Red Hat Ansible Automation Platform Reviews

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.

I'm a software architect at a DevOps platform called Jihu. We use Ansible to provision Kubernetes clusters. For example, if the cluster has dependencies, we provision for the specific package manager version and dependencies, so they can scale for the CI/CD line. Ansible helps us provision the Kubernetes cluster for single-cloud or hybrid-cloud scenarios.

I like Ansible's ease of use. If you have Linux skills, you can create a reusable template for the dependencies and other configurations. I can store the templates in a repository and share them with my customers or other developers. It's a popular solution, so there is a large user base that can share templates. 

It could be easier to integrate Ansible with other solutions. No single tool can do everything. For example, we use Terraform for infrastructure and other solutions for configuration management and VMs. 

I have used Ansible for around four years. 

Ansible is stable as long as you have the connections between the machine and the server you use for all of this. 

Ansible has some built-in mechanisms to help you scale. There are different playbooks or steps. I have various multi-project partners that handle these kind of jobs, so I can do the provisioning simultaneously. Of course, we still need to do some prerequisites and there are dependencies between various jobs. 

I don't typically raise support tickets, but I frequently work with the Red Hat presales staff because we sell their solutions.

Setting up Ansible is straightforward because we use the Docker image. There may be some challenges if you have large-scale VMs. It's typically fine if we use configuration management for the credentials and SSH. If you want to use Ansible to provision VMs like TerraForm, then we need to clearly understand the mechanism. The time needed to deploy Ansible depends on the type of applications and infrastructure you're dealing with. It isn't only about the specs of the VM. The network speed and complexity also factor into it.

I rate Red Hat Ansible Automation Platform seven out of 10.  I give it a seven in the Hong Kong context. It's about the culture, not the technology. Most of the infrastructure and network people in Hong Kong find it hard to accept a new solution, and it isn't easy to transform this kind of culture. They have one or two OEMs running on some simple web servers. Their teams are not familiar with the infrastructure cost calculators and configuration management stuff. 

We don't push them to use anything like this, but if they have lots of things they need to manage, then it's an opportunity for us to sell them solutions. We ask them questions. How many standard operations are you using? What is the approval flow? How long would take if you want to release or deploy applications? We make the case that they could shorten the time spent on SOP by eliminating manual work in the approval flow. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We use Ansible for automation. It is integrated with Datavations. When we start Datavations, it calls the Ansible tower, which executes tasks like automated checks between the servers. We also use Ansible when we need to patch or upgrade our software.

Ansible has saved us lots of time. Previously, it took us much longer to deploy or make changes across systems. 

I like the fact that Ansible is agentless.

The support could be better. 

We have used Ansible for three or four years.

Ansible seems steady. It's stable all the time.

I rate Ansible eight out of 10 for scalability. 

I rate Ansible support eight out of 10. I rarely use them. It isn't the worst, but the response time could be better. 

I rate Ansible 10 out of 10 for ease of deployment. Deploying Ansible was straightforward and only takes about a minute. It starts with the CI/CD process, and it's automated so that when there is a change to the code, the changes are applied across servers or applications.

I rate Red Hat Ansible 10 out of 10. I recommend Ansible. It's easy to use. 

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.