Red Hat Ansible Automation Platform Reviews

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.

So far, the main thing we've been doing with it is using it to automate our monthly patching of servers. Since we have the whole inventory, we can patch this project's servers. We can use the exclude, exclude others, and, in one hour, do a patch that would take people one night to do.

Managing our inventory is a big pain point. Right now, we have Satellite, but we can tie it in with Satellite, so we can actually manage things and automate the entire deployment stack, instead of trying to grab things from tickets, then generating Kickstart, and using that to get things in Satellite. That doesn't work well. We can do the whole deployment stack using the inventory share between Tower and Satellite.

I've been doing patching from the command line, but for other people, it's nice to have the Dashboard where they can see it, have it report to our ELK stack. It's far more convenient, and we can trigger it with API and schedules, which is better than doing it with a whole bunch of scripts.

• I like the inventory management. It's a very nice, simple, concise way to keep all that data together.
• The API allows us to use it even for things that are not Ansible.

On the Dashboard, when you view a template run, it shows all the output. There is a search filter, but it would be nice to able to select one server in that run and then see all that output from just that one server, instead of having to do the search on that one server and find the results. It would be nice to just be able to view per-server. Sometimes the server has some problems that we're going to find in some places. It would be nice not to have to search for them.

We haven't had any issues with its stability or with bugs, so far.

I think it will meet our needs going forward. We're going to put, not a whole lot of servers, just 3,000 servers, and that's going to be spread out. We're going to do an HA Tower. Right now, we're only doing 350 servers for our trial runs. We haven't had any problems with that, we just keep them all up at once.

I actually haven't had to contact tech support on any issues. My colleagues have worked with them for OpenShift, but for Tower, we haven't had a reason yet.

I felt the setup was really straightforward. The set up is with the Ansible Playbook. I just skimmed through that and I found that it does everything I need. And then I just ran it.

I did an upgrade two weeks ago. That was simple: Download the new one, run it. I did a back up before, just in case, but everything went smoothly. No problems.

Puppet is the main configuration management we have right now. The goal is that Ansible will do all the administration and deployment, and do all things with a baseline, to meet our standards. Then Puppet is going to be taking care of a lot of the rest of the configuration for all the different projects.

Everyone gets super excited about when we show them the automation part of Ansible: 

• How can you orchestrate things? 
• How do you operationalize it? 
• How do you take it to a group of people who don't have the experience writing playbooks themselves nor experience with command line? 

Tower allows control for more people to use it and have some safety nets behind it.

From speed to deployment, it is much quicker. It has an API in the back which allows for integrations. So, if you are building a pipeline with Jenkins or some orchestration tool, it's much easier to write the playbook and plug it in via Tower than try to link it yourself. Thus, it is quick to production.

If you look at network as a infrastructure, NetOps, and the continuous integration, we are certainly able to plug something (like Tower) into the pipeline, which is a big benefit and also a value add.

I haven't done a lot with the dashboards yet. One of the sort of difficulties on the network side is they just recently became first class citizens on the connection, so you have to do another step. However, I think now that is clearing up, and the dashboard will come into play more.

From a documentation standpoint, especially on the networking side of things, things are changing rapidly, most of time for the better. However, the communication on it is not probably where it could be. We could use some real life examples where we could point customers to them and say, "This is what you are trying to do. If you follow these steps, it would at least get you started a bit quicker."

I have had very few complaints from both my usage and when I've helped customers deploy it. From a stability standpoint, it seems to be pretty strong.

I haven't deployed it at a giant scale, but hundreds of nodes seems doable without too much trouble.

It's pretty straightforward. 

Sometimes from version to version, some discrepancies can make it a challenge to work through, but for the most part it's pretty straightforward. One of the reasons in the network industry that Ansible won out over some of the other automaton tools is the low barrier to entry. It's pretty simple to get started.

For deployment and maintenance, my team has two people work on it as their primary task.