Red Hat Ansible Automation Platform Reviews

It's a catch all. We now have a central way of pushing out updates. As long as we have every name of all the hosts on the network that we want to patch on Linux primarily, we have it covered, from one person logging on and issuing the commands, then looking for the feedback from the servers.

I like being able to control multiple systems and push out updates quickly with just a couple of clicks of a button and commands. I like the automation because it is a time saver.

I have seen indications that the documentation needs improvement. They are providing a "How to Improve Your Documentation" presentation at this conference.

It is stable and reliable. I don't see any problems with it.

We patch every week and have seven different environments, so now we are dealing with about 300 servers. However, we could increase that to 20,000 servers, as long as we have them in our catalog. We could push that out and be fine.

We haven't had to use tech support, but they are there. If we need to, I am sure we could easily reach out to them. We have an account.

We chose this solution simply because we use Red Hat. We trust Red Hat, and whatever Red Hat puts out, it is pretty solid.

The setup was done by another team of ours that we worked closely with. They walked us through setting up our own, and it's pretty straightforward. Once you install it, stand it up, and get all the configuration files in place, it seems pretty straightforward. 

I was surprised that it was so straightforward.

It has seamless integration because we are not using Ansible to manage our services. We are creating roles, and those roles configure servers. The way we design the role is we split into multiple roles and each role has its own action to perform. This helps a lot to design our overall architecture.

1. It's written in Python. It is not using Ruby. Python is already available on most of Linux backdrops. If you are using any of their distributions, YUM or DNF, both are using Python. 
2. It is agentless. I don't have to think about which client system my unit has understanding in or not, because I can execute from my system. It will go and configure it, and any module that it is looking for will be shipped out.

Documentation could be improved. Many times, if I'm looking for something, I have to Google it in a lot of places, then figure out what the best approach will be. There are some best practices documents, but they don't give you the information.

If we could have more information on how to figure out the IP address or the specific host, this type of information would help. We could get started up easily.

It is a reliable, stable product.

It is scalable. You can easily configure one or more nodes.

It has a lot of good features. For example, if you want to create a leader, you can execute a role on one node, then ask it to run on all the remaining nodes. It can easily scale this way.

There is always a learning curve when you are using a new tool. Other than that, the initial setup is straightforward.

I looked at Puppet and Chef. They are good tools, but there is a language barrier.

I've been using Python for more than six years. Using Ansible was a piece of cake for me.

Also, Puppet requests an agent. As with many places that I looked at it, it was a no-go if you have to install agent. We have a client system and need to install a client to configure or maintain our systems, so it is a no-go with an agent.  

With Ansible, it can remotely execute tasks and do its job.

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

Server configuration management: This is Ansible's forte as it has multiple modules to interact with servers either to orchestrate or configure them. This can take multiple forms like pushing a script and executing it, sending commands to restart services...

Network configuration management: Ansible coupled with Jinja2 allows to push parametered configurations in a reliable way. Support for network gear isn't as common as server/development use cases. But, with some hacking, it can be managed

The tool can also be used for CI/CD software deployment, But, we didn't explore this topic with it that much, yet.

Ansible provides great reliability when coupled with a versioning system (git). It helps to provide predictability to the network by knowing exactly what's being pushed after validating it in production.

It is very hard to manage more than a hundred servers with redundant configurations manually. It is too prone to error and troubleshooting can easily become a nightmare. This is why it is very beneficial to use an automation platform like Ansible coupled with configuration management/versioning (Gtilab, Gogs) and some best practices around that.

• Reliability & reproducibility: Being able to design playbooks that can be validated in the development environment, QA, then production is very valuable. This helps reducing configuration errors and provides faster deployments.
• Extensibility, versatility. Using its wide range of modules, Ansible can be used with different OSes and systems. In fact, using Ansible modules, one can interface with network gear using NAPALM, for example, or push remotely scripts for local execution on automated platforms.
• Facts gathering: Ansible is able to extract configuration items either to be used later for reporting or to be used as conditions for playbook actions
• Agentless: Ansible does not require to install a local agent on automated devices. It goes through communication protocols like SSH, Telnet, SQL (multiple DBS).
• Dry runs! Better safe than sorry!

• Accessibility. Ansible uses a CLI by default. Those accustomed to it can find their way and adopt the YAML files easily over time. But, some users are more comfortable using UIs.
• Ansible Tower's upstream project, Ansible AWX provides a web UI. But, it can be improved to make it more user-friendly.
• Overall, the learning curve could benefit from an easy to use UI.
• Network gear support is still not that great but evolving. We definitely would like to see a general direction towards those. Especially since there are so many vendors and managing them all from the same platform is a rare plus.
• For Windows, support is getting better, too. 

We've been using it for three years for various automation tasks from local user management (backup & monitoring) to orchestrated configuration updates

It has been very stable till know. As long as you test correctly your playbooks on dev/qa environments, you reduce the major source of concerns

We previously were using custom-made Python scripts for automation. It can weirdly scale well when multi-threading is leveraged correctly. But, it definitely cannot replace an extensible framework like Ansible. 

The community behind Ansible and its important number of modules make it a lot more relevant.

We were also using Puppet at some point. But, it's a bit different than Ansible, it was not a competing usage for

The initial setup is quite easy. Creating your first playbook and inventory can be challenging if you're not used to the underlying technologies.

It's opensource so it's free. But, not free as in beer.

The most important cost here is the learning curve. Small targets like local user management (backup/monitoring) or monitoring configuration management (Syslog/SNMP) are some of the easiest and low-risk ones can learn from. The OPEX gain is high, though. So, the ROI is definitely there.

For the UI, you might want to pay for Ansible Tower. But, there's also the opensource upstream project, AWX.

Chef, Puppet, Saltstack. Ansible proved to have the most traction and its orchestration use-case was a bit different than the configuration management one.