Red Hat Ansible Automation Platform Reviews

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.

Our use case is to stitch together all the units, all the teams writing roles and Playbooks, and provide a central point for execution, and a way of managing what is executing against the infrastructure.

I was the one who initially initiated Ansible Core and Tower within our department of the bank. I have actually been the Ansible evangelist, so I'm slowly migrating people from using batch scripts to using Ansible Playbooks. That has taken a little while but there has been an improvement in people using Ansible, and starting to automate things better, and people sharing code amongst the teams.

I prefer Ansible Core, but from an enterprise standpoint, an admin point of view, having the Dashboard and seeing how all the projects and all the jobs lay out is helpful.

What I would like to see is a refined Dashboard to see, when I log in: Here are all my jobs, here are how many times they've executed; some kind graphical stitching-together of the workflows and jobs, and how they're connected.

Also, those "failed hosts," what does that mean? We have a problem, a failed host can be anything. Is SSH the reason it failed? Is the job template why it failed? It doesn't really distinguish that.

The job workflow needs to be worked on. It's not really clear to how you actually link things together. What they probably could do is provide an example workflow on how to stitch things together. I think that would be very helpful.

After I built it, it was given to another department to manage. From what I'm seeing, it is reliable, since we've clustered it together. We have a cluster of Towers within each different environment, Dev, UAT, and Prod, and that controls which Playbook is executed in which environment. In regards to the clustering and it staying available, it's stable.

It scales well because of the clustering.

Sometimes it takes a couple of messages before they understand more difficult situations, but I would rate technical support at eight of ten.

At the time, the setup was pretty straightforward. I don't think there have been any changes in that regard.

I've used Salt and I've used Puppet. The reason I like Ansible is, first, the coding of it is very straightforward, it's very human-readable. I'm also on a contract, and I can clearly iterate and bring people up to speed very quickly on writing a Playbook, compared with writing up a Puppet manifest or a Salt script.

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.