We just raised a $30M Series A: Read our story

Ansible OverviewUNIXBusinessApplication

Ansible is the #2 ranked solution in our list of top Release Automation tools. It is most often compared to Microsoft Endpoint Configuration Manager: Ansible vs Microsoft Endpoint Configuration Manager

What is Ansible?
Ansible is the simplest way to deploy your applications. It gives you the power to deploy multi-tier applications reliably and consistently, all from one common framework. You can configure needed services as well as push application artifacts from one common system.
Ansible Buyer's Guide

Download the Ansible Buyer's Guide including reviews and more. Updated: October 2021

Ansible Customers
HootSuite Media, Inc., Cloud Physics, Narrative, BinckBank
Ansible Video

Archived Ansible Reviews (more than two years old)

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
it_user1028010
Automation Engineer at Fidelity National Information Services, Inc.
Real User
Saved time as well as helped support compliance and standards

What is our primary use case?

It is used to support WAN network equipment.

How has it helped my organization?

Saved time as well as helped support compliance and standards.

What is most valuable?

The countless modules and products supported.

What needs improvement?

Error codes are not very descriptive.

For how long have I used the solution?

Less than one year.

What is our primary use case?

It is used to support WAN network equipment.

How has it helped my organization?

Saved time as well as helped support compliance and standards.

What is most valuable?

The countless modules and products supported.

What needs improvement?

Error codes are not very descriptive.

For how long have I used the solution?

Less than one year.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Mohamed Ibrahim
Senior DevOps at RubiconMD
Real User
It saves time; it cut our configuration time

Pros and Cons

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

What is our primary use case?

The primary use case is for configuration management. We use it for patching and updating. We also use it to send out new configs to all our servers.

How has it helped my organization?

It saves time; it cut our configuration time. 

It is very easy to use, and there is less room for error. For exampe, if we had 10 servers, and we need to update a file on each server. So, you would have to go into every server and update the file manually, then sign out. You can mess up on the sixth one and have configuration issues. It is easier to use one server to create a playbook, then you just hit "push" and the playbook is distributed to all the servers.

What is most valuable?

Ansible Tower offers use a UI where we can see all the pushes that have gone into the server.

It is very easy to grasp. Multiple users on my team can utilize it without me giving them a thorough tutorial. This has been helpful.

What needs improvement?

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.

It needs better documentation when setting it up. It is not very clearly stated how exactly to set up Ansible Tower, though it is pretty self-explanatory.

For how long have I used the solution?

Less than one year.

What do I think about the stability of the solution?

It is definitely a workhorse. It does our back-end deployment, so we utilize it very heavily. We're committing too much to it, so we have it highly available. We built some redundancies around it just in case it ever goes down, because it's a big part of our work.

What do I think about the scalability of the solution?

We are about 50 servers. It is not very big, but we are continuing to grow.

How is customer service and technical support?

If we want to utilize technical support, we would need to use a more premium solution since Ansible Tower is free.

How was the initial setup?

The integration and configuration in our AWS environment was super easy to set up. It does all our tasks. Having it integrate with our front-end and back-end deployment has all been seamless. There is no custom configurations.

What's my experience with pricing, setup cost, and licensing?

Ansible Tower is free. Until they lower the cost, we are holding off on purchasing the product.

Which other solutions did I evaluate?

We considered Chef and Puppet, which are very similar to Ansible. However, they have a more Ruby-based programming language. Therefore, it takes more time to learn and incorporate into a company. Ansible is easier for everyone to understand what is going on without actually knowing the programming language.

We chose Ansible for simplicity. Ansible is easy to set up, then get up and running in about a day or so. With Chef, I would have had to sit there and learn it, so the time constraints didn't really work out.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Learn what your peers think about Ansible. Get advice and tips from experienced pros sharing their opinions. Updated: October 2021.
542,721 professionals have used our research since 2012.
AB
Senior Security Engineer at Mindpoint
Real User
Its checking and validating ensures our packages are properly patched

Pros and Cons

  • "Its checking and validating ensures our packages are properly patched."
  • "Ansible could use more public relations and marketing."

How has it helped my organization?

For my client, it has improved a lot of the problems that we had. For example, with package management, I wrote a script in Bash to check all the different PHP versions in Red Hat. With Ansible, I can do it for all my systems at once, which is huge.

There are a lot of different, little nuances that I like about Ansible. The biggest is the checking and validating, since it makes sure our packages are properly patched. We are running the latest version (PHP, etc.) on our different packages and validating them.

What is most valuable?

I like learning and challenging myself with it, finding out if there are different problems that we can automate. I always look to see if there is a community solution first on the Internet. By looking at what other people have done, I can see if I can try to emulate their work.

What needs improvement?

Ansible could use more public relations and marketing.

For how long have I used the solution?

Less than one year.

What do I think about the stability of the solution?

It is stable.

What do I think about the scalability of the solution?

It is scalable.

How is customer service and technical support?

We do have a support license with Red Hat. I can call them and ask them questions, if I am stuck somewhere. However, our Linux department is really smart, and they know what they are talking about if I run into something, so I reach out to my resources first before I go to Red Hat.

How was the initial setup?

The setup is simple and easy.

Which other solutions did I evaluate?

Puppet and Chef are cool, and have been in the game much longer, but Ansible is way better.

What other advice do I have?

I like what Red Hat did with Ansible. They are keeping the community focus as a whole and building around the grass roots movement that Ansible started. They are keeping that and putting a fresh face on it.

Tower is user-friendly too.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
CB
Solutions Engineer at a tech services company with 51-200 employees
Real User
Check mode enables us to verify that the config we have pushed is what we intended

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

    What is our primary use case?

    We use it both internally on our managed services offerings, which are new for us, and I've used it for the last two years in my customers' environments to help me with deployments, primarily on the networking side. We also place a big focus on source control and the software development lifecycle.

    How has it helped my organization?

    It's going to help differentiate our services. It's something new that we're using internally, and our managed services, themselves, are new within Canada. It's something we're doing to help scale faster. Our company has an offering called through which we manage the subscriptions to various cloud providers for clients. We help them to automate that component.

    We also offer another service to help customers connect to various clouds effectively, through VPNs to different clouds. A big piece of that is standardizing. If client A comes in, versus client B, we want to standardize that process and make it repeatable, so we're templating that as much as possible in Ansible.

    Sometimes we'll combine various tools so we'll use Ansible on a native cloud formation. We're looking at Ansible as our key orchestration engine for the data model that we developed internally and to help pump that out.

    What is most valuable?

    To me, a great thing about Ansible is that it can do everything. Cloud, on-prem, Windows, Linux, networking. I've not seen any other orchestration tool able to do that as easily.

    The biggest thing I like about Ansible is the check mode so that we can verify, after we've pushed, that the config is actually what we intended. That's a big feature that I like about the product.

    What needs improvement?

    The way it's going to improve is with the community contributing more to the platform in terms of modules that interact with different devices. And perhaps it can contribute use cases, which is something I'm very focused on: documenting and showing them to customers; not just roles but how I use those roles, how I get started.

    Part of my initiative, in terms of using Ansible to build Ansible, is to demonstrate how I properly structure Ansible to deploy to a server with various roles. In my case, my role works on both Red Hat and Ubuntu Debian: How do you structure it to handle multi-OS, which is something I've learned from Jeff Geerling, whom everyone knows.

    The power of the community is what's going to make it better. It feels like it's growing every year. It's how the community is coming together. There's a lot of enthusiasm around that and it's contagious. People are excited about it. It has really been fun being here at AnsibleFest 2018 and seeing the passion about the product.

    What do I think about the stability of the solution?

    From an Ansible perspective, it is stable. Working more on the networking side, typically the challenge is with the particular networking device that we're dealing with: specifically, getting structured data returned, with the consistency of the CLI, across platforms. The challenges are not necessarily Ansible, per se, they're more because of the variety of vendors.

    It's impossible to tell Ansible, "Okay, handle every use case possible, every version of code." I've been trying to identify issues with platforms and how we can address them by fixing a module or parsing that data properly, without having to get Cisco to fix it in our code. That approach is somewhat backward, but we've had to deal with it a few times.

    What do I think about the scalability of the solution?

    So far, we haven't run into any scalability issues. We haven't needed to scale to the levels I've heard spoken about here at AnsibleFest 2018. Certainly, this summer, we used it to push over 8,000 lines of code on network devices and it worked quite well.

    How was the initial setup?

    In terms of the setup, there are still aspects that are a bit complex to set up, especially the different Python libraries' dependencies. I use it against Windows as well and that means integrating with Kerberos. But I've actually developed a role on GitHub to stand up an Ansible development workstation with all those requirements to make it easy. I actually use Ansible to deploy Ansible, which is kind of ironic.

    What other advice do I have?

    Another thing that I've been doing is mentoring teams on how to use Ansible. Ironically, I've been mentoring the server teams, which is where I worked in the first part of my career. I was more on the server side: Windows, a little bit of Linux. But I find it's so easy to use that it's more about the concepts and the Ansible language.

    I saw a very interesting use case where Harvard University Online essentially does its entire deployment using Ansible end-to-end, with native infrastructure. That is geared to a lot of things we do within our managed services. I knew that was possible, but seeing it in real life, how they deployed and the number of different stacks that they've touched, was something. Their ability to demonstrate they've done that is pretty remarkable. 

    Because some documentation needs to be improved - while getting started with it is getting better - it's hard to give it a perfect ten. It's definitely in the top products that I suggest to customers. I would rate it a nine out of ten. But you have to look at it as a framework. It's not going to come in and solve all of your problems, but you can build on it. You can develop your own module if it doesn't ship with the product. The core of Ansible is very solid.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    MK
    Senior Systems at a government with 10,001+ employees
    Real User
    I like the automation because it is a time saver

    Pros and Cons

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

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?

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

    For how long have I used the solution?

    Less than one year.

    What do I think about the stability of the solution?

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

    What do I think about the scalability of the solution?

    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.

    How are customer service and technical support?

    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.

    Which solution did I use previously and why did I switch?

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

    How was the initial setup?

    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.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Keith Rhea
    Security Engineer at MindPoint Group
    Real User
    It increases our company's efficiency, automating all the simple tasks which used to take hours of somebody's time

    What is our primary use case?

    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.

    How has it helped my organization?

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

    What is most valuable?

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

    What needs improvement?

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

    For how long have I used the solution?

    One to three years.

    What do I think about the stability of the

    What is our primary use case?

    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.

    How has it helped my organization?

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

    What is most valuable?

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

    What needs improvement?

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

    For how long have I used the solution?

    One to three years.

    What do I think about the stability of the solution?

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

    What do I think about the scalability of the solution?

    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.

    How is customer service and technical support?

    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.

    Disclosure: My company has a business relationship with this vendor other than being a customer: Partner.
    Yogesh_Sharma
    Senior Data Architect at Crunchy data
    Real User
    Since it is agentless, it can remotely execute tasks to do its job

    Pros and Cons

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

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?

    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.

    For how long have I used the solution?

    Less than one year.

    What do I think about the stability of the solution?

    It is a reliable, stable product.

    What do I think about the scalability of the solution?

    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.

    How was the initial setup?

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

    Which other solutions did I evaluate?

    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.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Shashank Jha
    Senior Software Developer at HCL Technologies
    Real User
    Since it is in YAML, if I have to explain it to somebody else, they can easily understand it

    Pros and Cons

    • "Since it is in YAML, if I have to explain it to somebody else, they can easily understand it."
    • "There are so many models that I don't have to create one."
    • "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."

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    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. 

    What needs improvement?

    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.

    For how long have I used the solution?

    Less than one year.

    What do I think about the stability of the solution?

    I haven't had any issues, but I have only been working with it for two months.

    What do I think about the scalability of the solution?

    It is scalable enough for our needs. We are not working with hundreds of nodes, just ten to 15.

    How is customer service and technical support?

    The community is enough for me.

    How was the initial setup?

    The initial setup is pretty straightforward.

    Which other solutions did I evaluate?

    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.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Chris Smolen
    Senior Network Engineer at ePlus Technology
    MSP
    It is all modular-based. If there is not a module for it today, someone will write it.

    Pros and Cons

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

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    The network modules.

    What needs improvement?

    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.

    For how long have I used the solution?

    One to three years.

    What do I think about the stability of the solution?

    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.

    What do I think about the scalability of the solution?

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

    How is customer service and technical support?

    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.

    How was the initial setup?

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

    Which other solutions did I evaluate?

    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. 

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Eric Spencer
    Network Engineer at a legal firm with 1,001-5,000 employees
    Real User
    We have automated a lot of our firewall-related processes, on the network side

    Pros and Cons

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

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?

    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.

    For how long have I used the solution?

    Less than one year.

    What do I think about the scalability of the solution?

    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. 

    How was the initial setup?

    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.

    Which other solutions did I evaluate?

    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.

    What other advice do I have?

    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.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Logan Vig
    Co Founder at Limestone networks
    Real User
    It has made our infrastructure more testable. We are more confident in what we are deploying will work.

    Pros and Cons

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

    What is our primary use case?

    We use it to deploy our infrastructure.

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?

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

    For how long have I used the solution?

    Three to five years.

    What do I think about the stability of the solution?

    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.

    What do I think about the scalability of the solution?

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

    How is customer service and technical support?

    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.

    How was the initial setup?

    The initial setup is simple.

    What other advice do I have?

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

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    SR
    Linux Administrator at a healthcare company with 10,001+ employees
    Real User
    Will enable us to do urgent patches through a Playbook or module

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    The most valuable feature is the Playbooks and pushing them out.

    What needs improvement?

    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.

    For how long have I used the solution?

    Trial/evaluations only.

    What do I think about the stability of the solution?

    It has been stable so far.

    What do I think about the scalability of the solution?

    It's scalable. We're looking at an enterprise configuration, when we get it done. It's a matter of getting it licensed.

    How is customer service and technical support?

    So far, in our interactions with technical support, they've been knowledgeable. We're very happy.

    How was the initial setup?

    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.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    EG
    Senior DevOps Engineer at a tech vendor with 201-500 employees
    Real User
    It is very extensible. There are many plugins and modules out there that everybody helps create to interact with different cloud providers.

    Pros and Cons

    • "It is very extensible. There are many plugins and modules out there that everybody helps create to interact with different cloud providers as well."
    • "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."

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?

    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.

    For how long have I used the solution?

    Three to five years.

    What do I think about the stability of the solution?

    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.

    What do I think about the scalability of the solution?

    I have never had any scalability problems. I have deployed 2000 computers all at once in the past for a previous employer. 

    How are customer service and technical support?

    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.

    How was the initial setup?

    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.

    Which other solutions did I evaluate?

    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.

    What other advice do I have?

    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.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    TE
    Senior Systems Administrator at Louis Stokes Cleveland VA Medical Center
    Real User
    Inventory management is a very simple, concise way to keep all that data together

    Pros and Cons

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

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

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

    What needs improvement?

    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.

    For how long have I used the solution?

    Less than one year.

    What do I think about the stability of the solution?

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

    What do I think about the scalability of the solution?

    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.

    How is customer service and technical support?

    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.

    How was the initial setup?

    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.

    What other advice do I have?

    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.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    DT
    Software Engineer at Arista
    Real User
    It is quick to production. It has an API in the back which allows for integrations.

    Pros and Cons

    • "It is quick to production. It has an API in the back which allows for integrations."
    • "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.""

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What needs improvement?

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

    For how long have I used the solution?

    One to three years.

    What do I think about the stability of the solution?

    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.

    What do I think about the scalability of the solution?

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

    How was the initial setup?

    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.

    What about the implementation team?

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

    Disclosure: My company has a business relationship with this vendor other than being a customer: Partner.
    CM
    System Engineer at a tech vendor
    Real User
    I can quickly train new users on writing a Playbook, the code is very human-readable

    Pros and Cons

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

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    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 needs improvement?

    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.

    For how long have I used the solution?

    One to three years.

    What do I think about the stability of the solution?

    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.

    What do I think about the scalability of the solution?

    It scales well because of the clustering.

    How is customer service and technical support?

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

    How was the initial setup?

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

    Which other solutions did I evaluate?

    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.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Andy Brittingham
    Systems Administrator at Main Street softworks
    Real User
    I was able to take the old build manifest and automate everything

    Pros and Cons

    • "It enabled me to take the old build manifest and automated everything. So when it came time to spin everything up, it was quick and simple. I could spin it up and test it out. And then, when it came time to roll production, it was a done deal. When we expanded to multiple data centers, it was same thing: Change a few IP addresses, change some names, and off we went."
    • "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."

    What is our primary use case?

    We use it to manage all configurations and deployments.

    How has it helped my organization?

    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.

    What is most valuable?

    The ability to centralize everything, to centralize management, and to push changes quickly and reliably. That's the main use for us.

    What needs improvement?

    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.

    For how long have I used the solution?

    Three to five years.

    What do I think about the stability of the solution?

    It's reliable.

    What do I think about the scalability of the solution?

    We're a small shop. It seems it could be quicker, but for what it does, it's fine.

    Which solution did I use previously and why did I switch?

    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.

    How was the initial setup?

    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.

    What other advice do I have?

    We mostly run everything CentOS, and do the Community edition.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    JoeGarcia
    Principal Engineer at CyberArk
    Real User
    The user interface is well-built and very easy to navigate around

    Pros and Cons

    • "The user interface is well-built and very easy to navigate around."
    • "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."

    How has it helped my organization?

    We are a partner, but we also use it in-house. It drives all of our demonstrations. We've used Ansible community to be able to easily deploy and set up pipelines end-to-end in Dockers or containers. Therefore, we can have an easy to go, ready demonstration set up in less than five minutes. We can also have a customer go to our GitHub page and just be able to use Ansible to have it easily deployed, then we don't have to give them any more instructions, i.e., run this playbook and you'll be set up in no time.

    Our sales engineers use it a lot in order to understand how the security works between Ansible and our own product, so they can better sell it. We have been lucky enough to have a great partnership with Red Hat, so we receive a lot of great feedback directly from their solutions architects. 

    We are always getting together and sharing information. We will be training them on Conjur, and on Thursday, they have us being trained on Ansible. So, it's a great partnership.

    What is most valuable?

    I really love the user interface:

    • The first time I started to use it, I found that it was well-built and very easy to navigate around. Things were were I expected them to be. I didn't have to go clicking around too much to find what I wanted to do. 
    • The documentation on their website is well done. Anytime that I need to, I can pull up its six tabs. For example, I wrote my first Ansible playbook with no Internet on a plane and those six tabs cached in my phone's browser. 

    Red Hat has always done a great job with their documentation. However, I sort of grew up around most of their products.

    As far as the dashboard is concerned, it is a nice, quick, easy look without having to dig in, deep dive into the different metrics, etc. I obtain a quick presentation of what's failed and what's been successful. Having an operator and/or admin get that quick of a look is beneficial because they can quickly act and react to job failures, etc.

    What needs improvement?

    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. I end up having to either custom-make my own credential type or trying to figure out what is already available that I can fit it into and use. I would prefer to see a lot of the more popular ones included as an out-of-the-box credential type. Because, at least for our integration with Ansible Tower, we do have to put a certificate and a key into the Tower credentials and custom-make that credential type.

    We're not the only product that does it. I feel like if it's such an adopted method of dealing with third-party tools, maybe we should add in that credential type and make it easier for everyone.

    For how long have I used the solution?

    One to three years.

    What do I think about the stability of the solution?

    Tower is stable, and AWX is not. AWX is not meant to be in production. 

    Tower is very stable. Sometimes the job isolation can cause me to rip out my hair, but I know now that it is the job isolation and not an issue on my end. So, I'm good now. 

    What do I think about the scalability of the solution?

    Scalability should meet our needs going forward.

    How is customer service and technical support?

    I've never had to use tech support. I've always been lucky enough to be a partner, so I get direct to where I need to go. I also haven't heard any complaints from our customers.

    How was the initial setup?

    It depends on the method that you choose. I deployed it in AWS just fine using the CloudFormation template that was provided on the website. As long as people are doing that, then they'll be good to go. I've never had an issue deploying. I can't imagine anybody having an issue deploying it. They do a pretty good job of orchestrating the orchestrator.

    What other advice do I have?

    I learned about the solution last year through AWX. Surprisingly enough, I found AWX first, then made my way to Tower from there.

    From a security standpoint, we are a security company so I will always back my product over what these other tools do. From their standpoint, we do practice adding certificates and keys into Tower credentials. We use and trust it. My preference would always be to get all of the secrets out of all the tools and manage them in a central location.

    They have some room for improvement, but they're doing a great job as is.

    Disclosure: My company has a business relationship with this vendor other than being a customer: Partner.
    Sergey Kletsko
    Solution Integrator at Kpco
    Real User
    It does not require staff for deployment and maintenance. It just works.

    Pros and Cons

    • "The most useful features are the playbooks. We can develop our playbooks and simplify them doing something like a cross platform."
    • "It does not require staff for deployment and maintenance. It just works."
    • "The documentation for the installation step of deployment, OpenStack, etc., and these things have to be a bit more detailed."

    What is our primary use case?

    We have reached the stage where we really need to automate all our tasks. That is why we are trying to use Ansible Tower.

    We are trying to help our customers simplify their deployment process for deploying their private clouds, like Red Hat object tags. We start by the deploying the director Undercloud, Overcloud, etc.

    We are trying to develop automation for White box switches: Integration, deployment, NOS installation, etc.

    What is most valuable?

    The most useful features are the playbooks. We can develop our playbooks and simplify them doing something like a cross platform. Because right now, during deployment of OpenStack on different platforms, it is behaving a bit different. We want, and are trying, to develop a universal solution for all platforms.

    What needs improvement?

    Right now, I am trying to understand the CLI, so the originals will be easier for me to use. Once I understand the CLI, the company will move everything to Tower.

    The documentation for the installation step of deployment, OpenStack, etc., and these things have to be a bit more detailed. For Dell and HPE, we are creating detailed instructions on how to deploy OpenStack Undercloud and Overcloud director step-by-step with very clear and detailed description.

    For how long have I used the solution?

    One to three years.

    What do I think about the stability of the solution?

    It is stable.

    How was the initial setup?

    It is easy.

    What about the implementation team?

    It does not require staff for deployment and maintenance. It just works.

    What's my experience with pricing, setup cost, and licensing?

    We went with product because we have a subscription for Red Hat.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    SS
    Senior Operations Engineer at a financial services firm with 5,001-10,000 employees
    Real User
    The "Organizations" feature allows me to give clear silos to different teams, but workflows and dashboards need improvement

    Pros and Cons

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

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

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

    What needs improvement?

    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.

    For how long have I used the solution?

    One to three years.

    What do I think about the stability of the solution?

    It's definitely stable and reliable.

    What do I think about the scalability of the solution?

    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.

    How is customer service and technical support?

    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.

    How was the initial setup?

    The initial setup was pretty straightforward.

    What other advice do I have?

    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.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Marek Jeerzejewicz
    Senior Director Network Security at Oracle Corporation
    Real User
    This solution allows us to stitch a lot of different parts of the workflow together, but it needs better documentation

    Pros and Cons

    • "This solution allows us to stitch a lot of different parts of the workflow together."
    • "It needs better documentation."

    What is our primary use case?

    Our group at Oracle has been using the product for at least a year. I have only been using the product for four months.

    How has it helped my organization?

    We have done a lot of work to do automation. Previously, it wasn't in the DNA of Oracle at all. Ansible has brought a platform which has allowed us to automate a lot of services, not just server services, but network services as well.

    This solution allows us to stitch a lot of different parts of the workflow together. We have integrations with some of our ticketing and monitoring systems, which allows work to start work happening.

    What is most valuable?

    The community support is broad with a lot of available plugins and modules. People have shared a lot of information about how to do things with the solution.

    What needs improvement?

    • How do you democratize Ansible across more engineers that don't have a large body of scripting knowledge to leverage? 
    • Do you bring Ansible down to that common denominator, or do you bring the engineer up to some common level of scripting capabilities? 

    I think we need to meet in the middle. We are trying to build tools which allow engineers who don't have a lot of scripting capabilities to still leverage the power of Ansible in more standardized ways without just a choose your own adventure approach. We are trying to make Ansible simpler for more engineers to be able to use and raise the level of engineering skills. We are trying to do both.

    Ansible could probably help here with better documentation.

    For how long have I used the solution?

    Less than one year.

    What do I think about the stability of the solution?

    It is stable.

    What do I think about the scalability of the solution?

    We definitely don't have any scale challenges at Oracle. I came from Microsoft, where scale was an issue. We have a small six figures of servers, so it's not a massive environment, so scalability is okay.

    How was the initial setup?

    The setup is straightforward. It's as easy as anything else to set up.

    Which other solutions did I evaluate?

    We do use Puppet and Chef in some other areas. However, Ansible is our dominant platform.

    What other advice do I have?

    It's an effective solution for the problem space.

    In terms of learning about the solution and finding new ways to do things or solving problems, I think you are a quick Google search away.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    NA
    Student at StarHub
    User
    There needs to be improvement in the orchestration. The automation is the most valuable feature.

    What is our primary use case?

    We are still implementing it.

    How has it helped my organization?

    Ansible automation has benefited our organization.

    What is most valuable?

    I have found the automation to be the most valuable feature.

    What needs improvement?

    There needs to be improvement in the orchestration.

    For how long have I used the solution?

    Still implementing.

    What is our primary use case?

    We are still implementing it.

    How has it helped my organization?

    Ansible automation has benefited our organization.

    What is most valuable?

    I have found the automation to be the most valuable feature.

    What needs improvement?

    There needs to be improvement in the orchestration.

    For how long have I used the solution?

    Still implementing.
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Monika Agrawal
    User at a tech services company with 10,001+ employees
    Consultant
    Simplifies maintaining configuration across environments, but lacks robust documentation

    Pros and Cons

    • "Ansible Galaxy is helpful for roles and Git Submodules: No dependency in managing playbooks. Also, fact caching in redis for host/role grp information speeds up execution. Finally, variable management is easy."

      What is our primary use case?

      We are using Ansible to automate the infra for various companies in the ASEAN region. The tasks include the creation of virtual machines, provisioning volumes/disks, database installation, user creation, and configuration. The environment includes Linux boxes and Nutanix for software-defined storage.

      How has it helped my organization?

      Ansible makes it easy to maintain configuration across environments and to maintain and execute the code through playbooks. It has helped us reduce manpower costs.

      What is most valuable?

      Everything in source control. All changes are visible while deploying.

      • Ansible Galaxy for roles and Git Submodules: No dependency in managing playbooks.
      • Fact caching in redis for host/role grp information: Speeds up execution.
      • Tags: To repeat task execution until the desired result is achieved. Quite useful in a test environment.
      • Ansible comes with an orchestration layer.
      • Sensitive data: Ansible has a command called ansible-vault. You can edit the file locally and it is saved in source control.
      • Easy variable management.

      What needs improvement?

      Improvement is required in the GUI. Sometimes results are different on CLI.

      For how long have I used the solution?

      Less than one year.

      What other advice do I have?

      Ansible is fast to deploy and develop in. I rate it a seven out of 10, for now. It doesn't work well with large-scale infra. Also, as I am a relative beginner (I have been working on Ansible for 6 months, mainly for automation) and the lack of documentation is an issue.

      Disclosure: I am a real user, and this review is based on my own experience and opinions.
      it_user870588
      User at Huawei Technologies
      Real User
      Role-based access control and agentless architecture are the main features, but the cost is high

      What is our primary use case?

      1600 host environment, which is mainly used for software updates. As a production environment, it is used for security compliance.

      How has it helped my organization?

      We are still implementing it. I have used it in a very small environment (10 hosts), and it performed well.

      What is most valuable?

      Role-based access control and agentless architecture are the main features which may attract users. It is also easy to learn.  Ansible Tower provides a GUI, which is an enhancement, and a well-liked feature by operation teams.

      For how long have I used the solution?

      Still implementing.

      What's my experience with pricing, setup cost, and licensing?

      The cost is high but it sill works well.

      What is our primary use case?

      1600 host environment, which is mainly used for software updates. As a production environment, it is used for security compliance.

      How has it helped my organization?

      We are still implementing it. I have used it in a very small environment (10 hosts), and it performed well.

      What is most valuable?

      Role-based access control and agentless architecture are the main features which may attract users. It is also easy to learn. 

      Ansible Tower provides a GUI, which is an enhancement, and a well-liked feature by operation teams.

      For how long have I used the solution?

      Still implementing.

      What's my experience with pricing, setup cost, and licensing?

      The cost is high but it sill works well.

      Disclosure: I am a real user, and this review is based on my own experience and opinions.
      BW
      Systems Engineer with 1,001-5,000 employees
      User
      There are no agents by default, so adding a new server is a couple lines of configuration

      Pros and Cons

      • "There are no agents by default, so adding a new server is a matter of a couple lines of configuration (on a new server and the configuration master)."
      • "Because Ansible is establishing SSH sessions to perform tasks, there is a limit on scalability."

      What is most valuable?

      The beauty of Ansible is the easy ramp-up to get started.  You really only need Python and SSH access. Configuration is generally done in YAML, which is easy to understand, and there is a progression from ad hoc tasks, to playbooks, then to roles, which means you can start with one server and continue building up to datacenters worth of servers with the same methodology. Also, shared by most configuration management tools, the idea of creating a desired state scales better than trying to specify procedural steps to set up new hosts. There are no agents by default, so adding a new server is a matter of a couple lines of configuration (on a new server and the configuration master).

      How has it helped my organization?

      There is some overhead in setting up the initial playbooks, but it now takes less time to set up 10 servers than it did to configure one in the past. Also, the setup is consistent because there is not the concern that someone forgot to copy/paste a config line or run another command. Whatever is in the playbook gets done.

      What needs improvement?

      Because Ansible is establishing SSH sessions to perform tasks, there is a limit on scalability. Speed and the sheer number of open connections start to become issues past a couple hundred servers. There are some workarounds, but that is a key area for improvement. Ansible could also improve support for private package repos, to ensure that new batches of servers are getting the same package versions as earlier batches.

      For how long have I used the solution?

      I have been using Ansible for about two years.

      What do I think about the scalability of the solution?

      SSH is pretty good, but it was not designed for the access pattern of hundreds of connections out of configuration targets. Other tools solve this with a listening agent process, so the initial connection to configure is much faster.

      How are customer service and technical support?

      I have not used customer service. Ansible is well established, so there is plenty of documentation, examples, and third-party resources.

      Which solution did I use previously and why did I switch?

      Manual configuration and "Golden" templates for virtual machines were used.  The former is tricky to maintain consistency with. The latter seemed to require constant updating and it did not help maintain the configuration of already installed servers.

      How was the initial setup?

      Initial setup boils down to installing Ansible and ensuring you have SSH access to a target that is running Python. Standard packaging is available on major Linux distros to install some level of Ansible. I recommend following instructions on Ansible's site to get the latest stable release as they have been improving rapidly.

      What was our ROI?

      Not applicable.

      What's my experience with pricing, setup cost, and licensing?

      Although Red Hat has an enterprise add-on to manage Ansible through a web application and offers commercial support, I have not used it. Like many Red Hat products, they have a no-cost version of the web application (AWX, formerly Ansible Tower), but you are on your own to install and it is a little more complicated than just installing Ansible. AWX will probably be required in most shops for the RBAC functionality. With AWX, non-admins can be limited to perform some tasks, but not be allowed free reign with Ansible.

      Which other solutions did I evaluate?

      Salt (or SaltStack) is a similar tool, but does have an agent. There are other tools like Chef or Puppet that use languages other than Python. Ansible was chosen based on these characteristics and the others were not evaluated after this initial choice.

      Disclosure: I am a real user, and this review is based on my own experience and opinions.
      it_user573504
      Senior DevOps/Build Engineer at a tech vendor with 10,001+ employees
      Vendor
      Easy to maintain and support.

      What is most valuable?

      I like Ansible because it is:

      • Easy to use.
      • Easy to read.
      • Easy to maintain.
      • Easy to support.
      • It works without an agent.

      How has it helped my organization?

      It has made software installation and updates much easier. Tasks including changing or checking configurations and files have been improved especially considering the big scope of servers.

      What needs improvement?

      It could work with a larger number of servers.

      For how long have I used the solution?

      I've been working with Ansible since v0.7 and still use v2.2.

      What do I think about the stability of the solution?

      We only encountered issues with syntax, as sometimes it was changed and then one has to adapt.

      What do I think about the scalability of the solution?

      There were a few scalability issues. I had no problems as long as the number of servers was less than 500. When the number of servers has exceeded 500, I encountered an increased number of failures when trying to provision all together. I tried to play with forks, timeouts, and other options, but as the number of servers grew, I got more failures, so I had to provision smaller groups.

      How are customer service and technical support?

      I haven't yet used it.

      Which solution did I use previously and why did I switch?

      I used bash scripts before, but bash is not idempotent and you should write more code whereas Ansible already has them as a module. Ansible gives you an informative report after each task.

      How was the initial setup?

      It was easy to install and easy to use.

      What's my experience with pricing, setup cost, and licensing?

      I use the free version with Jenkins, it's enough for my needs.

      Which other solutions did I evaluate?

      We did not evaluate other options.

      What other advice do I have?

      It should work easily.

      Disclosure: I am a real user, and this review is based on my own experience and opinions.
      ITCS user
      Senior System Engineer at a computer software company with 51-200 employees
      Vendor
      ​Agentless architecture, relying on SSH only. Speed can be improved, but it only can go as fast as SSH does.

      What is most valuable?

      Agentless architecture, relying on SSH only. Great documentation.

      How has it helped my organization?

      Provision and configure from nothing on Amazon.

      What needs improvement?

      Speed but it only can go as fast as SSH does.

      What was my experience with deployment of the solution?

      6 months

      What do I think about the stability of the solution?

      No.

      What do I think about the scalability of the solution?

      A little slow.

      Which solution did I use previously and why did I switch?

      Used S before. Switched because of coworkers and even if I find SaltStack easier to learn, the documentation of Ansible made me choose it over Salt.

      How was the initial setup?

      Not at all, just need to have general knowledge of SSH.

      What's my experience with pricing,

      What is most valuable?

      • Agentless architecture, relying on SSH only.
      • Great documentation.

      How has it helped my organization?

      Provision and configure from nothing on Amazon.

      What needs improvement?

      Speed but it only can go as fast as SSH does.

      What was my experience with deployment of the solution?

      6 months

      What do I think about the stability of the solution?

      No.

      What do I think about the scalability of the solution?

      A little slow.

      Which solution did I use previously and why did I switch?

      Used S before.

      Switched because of coworkers and even if I find SaltStack easier to learn, the documentation of Ansible made me choose it over Salt.

      How was the initial setup?

      Not at all, just need to have general knowledge of SSH.

      What's my experience with pricing, setup cost, and licensing?

      Open source.

      Disclosure: I am a real user, and this review is based on my own experience and opinions.
      ITCS user
      Consultant at a tech consulting company with 1,001-5,000 employees
      Consultant
      Easy, straight to the point for a non programmer. But it's a young product - improvement needed on the module side.

      What is most valuable?

      The simplicity of the programs is the best part and the fact that there is no need to install clients on your hosts makes it unique compared to other orchestration tools.

      How has it helped my organization?

      We can now go to a customer and deploy all software in a few minutes instead of hours.

      What needs improvement?

      It's a young product so there is still room for improvement on the module side. There are about 150 modules at the moment but there are still many missing.

      For how long have I used the solution?

      For a couple of months

      What was my experience with deployment of the solution?

      Deployment is easy, it cannot be any easier.

      What do I think about the stability of the solution?

      The software is so small and well written that there are no stability issues. At the moment there is a new update every 2 months so if there is an issue with a bug it will be fixed in the next release.

      What do I think about the scalability of the solution?

      It scales from a few up to 1000's of servers so does it scale - YES!

      How are customer service and technical support?

      Customer Service: No idea. It's so simple and there is so much support on the internet that so far I have had no need to look for support.Technical Support: People at Ansible have been very nice to me so far even without a support contract. I get pointed to the help boards to get answers to my questions by their support staff.

      Which solution did I use previously and why did I switch?

      We use all kinds of solutions like puppet, chef, .... Why do I like Ansible more? Ansible is easier, it makes use of yaml, and templating is done with jinja2. With other solutions there is a steeper learning process. Ansible is so easy that it takes you only a few minutes to get going. Where other solutions are more for programmers, Ansible is made for system engineers without any need to program or script in any language derivatives. Ansible puts all the intelligence in the modules.

      How was the initial setup?

      Setup is easy. Every distro has packages available and if you have a weird distro that hasn't one, you can install it easily with python pip or download it from github.

      What about the implementation team?

      We installed it in-house. It is so simple for an IT person that with the online documentation that it should be easy to set you up in minutes.

      What's my experience with pricing, setup cost, and licensing?

      The product is free, at least if you make use of the command line version. There is also a graphical version that has some extra features in reporting, etc. Here the price depends on the number of clients you want to manage. For us the cost was the time it took to learn the product which was only a day or two.

      Which other solutions did I evaluate?

      Puppet, Saltstack, Chef

      What other advice do I have?

      If you are looking for something easy straight to the point for a non programmer this is what you need!!
      Disclosure: I am a real user, and this review is based on my own experience and opinions.
      Buyer's Guide
      Download our free Ansible Report and get advice and tips from experienced pros sharing their opinions.