Red Hat Ansible Automation Platform Reviews

We use it to manage all configurations and deployments.

We were growing at the time. I was able to take the old build manifest and automate everything. So when it came time to spin everything up, it was quick and simple. I could spin it up and test it. When it came time to roll production, it was a done deal. When we expanded to multiple data centers, it was the same thing: Change a few IP addresses, change some names, and off we went.

It helps me do a lot more. Where previously we had a couple of guys doing what I do, now it's just me.

The ability to centralize everything, to centralize management, and to push changes quickly and reliably. That's the main use for us.

In my opinion, one thing that needs improvement is mass updates: How I can parallelize that process a little bit better? It seems right now that I run through one set of servers, and then another set of servers, and then another set of servers but I'm not sure all those checks are needed. If I could parallelize different types of servers, like web servers and DB servers, that would make everything run a little bit more efficiently.

It's reliable.

We're a small shop. It seems it could be quicker, but for what it does, it's fine.

I had briefly toyed around with Chef and Puppet, but I didn't get anywhere with them. Then I found Ansible. It was at a previous job where I picked up on Ansible. At that job, they were against putting an agent on anything. So Ansible was it. That was the easy sell. Then I figured it out and rolled with it.

The setup of Ansible is straightforward. You just download it and get started.

In terms of the documentation, I'm used to it, so it works fine for me now. At first, it took me a minute to find out exactly how to quickly find my way around the documentation, but now I'm comfortable in it and I'm happy with it.

We mostly run everything CentOS, and do the Community edition.

We are using the Red Hat Ansible Automation Platform for storage and for confirmation management. We are using a template in VMware.

The solution can be deployed on the cloud or on-premise.

The most valuable features of Red Hat Ansible Automation Platform are the agentless platform and writing the code is simple using the Yaml computer language.

There are some options not available in the community edition of the solution.

I have been Red Hat Ansible Automation Platform for approximately eight months.

I rate the stability of the Red Hat Ansible Automation Platform a nine out of ten.

We have approximately five people using the solution in my organization.

I rate the scalability of the Red Hat Ansible Automation Platform a nine out of ten.

I have not used the support from the vendor.

The initial setup of the Red Hat Ansible Automation Platform is simple.

We did the implementation of the solution in-house.

I am using the community edition of the solution which is free.

I rate Red Hat Ansible Automation Platform a ten out of ten.

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 just started using Community with Ansible. We are trying to install agents to either a cloud or a local virtual machine. We are still in the starting phase as it has only been implemented for two months.

My team thinks it is easy to work with, especially when working with the nodes. When the nodes increase, from say five to 15, I don't have to do anything extra.

1. There are so many models that I don't have to create one. I don't have to worry about anything. In these two months, everything was easily available.
2. Since it is in YAML, if I have to explain it to somebody else, they can easily understand it. 

One problem that I'm facing right now is the mismatch between the new version of Python and Ansible. Sometimes it's Python 2, and sometimes it's Python 3. When things get a bit dicey, I wish that Ansible would solve this issue by itself. I don't want to have to specify if it is Python 3 or version 2.

I haven't had any issues, but I have only been working with it for two months.

It is scalable enough for our needs. We are not working with hundreds of nodes, just ten to 15.

The community is enough for me.

The initial setup is pretty straightforward.

I researched with other tools, but I still chose Ansible. One reason, it was agentless. With other tools, I had to install agents. Ansible has a big plus factor being agentless.

We use it for any sort of automation. We started using Ansible about 18 months back. But then we realized, as we expanded Ansible, that we needed controls around it. We didn't want people just running around crazily running Playbooks. And that's where Tower came in. We bought licenses and it's kind of worked out, though we expect a lot more. I did have a meeting yesterday with the Product Manager for Tower. I did give some suggestions. It's worked out but we've got more expectations, and I hope they work out as well.

Some examples of the tasks we've automated include OS patching to begin with - everyone does that. We have been using Ansible and Tower for a lot of data collection, for auditing, collecting data from across different servers: network, OS, Windows, Linux, etc. That's one of our major automations. In addition, AWS and various clouds, if we have to spin something up.

We're not using it for compliance yet. I saw a demo about that yesterday and we'll probably explore that.

In terms of staff or the amount of effort involved, Ansible is great. That Tower uses Ansible is amazing. Creating Playbooks takes less time. Tower has its own features. If there were more that would be great. But because Tower uses Ansible, it's not a lot of effort and we can get things done quickly.

• The Organizations feature, where I can give clear silos and hand them over to different teams, that's amazing; everybody says that it's their own Tower. It's like they have their own Tower out there.
• RBAC is great around Organizations and I can use that backend as our lab.
• Ingesting stuff into the JSON logs, into any sort of logging collector; it works with Splunk and there are other collectors as well. It supports Sumo and that helps. I can go create reports in Sumo Logic.
• Workflows are an interesting feature. I can collect a lot of templates and create a workflow out of them. 
  
• Also, the fact that Tower exposes APIs so other Playbooks can consume the APIs, it does complement other programs we use internally.

We are not using the Dashboard a lot because we have higher expectations from it. The default Dashboard from Tower doesn't give that much information. We really want to get down into more than if the job succeeded or what was the percentage of success. We want to get down to task-level success. If, in a job, there are ten tasks, we want to see this task was a success, and this one was not, and how many were not. That's the kind of granularity we are looking for, that Tower does not give right now.

There could be more stuff in the workflows. I hope that if I have ten templates with different services on it, workflow could auto-populate all the template-based services.

It's definitely stable and reliable.

Regarding scalability, we had issues initially. The biggest issue we ran into is, while yes, the documentation says if you want to run on 100 machines you need to have this many CPUs and this much memory - and we started following that - if my job template has 50 tasks in it and I enable verbosity and I run it on 1,000 servers, I am out of memory right away. The moment I have to expand to 1,000 or 2,000 or 3,000 servers, I cannot run verbosity. That has been one of the major problems that we have faced.

Scalability-wise, if I'm not enabling the debug log, it's good. Normally I do that. I have to cut down the list, shorten the number of target hosts, and then I can enable debug. That's been a problem.

Technical support has been good with the limited number of things that are supported in Tower. The Tower modules are not supported by Red Hat, which was disappointing. If I have to do updates to Ansible Tower, not somewhere else, I have to call the API, look at the right JSON, and post the JSON. If I had the module, and I had the feature of the module, I could use it. Right now the modules available on community don't have all the features. If Red Hat was supporting it they would have added those features. So there are things that are still missing.

The initial setup was pretty straightforward.

In addition to the developers who use it most, we hand over job access to different teams. Security needs some data, we clear jobs for them, we hand it over to them. But most of it is with Operations and the Development team.

I rate it a seven out of ten because there are a couple of things which I expect from Tower which are not there yet. As I mentioned already, things like services being populated from templates, job tags are not there on workflows right now, I have to go to another tool like Splunk or Sumo or some other logging tool to look at graphs. If those were possible in Tower it would be amazing. Anybody could run a job and go and look at a graph and see what happened, instead of having to log into another tool. There are things which I think can be added to Tower, but it's a good tool.

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

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.