Red Hat Ansible Automation Platform Reviews

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 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 can use the solution for a group deployment if we have an infrastructure where we need to deploy software onto multiple machines at the same time. The tool should be on an Ansible server, and the server should be able to do SSH to the multiple hosts on which it wants to act.

We can automate a few host configurations using the product.

The solution must be made easier to configure.

I have been using the solution for almost five months. I am using the latest version of the solution.

The product is very stable.

The product is scalable. We can use it on multiple cluster levels.

The documentation is quite good. We don’t need to call anyone.

The initial setup is quite easy. The deployment took 15 to 30 minutes. The tool was deployed on a Linux machine. People deploying the solution must have some hands-on experience in Linux.

It’s an open-source tool.

I recommend the solution to others. Overall, I rate the solution a nine out of ten.

We can use it to configure or to change the configuration in a large number of servers. Also, if there are some issues in comprehension, for example, permission or ownership, we can fix that with the Ansible label. 

We can use other advanced features. Currently, for example, we are using BigFix for automation. We use Ansible since it doesn't need agents to install on every server. For BigFix, in contrast, you do need to have a BigFix agent for every server. Not having to do that with Ansible is a benefit for us.

The Ansible automation platform helps us achieve our goals. It is easier to handle and easier to understand. We can learn it easily, and we can share it with colleagues also very easily.

New colleagues and new people can understand the solution very well, making it quick for onboarding. 

It is easy to manage. If we make a playbook, we do need to have some skills in scripting or skills for the AML file. However, once we do, we can easily handle the issue.

We are just starting to use the solution. I can't speak to improvements, really. So far, I am more comfortable with this product than the previous one. Once we start using it heavily, maybe we will see issues.

I've been using the solution for one year.

The solution is stable. Some colleagues and other companies use it and comment that it is easy to use, easy to understand, and offers good features. They're very positive when discussing Ansible. 

The solution can scale. It can cover large amounts. Many other companies also use it successfully.

We have more than 600 Linux servers. We are using it on all the servers. 

We use Red Hat a lot. I open tickets for the Red Hat cases, however, with Ansible, I haven't opened any cases. My manager worked with them a bit.

If we have a problem with some file and we need to get Red Hat to analyze the issue and the file is 100GBs, we'll have an issue since we need to provide a log file for them to analyze. If it is around 12GB or 13GB, we can easily upload it to the Red Hat portal. With more than 100GBs, it will fail. I heard it should cover up to 250GB for an upload, however, I find it fails. Therefore, Red Hat needs to provide a way to handle this.

Positive

We also use BigFix. However, we need to have an agent on every server with BigFix, which is not the case with Ansible. 

Our manager had already implemented Ansible, and we were using it in the lab previously. In the lab, we saw it running very smoothly. Some of the production servers also use Ansible as well.

I was involved in the initial setup. I use it in the lab server for now, and it is good. It is going to be in production soon. However, we already deployed it in lower environments, like the QA and development servers.

We might see an ROI soon. 

Previously, we had BigFix and considered other solutions. However, when Ansible came in, and we studied it a bit, we felt that it would be easy to understand and easy to implement. The learning curve was small. 

We are a contractor of the client. We support the client, so whatever the client needs, we use and provide. Our client owns Red Hat, and therefore we use it.

Our operating system is Red Hat. We chose it due to the fact that it is open source. In Red Hat, we can use VMware or physical servers or the cloud and find Red Hat to be easy to use, secure, and user-friendly. Also, if we use all RHEL products, they are all compatible with each other. If we use a third party, we might have issues. With RHEL products, it is already tested on the RHEL side, so we don't generally see issues. 

It's one of the best products to use. It is easy to understand and easy to manage. You can use it if you have a cloud, physical server, or VMware. It is very good and offers operational efficiency.

I would rate the solution nine out of ten. We like it, and we feel good about its capabilities. 

The primary use case is for configuration management. We use it for patching and updating. We also use it to send out new configs to all our servers.

It saves time; it cut our configuration time. 

It is very easy to use, and there is less room for error. For exampe, if we had 10 servers, and we need to update a file on each server. So, you would have to go into every server and update the file manually, then sign out. You can mess up on the sixth one and have configuration issues. It is easier to use one server to create a playbook, then you just hit "push" and the playbook is distributed to all the servers.

Ansible Tower offers use a UI where we can see all the pushes that have gone into the server.

It is very easy to grasp. Multiple users on my team can utilize it without me giving them a thorough tutorial. This has been helpful.

For Ansible Tower, there are three tiers with ten nodes. I would like them to expand those ten nodes to 20, because ten nodes is not enough to test on.

It needs better documentation when setting it up. It is not very clearly stated how exactly to set up Ansible Tower, though it is pretty self-explanatory.

It is definitely a workhorse. It does our back-end deployment, so we utilize it very heavily. We're committing too much to it, so we have it highly available. We built some redundancies around it just in case it ever goes down, because it's a big part of our work.

We are about 50 servers. It is not very big, but we are continuing to grow.

If we want to utilize technical support, we would need to use a more premium solution since Ansible Tower is free.

The integration and configuration in our AWS environment was super easy to set up. It does all our tasks. Having it integrate with our front-end and back-end deployment has all been seamless. There is no custom configurations.

Ansible Tower is free. Until they lower the cost, we are holding off on purchasing the product.

We considered Chef and Puppet, which are very similar to Ansible. However, they have a more Ruby-based programming language. Therefore, it takes more time to learn and incorporate into a company. Ansible is easier for everyone to understand what is going on without actually knowing the programming language.

We chose Ansible for simplicity. Ansible is easy to set up, then get up and running in about a day or so. With Chef, I would have had to sit there and learn it, so the time constraints didn't really work out.

Our use case for it is as an automation tool. For the Linux side, we have very few automation tools. We do have Puppet Enterprise as a matter of fact, and we're looking at tools for automating our day-to-day operations, server builds, configuration management, etc.

We've got a demo version of Tower. We've been playing with it, using it for patching. One of our first goals is to automate patching.

The improvement is going to come in that we are going to be able to maintain configuration management, through the use of both Puppet and Ansible. Currently, in a manual process, hands-on - that is what kills us. When we have a system administrator trying to do his job, that kills us every time. We have 2,500 servers and if a project comes to him, we have 15-minute time-outs. I don't like that. He'll go in there and he'll change it. And we can't control that and we don't know when it gets changed.

The hope is that we automate and then it's there, we know it's there. And then we'll use Puppet to come in at the back, and just maintain it. That is our plan.

If somebody tries to change something through Puppet, we're going to get reports. Ansible is going to be used on the front end, and if somebody comes up and says, "We need this patch pushed out. It's an urgent patch. It's high criticality. We need to do it now," we'll do it through Ansible. We'll write a Playbook or a module and just, boom, get it done.

The most valuable feature is the Playbooks and pushing them out.

We'll probably use it in conjunction with Puppet, because Puppet is more a solution where every 30 minutes it's going to check, whereas as Ansible doesn't do that. You have to push, from my understanding. That's what I thought. I could be wrong.

It has been stable so far.

It's scalable. We're looking at an enterprise configuration, when we get it done. It's a matter of getting it licensed.

So far, in our interactions with technical support, they've been knowledgeable. We're very happy.

The setup looks pretty straightforward. From what I've seen, although it was done by another person, it seemed to be pretty simple. I think it was an RPM.

You can literally automate everything. Whatever you want to do if you did it with shell scripts, you can do it in Ansible. There is also the ability to use Tower AWX, which allows you to store your variables in a hierarchy. 

If you're familiar with the Puppet product from more than six years ago, it allowed you to do inheritance on variables. Ansible made sure that they had that in their product. It's also not agent-driven. Therefore, you don't have the added extra bloat to your deployments. Just run your command, then get the code. You can deploy using packages on Ansible or you could deploy binary files by copying over.

It allows people without a lot of knowledge or expertise in a CI/CD pipeline to deploy it other than knowing how to write code. It allows them to look at what someone else has done and easily read it, then copy and paste into their own if they're creating a new app. They can also utilize what is already there.

It is very extensible. There are many plugins and modules out there that everybody helps create to interact with different cloud providers as well. Roles that sum up all the playbooks that you might have. You might have a giant playbook which is doing a lot of things just for one app. However, there may be other people who have also tried to do the same thing. So, they create these roles, and you're able to automate easier without needing all those playbooks. You can have role declaration with a couple of Rs.

In Community, there's a lot of effort towards testing, standardizing, and testing for module development to role development, which is why Molecule is now becoming real. Same thing with Zuul, which we are starting to implement. Zulu tests out modules from third-party sources, like ourselves, and verifies that the modules work before they are committed to the code. Currently, Ansible can't do this with all the modules out there.

It is stable.

The only issues that I have ever had were with brand new modules, which weren't really ready yet, and they were marked as testing or development modules.

I have never had any scalability problems. I have deployed 2000 computers all at once in the past for a previous employer. 

I usually just use the community. If you hop on IRC Channel, the Ansible channel, there are tons of people who are helping each other out all the time and helping the community grow. 

There is a lot of documentation on their website as well, which is unlike most tools out there. It is very thorough and detailed. It has how-tos and examples. You can even deep dive into Jinja and its more advanced features to understand what you're doing.

You install Ansible and are done. Even YUM or DNF installs, they are pretty easy to install. All the core modules support Python 3, so if you're moving to Python 3, it works. Python 2.7 is pretty much standard.

I was a very big Bash script guy years ago on automating deployments. Then, I moved into Puppet. I did Puppet for a few years, and was very involved in the community there as well. After that, I moved over to SaltStack. The design of SaltStack was a bit complicated, as it felt very split brain. So, I did that for about six months, then I decided to look more at Ansible, which I dabbled with for about two years before I started using it. It was a little complicated to use as the action system was weird, but they have over come a lot of those issues. Now, the Ansible modules are simple and easy to use, so I moved to Ansible and haven't changed since then.

It simplifies everything. You can see what is happening actively on your screen. Now, with Tower and AWX, you are able to see the output afterwards. You can set up cron through the web interface and see what happens.

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.