Red Hat Ansible Automation Platform Reviews

Our primary use case is automating security compliance tasks.

It has met our expectations. Automating security compliance tasks is what drew us towards the product initially. It definitely checked the boxes for what we needed to be able to implement.

It increases our company's efficiency, automating all the simple tasks which used to take hours of somebody's time.

It was easy to read and learn. It is a YAML-based syntax, which makes it easily understand and pick up. 

The user interface on the Ansible Tower product could be better, but it is functional.

It is stable. Being community supported, obviously anytime there are issues, they are spelled out and resolved pretty quickly.

It should meet our needs going forward. We use it in a number of different environments which range anywhere from a handful of servers all the way up to thousands of servers. It has performed and scaled well for everything that we have done.

We are a partner with Red Hat. On the Ansible Lockdown project, we interact with them a lot, though not necessarily the tech support. We interact frequently with the product managers and those types of people.

We also work through the community.

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

The primary use case is network automation. I have been trying to use it to roll out new offices and update things, like NTP server changes. I would like to roll NTP server changes out with a couple of clicks instead of having to go and manage several hundred devices.

I have been using the product since 2016.

It's helped in my department, or at least in my role, because I use it a lot. NTP is a big one. We just rolled out GPS-based NTP. Instead of spending several days going to each device and ripping out config and putting new config in, I just batched our branches, batched our data center, ran three jobs, and called it a day.

The network modules.

There has been put a heavy focus on the network, so it is getting better. Some of the Cisco modules could be expanded, which would be great, along with not having to do so much coding in the background to make it work.

It has become a more stable product over the past two years. Ansible has put a focus on network, so a lot of things have changed rapidly. I have been trying to stay on a release for awhile until I can figure out how the new stuff works. For example, they just changed the connection type to network CLI from local.

It hasn't been always stable, but when it has been unstable, it was for a good reason: To get to a better place. The stability is getting there, if it is not already there.

It is all modular-based. If there is not a module for it today, someone will write it.

Since I use Community, it's all community-based. Most of my questions go to Network to Code, which has a Slack channel, and the Red Hat Ansible team is on it along with a lot of industry people. If you ask a question, it's pretty likely that you are going to get a response.

Installing it is a PIP command. So, it's pretty easy. It is a one liner. 

I have looked at Puppet because they are now trying to get into the network space, but it is not that easy. The feeling of the product is not as good. 

On the network side, I already have a lot of our firewall-related processes automated. If it's not automated all the way from the ticket system, our network team members, our tier-one guys in India, can just go into the Tower web interface and fill in a couple of survey questions. We've used Ansible even longer than that, organizationally, for web servers mainly. Some guys are doing some of the Kubernetes stuff, but I'm personally not involved with those modules.

The community is very important. Right now, I'm focusing on Palo Alto and automating a lot of our firewall processes related to when a developer requests new firewall rules. Right now, that's a totally manual process. I'm three weeks away from putting in an automated process from a third-party tagging system flowing into Ansible and actually writing to our Palo environment through our data centers throughout the world.

Some of the module documentation could be better, but I don't know if that's Red Hat Ansible's fault. Specifically, I've done a lot of Palo, and I've done some Cisco ACI. The Cisco ACI, I don't know who actually produces those particular modules, whether it's Cisco or the community.

Also, it is a little slow on the network side because every time you call a module, it's initiating an SSH or an API call to a network device, and it just slows things down. For the web server guys, all the work is done on the destination server, whereas for network devices, all the work is done on Tower. And then, as I said, it's either SSH-ing or using an API call to the device. Every time you do a module, that slows it down. I heard some rumors, I don't know if they're true, that the Ansible team is looking at improving that performance. But that's hearsay, as far as I know.

I'm going to have to learn more about the Tower and the sharding of jobs that's coming because, right now, I'm just writing stuff to a couple of individual devices - for Cisco ACI and Palo - but once I get into the Cisco IOS, we're talking thousands of devices. 

The setup is pretty straightforward. Getting started with Ansible, training on Pluralsight, it's about three hours. You do some labs and, from there, it's off to the races.

I did some training and I've messed around with Terraform. They do have providers for Palo, specifically. But in network, I'm dealing with mostly bare metal devices. And Terraform, that's just not what it's meant to do. I was trying to see if I could do some things with it, but it's not the right solution.

Some of my peers dealing with servers, they use a lot of Terraform because they can say, "Well, we have an environment that needs to be four to eight servers. Create the Terraform configuration and the TF files and TFR files and just let it do its thing." But I can't really do that with 1,500 physical devices that already exist.

I'll start on Cisco IOS stuff in Q1, 2019. I'm pretty excited to learn about the network engine today, here at AnsibleFest 2018, because I haven't looked at it at all yet.

We use it to deploy our infrastructure.

It has made our infrastructure more testable. We are able to build our infrastructure in CI, then are more confident in what we are deploying will work, not breaking everything.

It has been simple to get into, and we are able to get results out of it quickly. We automate across a bunch of different server and virtualization platforms and have been able to do that with Ansible across the board along with our networks.

For a couple of the API integrations, there has been a lack of documentation.

Performance has been an issue on larger environments, but it has gotten a lot better over the past two years. So, we are seeing steady improvements there.

As long as there is a continued focus on improving performance and scalability, then it should meet our needs going forward.

We don't use Red Hat tech support. We support everything in-house.

We have written a lot of open source Ansible content. I work on the OpenStack Ansible project. So, we've done a lot of open source contribution and support all of our playbooks and roles in-house as well.

The initial setup is simple.

The documentations are great. Everything is pretty well-documented.

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.