Ansible Pros and Cons
The biggest thing I liked about Ansible is the check mode so that we can verify, after we've pushed, that the config there is actually what we intended.View full review »
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.View full review »
The user interface is well-built and very easy to navigate around.View full review »
It is very extensible. There are many plugins and modules out there that everybody helps create to interact with different cloud providers as well.View full review »
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.View full review »
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.
It's nice to have the Dashboard where people 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. And the API allows us to use it even for things that are not Ansible.View full review »
It is very easy to use, and there is less room for error.
Ansible Tower offers use a UI where we can see all the pushes that have gone into the server.View full review »
Having the Dashboard from an admin point of view, and seeing how all the projects and all the jobs lay out, is helpful.
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.View full review »
It is quick to production. It has an API in the back which allows for integrations.View full review »
Installing it is a PIP command. So, it's pretty easy. It is a one liner.
It is all modular-based. If there is not a module for it today, someone will write it.View full review »
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 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.View full review »
It can use some more credential types. I've found that when I go looking for a certain credential type, such as private keys, they're not really there.View full review »
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.View full review »
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.View full review »
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.View full review »
For Ansible Tower, there are three tiers with ten nodes. I would like them to expand those ten nodes to 20, because ten nodes is not enough to test on.View full review »
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.View full review »
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."View full review »
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.View full review »
What I'm trying to figure out, personally, is, when doing mass updates, how I can parallelize that a little bit better. It seems right now - and maybe, it's a shortcoming on my end - that I run through one set of servers, and then another set of servers, ad then another set of servers, but it seems like I could throw a lot of these checks out. Different types of servers, like web servers and DB servers, if I could parallelize that a little bit to make everything run a little bit more efficiently, that would help.View full review »