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

Pricing Advice

What users are saying about Ansible pricing:
  • "Red Hat's open source approach was a factor when choosing Ansible, since the solution is free as of right now."
  • "If you only need to use Ansible, it's free for any end-user, but when you require Ansible Tower, you need to pay per Ansible Tower server."

Ansible Reviews

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
MC
DevOps Consultant at a government with 501-1,000 employees
Consultant
Enables us to efficiently manage an almost unlimited number of nodes

Pros and Cons

  • "Being a game-changer in configuration management software is what has made Ansible so popular and widespread. Much of IT is based on SSH direct connectivity with a need for running infrastructure in an agentless way, and that has been a big plus. SSH has become a great security standard for managing servers. The whole thing has really become an out-of-the-box solution for managing a Unix estate."
  • "Some of the modules in Ansible could be a bit more mature. There is still a little room for further development. Some performance aspects could be improved, perhaps in the form of parallelism within Ansible."

What is our primary use case?

We use it to configure operating systems, apply security, and for day-to-day management. Our use cases include collecting information from end nodes, rather than writing shell scripts or any other types of scripts, as was done historically, and rather than even logging in manually and collecting information from the nodes. These days, you write an Ansible playbook and it does things for you. And if you don't have a playbook, you can simply gather the facts from the nodes, and that's available out-of-the-box without writing anything. You simply utilize the Ansible modules.

Our Ansible deployment is for a hybrid environment. We have on-premises services that we use Ansible to configure as well as cloud instances.

How has it helped my organization?

Historically, lots of things had to be orchestrated manually. There weren't any great tools to do configuration management across multiple nodes. IT servers were physical but then moved into virtual, and with that change came the need to manage more and more nodes. It became quite time-consuming, and employing people to manage hundreds or thousands of servers wasn't really a great solution. Ansible, as an orchestrator, has filled the gap. It allows you to manage an almost unlimited number of nodes with a single body. That has been a great improvement in the way organizations manage their estates.

In addition, we're able to configure or deliver something to our end nodes step-by-step. You can have dependencies, types of conditions, between steps. For example, if something isn't present or it's not happening on that node, you can skip steps and move to another one. This ability definitely helps. In the past, a lot of things had to be done manually or with a semi-manual script. Ansible automates those things. As long as you've got your playbook written up and tested correctly, you can run it with confidence against your production system.

Ansible also saves us time when it comes to service deployment, moves, and updates. If we consider the effort involved in writing playbooks, and the effort to deploy them, Ansible saves 80 to 90 percent when it comes to the time involved in these scenarios.

Another advantage is that Ansible enables collaboration across teams. We're transparent. Whatever we deliver needs to be backed by the code. That code lives in source control. Anybody who is capable and wants to could grab that code. Playbooks are an example. They could simply apply them against the target. This is a form of collaboration, where one person does something and another can grab it and use it. Obviously you need source control, but multiple people can work on a specific project together and can have influence on that project, providing updates, features, and bug fixes to the project.

We have certainly seen an improvement in automation. With Ansible, you can pretty much automate everything. You work on a desired state. And we have been able to apply current, modern security standards to the estates. From a security perspective, our servers are now fully compliant with modern security standards. We are able to use Ansible to run some benchmarks against them to see if they're fully compliant.

What is most valuable?

Being a game-changer in configuration management software is what has made Ansible so popular and widespread. Much of IT is based on SSH direct connectivity with a need for running infrastructure in an agentless way, and that has been a big plus. SSH has become a great security standard for managing servers. The whole thing has really become an out-of-the-box solution for managing a Unix estate. Managing a Windows or Microsoft estate via Ansible is a little bit different and I believe that requires the installation of some agents.

Another advantage is that Ansible did not require us to change our existing infrastructure in any way. This issue ties in with the SSH connectivity. You don't have to prepare any infrastructure to use Ansible. When you provision an operating system, that SSH remote connection is available. It's embedded in the operating system. That means you don't have to enable anything. All you have to do is make sure you can reach the nodes, either via SSH, passwordless authentication, or possibly other mechanisms. We've only been using SSH, and it does the job very well.

What needs improvement?

Some of the modules in Ansible could be a bit more mature. There is still a little room for further development. Some performance aspects could be improved, perhaps in the form of parallelism within Ansible. 

Also, some of the Ansible versioning or backward compatibility, or Python changes, could have been handled a little bit better. 

But all these challenges could potentially be offset by the way you use Ansible. For instance, you could have Ansible Docker-ized and that would make your Ansible environment fixed and static and fully controlled. That way you wouldn't be worried about your server or your local workstation that is used for deployment.

These aren't huge issues, they are just things to keep in mind, but it all depends on how you use the product.

For how long have I used the solution?

I have been using Ansible for a good few years. I started five to seven years ago, by first writing Ansible playbooks, simply to orchestrate configuration management of the estate at that time. I was mainly using it on Linux servers.

What do I think about the stability of the solution?

The stability of Ansible is great. Historically, we have had some compatibility issues, such as during a Python change a library had to be downgraded. Other than that kind of minor issue, the product has been very stable.

What do I think about the scalability of the solution?

It's quite scalable. I don't think there are huge limits in terms of what you can do. I have not run any performance benchmarks for Ansible. I don't know how long it would take to upgrade 10,000 nodes compared to competitors. But I feel Ansible could be nicely scalable. An orchestrator would allow you to simply have Ansible containers, perhaps on Kubernetes, and they would run something against the nodes. Having multiple Ansible nodes, or multiple pods of Ansible containers, running code against targets in parallel, would be a scenario in which I could hardly imagine any limits.

We are managing between 1,000 to 2,000 servers.

My team is more of a development team, so we don't run Ansible on a daily basis for operations. We mostly program or develop robots that run Ansible when needed. As for other teams, I'm not sure how they use it, but whenever they need to collect something from these hosts or need to quickly push a similar update to all hosts, I think they would use Ansible. While it's not being used on a daily basis in our organization, it's certainly being used.

How are customer service and support?

The typical Red Hat support, the kind you access via their portal or email, can vary. Sometimes things are not done as quickly as you would want, but it's standard support and you get what you pay for. Moving up a level, if you were to get TAM support, things would improve a bit because you get dedicated technical contacts with whom you speak on a weekly basis. They help push things along. However, you're still tied to the Red Hat backlog and its engineering, which is not always the fastest. Often they have a different view and different priorities. We have had some cases where they have simply said, "We're not delivering this. We're not doing this," but they did not provide a rationale as to why. 

Overall, the results are mixed when it comes to support. It's not that bad, but there's room for improvement.

How would you rate customer service and support?

Neutral

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

I've used Puppet a little bit, but I quickly moved into Ansible as it became a standard over Puppet, Chef, and perhaps SaltStack. We moved quickly into Ansible. When Ansible was acquired by Red Hat, it quickly became a very interesting product. The first bullet point was the agentless infrastructure for Ansible.

Red Hat's open-source approach was also a factor for me, certainly. I'm an open-source enthusiast. It's a big plus that Ansible is an open-source project, and it's free. They gained popularity from that as well.

How was the initial setup?

When you need to use Ansible, you need to grab the Ansible binary. A typical method in Linux would be to use the Package Manager to install it. You could also use a Python-native method for installing it through pip.

Another good method would be to simply get your Ansible Docker-ized or pull a Docker image from a third-party repository and that image would have Ansible deployed in it. That way, every time you need to run Ansible, you could just an image and that image would provide the binary for Ansible.

The next step is related to your particular use case, what you need to use and how you need to use it. For example, if you want to write a small portion that does something, you simply instruct Ansible to use that code against the targets. By "targets" I mean you need to provide an inventory that you want to run your code against.

Another step that needs to happen in order to use Ansible nicely is to set up passwordless authentication to use SSH keys instead of passwords. That's what should probably happen together with installing or delivering Ansible binaries. Once you have these elements, binaries and authentication, your system is pretty much ready to be configured through Ansible.

Because I'm quite senior and specialized in Red Hat and, in general, a Linux expert, deploying Ansible literally takes me minutes.

Implementation strategy would vary from case to case, but one of the popular ways of deploying Ansible is to have a bastion host that allows you to access your estates over SSH keys and simply have Ansible running from that host. Ideally, you would like to see what Ansible is changing on every run so a good practice would be to have CI/CD orchestration for Ansible, using Jenkins or another CI/CD tool that allows you to keep historical logs on how Ansible behaves, and what has changed in an estate during an Ansible run. That would be the minimal implementation I would suggest for an organization.

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

We're not paying for it, but if you were to buy it, you would get Ansible Tower. That is what they are charging for, if I recall correctly.

Which other solutions did I evaluate?

Ansible seems to have been quite well received. There are competitors, or there were when I started using it several years ago, but Red Hat, with community development, has become the easiest to use, compared to Puppet or Chef. That is how Ansible gained popularity across the IT market.

Another element in why Ansible became so popular is the way things are being pushed to the end nodes. We're using existing SSH connectivity, which is a common way to manage Unix servers. That became available out-of-the-box. The competitors usually ask you to install agents and that brings with it challenges, such as how to orchestrate installing agents. Ansible does not suffer from that problem. Every Unix server must have SSH enabled by default and Ansible simply uses that.

What other advice do I have?

It's a great tool. It's easy to use. Do your own research and run a spike to compare Ansible with competitors and simply pick whatever suits you. But a great plus for Ansible is its simplicity.

For doing basic things, or things Ansible was designed for, you probably don't need special coding skills. All you likely need to know is how to properly structure a YAML file, and YAML is now a common language across development. However, if you were to do things that are a little bit more advanced in Ansible, Python would be something that you would want to study or be good at. That would help you write custom Ansible modules or provide further input into existing development to improve them or deliver additional bug fixes and features.

We spike the open-source version of Ansible Tower, and Tower is not difficult to learn if you have experience with Ansible and with Unix. Deployment of it is relatively easy. We have not found a great use case for it, to be honest. At that time, it was more for compliance and, maybe, a Chrome-job type of product, and we had the orchestration for that already.

When it comes to SLAs, I don't think Ansible has created a great change for us. Once you achieve a certain level of automation in an organization, you're probably not going to feel any changes when it comes to SLAs because you have already built that capability. Our SLAs are well maintained and are at a high standard, but I don't feel Ansible has had a huge influence on them because we were mature in that area. But perhaps for some organizations, it would have a significant effect on what they offer. Being able to do more via automation means services are up more than they might have been.

We are using other Red Hat solutions in our environment, including Red Hat Enterprise Linux, Red Hat OpenShift, Red Hat Satellite, and we have also used Red Hat Virtualization. All of these products integrate nicely with Ansible. It's mainly because they're fully backed by variations or just pure Red Hat Enterprise Linux. The integration is great. Whatever you can do on Linux, can probably be done on any other Red Hat products that are based on similar technology. There are no limits.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
NishantSingh
Student at ARTH
Real User
Top 20
Helpful for creating an environment and easy to use with dynamic inventory capability

Pros and Cons

  • "Ansible is agentless. So, we don't need to set up any agent into the computer we are interacting with. The only prerequisite is that the host with which we are going to interact must have the Python interpreter installed on it. We can connect to a host and do our configuration by using Ansible."
  • "Ansible is great, but there are not many modules. You can do about 80% to 90% of things by using commands, but more modules should be added. We cannot do some of the things in Ansible. In Red Hat, we have the YUM package manager, and there are certain options that we can pass through YUM. To install the Docker Community Edition, I'll write the yum install docker-ce command, but because the Docker Community Edition is not compatible with RHEL 8, I will have to use the nobest option, such as yum install docker-ce --nobest. The nobest option installs the most stable version that can be installed on a particular system. In Ansible, the nobest option is not there. So, it needs some improvements in terms of options. There should be more options, keywords, and modules."

What is our primary use case?

Basically, Ansible is a configuration management tool. Mainly, I've been using Ansible for making changes and for deployments, such as of web servers. I also use it for servicing instances, mostly from AWS. I use AWS Cloud, and I configure the instances that I've launched.

Recently, I've also created an Ansible role. Basically, you can contribute to Red Hat in the form of an Ansible role. Everybody can share their code with just simple commands, such as Ansible Galaxy. With a few commands, we can share each other's infrastructure.

How has it helped my organization?

It helps us to create an environment. I'm a student. As students, when we get into newer technologies, we can't share our infrastructure with each other, and it gets difficult to explain to everybody. For example, I want to tell my friend to do certain things so that his infrastructure is similar to mine. In such a case, I'll just create a playbook from Ansible, and I'll just share it with him. He will just run that playbook, and we both will have the same infrastructure. 

It doesn't require us to change our existing infrastructure in any way. We just need Ansible software on the managed host. So, it just needs to have Ansible. The host with which we are going to connect should have the Python interpreter installed, and nothing else. 

It saves time when it comes to service deployment, moves, or updates. We have created playbooks, which are very easy to create. They are scripts in Python. A playbook also acts as a documentary for you. You can refer to a playbook any time, and it definitely saves a lot of time. It gives very good results in a long run. You just have to invest time in creating the first playbook. After that, you just use it. While creating a playbook, you can specify keywords by using Ansible variables. For example, to launch an instance in AWS Cloud, I need to specify a name to it. If I need to launch two to three instances at once, I will create a variable for it and pass it externally through the Ansible playbook. Next time, you can change the keyword and run the playbook.

What is most valuable?

Ansible is agentless. So, we don't need to set up any agent into the computer we are interacting with. The only prerequisite is that the host with which we are going to interact must have the Python interpreter installed on it. We can connect to a host and do our configuration by using Ansible. 

Its dynamic inventory capability is very useful. For example, we are provisioning instances in AWS, and I want a particular name tag. My name tag is my instance, and I've been running a lot of instances in AWS Cloud. If I want, I can filter and configure all instances running with a specific name. I can also dynamically fetch IPs. What happens in the AWS cloud is that if you shut your operating system down, and you do some reboot and stuff like that, then you'll lose the public IP. Being able to dynamically fetch IP is the main capability that I like in Ansible.

It is very easy to use. Anybody who has studied computer science or is from the mathematical field can easily use Ansible. You just have to know how to do a certain task. For example, if you want to make some changes to your firewall and maybe set up a web server, you don't have to know all the commands with respect to different operating systems such as Linux and Windows. You don't need to know commands, and you just need to have a basic idea about how you want to do it. It is very easy to use. You just have to know how to do it.

What needs improvement?

Ansible is great, but there are not many modules. You can do about 80% to 90% of things by using commands, but more modules should be added. We cannot do some of the things in Ansible. In Red Hat, we have the YUM package manager, and there are certain options that we can pass through YUM. To install the Docker Community Edition, I'll write the yum install docker-ce command, but because the Docker Community Edition is not compatible with RHEL 8, I will have to use the nobest option, such as yum install docker-ce --nobest. The nobest option installs the most stable version that can be installed on a particular system. In Ansible, the nobest option is not there. So, it needs some improvements in terms of options. There should be more options, keywords, and modules.

For how long have I used the solution?

I've been using Ansible for about one and a half years.

What do I think about the stability of the solution?

It is quite stable. It has been good so far. I didn't find any bugs. 

We do our operating system-related configurations and router configurations by using Ansible. I am focusing on operating system-based configuration because I use it in the operating system, and it has been quite stable.

What do I think about the scalability of the solution?

It is scalable. You just need to know the IP address of the new operating system with which you are going to interact. You just need to enter credentials into Ansible inventory. You have to make entries to this inventory, and you are good to go. You can use the same configuration that you have been using in your previous host.

How are customer service and technical support?

I have not interacted with their technical support because I didn't come across any issues from Red Hat's side. It has been stable, and there was no need to contact them.

There is an open-source community of Red Hat and Ansible Galaxy where users contribute. I've contributed two to three times. 

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

I just started using Puppet and Chef. The main thing where Ansible stands out is that you don't need to make any changes to the upcoming hosts. With Puppet and Chef, you have to install an agent program that will act as a layer for interacting with the host. You need to install an agent in between, which takes time as well.

How was the initial setup?

It is a very straightforward process. There is a package available on their site. After we download their software for the respective distro, we just write the installation command, and everything runs greatly. After installing the product, most people make use of Ansible roles. Ansible Galaxy is already filled with a lot of roles. A lot of developers have already contributed to a great setup with their proper codes. As a user, I have to just install a role or just download it from the site. It was not a lengthy or complex process. It was very easy.

For the initial setup, it takes about 10 to 15 minutes in going through sites and searching for a particular version. The installation will take about 5 minutes. After that, you have to configure Ansible properly, which might take a little bit of time, but it also depends on whether you know the IP address of the host. If you know the IP address and credentials, then you just have to enter it in the Ansible configuration file, and it is done. 

There is good integration between RHEL and Ansible. There are repositories configured for Ansible and you just enter the yum install ansible command, and it will do all the setup and it will also create a basic configuration file. The only remaining task would be to configure that inventory. You need to know the IP address of the host to which you are going to connect and the password. After you enter it into the inventory, it runs very quickly. There is no need to download it from any site. If you're using Ansible with Red Hat, then there is very little chance of any error while using Ansible.

Ansible's documentation is well-maintained and updated very frequently. You just need to go through the documentation. It is very easy to read. There is nothing much to worry about.

What other advice do I have?

Ansible Tower has great integration capabilities with enterprises solutions such as OpenShift and many more. I've seen many people integrating OpenShift with Tower, but I have not done it.

Before going for automation, one must first know the manual approach to it. After you've applied a manual approach, you can easily understand what type of automation you can do for your environment and infrastructure and how to do the automation.

When it is utilized with RHEL, things are very easy to understand. If someone has knowledge of RHEL, then they also have knowledge of Ansible. There is no need to study more about this. While using Ubuntu or different distros, you have to know more about Ansible, your OS-based package managers, and your internal configuration.

I'm currently preparing for the Ansible examination. I connect with their products remotely. They have configured every repository that one needs in their licensed products. Subscription will definitely be needed if you want to use it in the industry. If you just want to know about it, a subscription is not required.

I would rate Ansible an eight out of 10.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
Learn what your peers think about Ansible. Get advice and tips from experienced pros sharing their opinions. Updated: October 2021.
543,089 professionals have used our research since 2012.
DE
Linux Platform System Administrator at a healthcare company with 10,001+ employees
Real User
Top 5
Its agentless, making the deployment fast and easy

Pros and Cons

  • "It has improved our organization through provisioning and security hardening. When we do get a new VM, we have been able to bring on a provisioned machine in less than a day. This morning alone, I provisioned two machines within an hour. I am talking about hardening, installing antivirus software on it, and creating user accounts because the Playbooks were predesigned. From the time we got the servers to the actual hand-off, it takes less than an hour. We are talking about having the servers actually authenticate Red Hat Satellites and run the yum updates. All of that can be done within an hour."
  • "When you set up Playbooks, I may have one version of the Playbook, but another member of the team may have a different vision, and we will not know which version is correct. We want to have one central repository for managing the different versions of Playbooks, so we can have better collaboration among team members. This is our use case for using Git version control."

What is our primary use case?

We use it for patching and configuration management.

We are a healthcare institution. We have less than 500 hosts. Ansible is used between the infrastructure and applications, and primarily has Red Hat as the OS.

How has it helped my organization?

It has improved our organization through provisioning and security hardening. When we do get a new VM, we have been able to bring on a provisioned machine in less than a day. This morning alone, I provisioned two machines within an hour. I am talking about hardening, installing antivirus software on it, and creating user accounts because the Playbooks were predesigned. From the time we got the servers to the actual hand-off, it takes less than an hour. We are talking about having the servers actually authenticate Red Hat Satellites and run the yum updates. All of that can be done within an hour.

What is most valuable?

  • Ad-hoc commands
  • Playbooks
  • Setting up and deleting users
  • Patching
  • Using it for quick and dirty deployment of scripts.

The YAML syntax is easy to use, but it takes some getting used to. I feel like Microsoft Visual Studio helps with the YAML syntax, lining it up correctly. However, if you're doing it from the command line without actual spacing, that could be a little problematic. The new version of Visual Studio is quite helpful because Git is integrated with it. The YAML markdowns are also in place. My staff doesn't need special coding skills to use it.

We have multiple Playbooks to configure a server. We can break it up or make one main YAML script to push out all the individual dependencies.

What needs improvement?

When you set up Playbooks, I may have one version of the Playbook, but another member of the team may have a different vision, and we will not know which version is correct. We want to have one central repository for managing the different versions of Playbooks, so we can have better collaboration among team members. This is our use case for using Git version control.

Collaboration across teams is a great goal to accomplish, but that would necessitate more visibility to other teams of what Ansible is capable of with the database teams and other individual applications. Because we have so many applications, I don't know if they are aware of how Ansible could be beneficial to them. That would necessitate a broader conversation within the IT infrastructure application teams.

While it saves time with fewer moves, there could be still room for improvement because we do not actually manage the VMs. Instead, this is managed by the Windows team, who spins up the VM. Then, once the VM is handed off, we do the security hardening. If we received the request from the application owner to spin up the VM to hand it off, then we could take that entire process and get it streamlined. Whereas, it is handled by a different team right now.

It would be great if we could leverage Ansible Tower and Red Hat Satellites more. 

API integration would help because right now our security team uses Splunk, and they are independent of my team, which is the Unix team. Therefore, if we could tie in Splunk with products, like Ansible, Cylance, and Rubrik for backup, then we could get all that information in a central console. We have not previously raised this suggestion because our Ansible Engine needs to be upgraded so we can get support for the Ansible product.

For how long have I used the solution?

We have been using Ansible for at least four years.

What do I think about the stability of the solution?

We have not had any issues with Ansible. One of the projects that we have allocated for this year is to migrate our control station from RHEL 6 to RHEL 7.

We really don't have anyone maintaining it. It was a plug and play solution. We downloaded Ansible and ran it, because everyone knows how to use Ansible on the team at this point. Right now, I am trying to get to the next phase of using Git to set up more version control.

What do I think about the scalability of the solution?

The scalability is excellent.

Four guys use it on the Unix team.

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

We were previously using Bash scripting. 

We did try BigFix for two years. However, because of costs, Ansible proved to be better cost-wise. The licensing fee was a big issue with using BigFix. Control from the BigFix perspective was a concern, because you were locked into the GUI. With Ansible, we were able to do everything from the command line and touch the entire environment from the command line. Once you use BigFix and an issue, you then have to log out or go into the box from one of the servers, but you were locked into the GUI in BigFix.

How was the initial setup?

It is agentless. All we had to do is set up the control station, then Python was installed on all our Linux hosts. So, it was easy. The deployment took less than an hour.

The SSH keys were already in place. We already had the account, where we tested it out beforehand. Therefore, we knew exactly what we needed to do to deploy it. The keys were the hardest thing to set up and that was already in place (prior to Ansible).

What about the implementation team?

The entire Linux group of four guys was involved in the deployment. We never had to use Red Hat resources to set up Ansible.

What was our ROI?

Ansible is primarily used for provisioning or hardening our servers. The realization of getting a server from testing to actual production is very short in our environment because the processes have been streamlined. Before Ansible, the processes were a lot more unwieldy. We went from a week to less than a day where you can get your server hardened, provisioned, and handed off to the application owner.

Costs are negligible when using Ansible. The costs are just learning to use the solution's various options. We save time and efficiency versus other solutions.

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

We have tested out Ansible Tower, but there is a budget issue, so that is in our next phase.

Red Hat's open source approach was a factor when choosing Ansible, since the solution is free as of right now.

Which other solutions did I evaluate?

We have Red Hat Satellites and looked into Red Hat Insights, which we are still not fully deployed on yet. The integration between Red Hat solutions is seamless.

We looked into BigFix. I also looked at SaltStack and Puppet, but didn't get anywhere with that. I wanted something that had ease from a management perspective. Other solutions besides Ansible needed us to use agents, and I felt that would cause too many problems. Management didn't want a disruption of servers or downtime. I couldn't give them the assurance that installing something with an agent would not cause issues. So, this affected our decision to go with Ansible.

I don't think any product that we looked into could compare to Ansible.

What other advice do I have?

Test the environment because it is easy to use. Once you are proficient with Unix and Linux, it is extremely easy to use it: Setting up the inventory system, YAML files, and SSH keys.

I have no complaints about Ansible. I just wish I had more time to really delve into it.

I think we not using Ansible to its fullest potential, because of:

  1. Training.
  2. Time.
  3. Not knowing all the options available.

I haven't been exposed to Ansible Tower much. I have only tested it out three times. Right now, I am a little rusty on it, so it will take some getting used to again. It is more GUI-based, so it is pretty user-friendly.

The biggest lesson learnt: There are multiple ways of doing the same thing.

I would rate this solution as a nine (out of 10) because of the configuration management for all our servers in the environment. It can be used within the networking field for all devices, such as Cisco switches. The solution speaks to Windows hosts as well. It just takes time to use all the functionality and get it visible across the organization.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
AliceGolakiya
Operations Executive at Infosys Ltd
Real User
Top 5
Integration with a CI/CD tool, like Jenkins or Bitbucket, notably reduces service deployment time

Pros and Cons

  • "One of the most valuable features is that Ansible is agentless. It does not have dependencies, other than Python, which is very generic in terms of dependencies for all systems and for any environment. Being agentless, Ansible is very convenient for everything."
  • "The area which I feel can be improved is the custom modules. For example, there are something like 106 official modules available in the Ansible library. A year ago, that number was somewhere around 58. While Ansible is improving day by day, this can be improved more. For instance, when you need to configure in the cloud, you need to write up a module for that."

What is our primary use case?

My use cases with Ansible include configuring network devices. That is what I used it for when I was first learning Ansible. I then automated PKI (public key infrastructure) compliance. That particular domain has different servers and I developed an automation solution, using Ansible, to automate the configuration of the PKI servers. And for the last eight or nine months, I have been working on automating cloud solutions, such as deploying services or upgrading or migrating to a specific version of a product.

I am working on a client network, and that client also has clients who are hiring our client for hosted services, such as websites or internal applications for their employees or for their end-users. All the database-related activities and operations are being handled by our client. What I am doing, in that context, has to do with patches. There are patch releases, or bundles, or package upgrades, but the developers of those packages can't go and directly upgrade the particular sites of every customer. So we have developed an automation solution for them, using Ansible, that can directly trigger these processes. They can point out that "this is the package," and our automation in the backend, using Ansible, takes care of it.

It's a tool to automate different domains and Ansible can reduce human efforts for two domains in particular. One is DevOps and the other is network automation.

How has it helped my organization?

It's a total automation tool. Where you might need 100 employees to do a certain type of work manually, by developing Ansible modules, that type of work can be done by one employee. It just requires a simple SSH to the target nodes and then you can do whatever you want.

We had a scenario, the public key infrastructure project, in which there were multiple components. Some of my colleagues had automated some domains, such as a firewall domain. We then needed to integrate components, the firewall servers and the PKI servers, so that they could communicate with each other, and for security purposes. Ansible helped with that.

When you compare a process done by Ansible with human effort, there is a large time-reduction ratio. In a scenario involving networking, if it is done manually, the human effort will involve logging in to the system, entering user credentials, installing software, and configuring it to make the system ready. If there are 100 such systems, we would need to do the same process to all 100 systems, one by one. Whereas with Ansible, you just need to configure the IP addresses of those systems and, with one click, your job is done.

And when we integrate Ansible with a CI/CD tool, like Jenkins or Bitbucket, that reduces service deployment time by more than one hour. Also, we have site deployment where we require multiple servers. For example, when we have a database server, it needs many other components as well. When we deploy all those services manually, using a UI or a console in the cloud, it takes more than 10 hours to deploy one site. With Ansible, we automate that task once and it can do it in an hour, and the site will be provisioned successfully.

What is most valuable?

One of the most valuable features is that Ansible is agentless. It does not have dependencies, other than Python, which is very generic in terms of dependencies for all systems and for any environment. Being agentless, Ansible is very convenient for everything.

If you are good at Python and willing to customize Ansible modules, you can develop Ansible modules and, at one go, you can automate whatever you want.

When I started learning Ansible, I didn't know Python or any other programming language. But even so, I was easily able to understand what Ansible is doing and how I should write a playbook so that Ansible executes its tasks properly and the results are met, per my requirements. It's a simple English language and YAML script. Even folks with a non-IT background can write Ansible playbooks.

I have also been using Ansible Tower for about six months. It is nothing but a GUI version of, or experience with, Ansible. Ansible itself is a simple CLI tool, but with Ansible Tower there is a GUI, similar to Windows and Linux. There are a number of Ansible Tower servers, so if you want to run playbooks on multiple systems or you want to run multiple playbooks at the same time, you can do so using Ansible Tower. It is very dynamic. It's very easy to use. Even a non-IT employee or a non-IT student can understand Ansible Tower. The UI is very simple. Moreover, it has LDAP, Active Directory, and many other integrations, by default.

Suppose you have set something up, that you have pushed some code to the repo. Even your colleagues can test it using Ansible Tower. Or suppose I have run an Ansible Tower job and I am facing an issue with it. I can give a colleague the job ID and ask them to have a look and help me resolve it. That type of process is very easy, as Ansible Tower is like a common infra for employees to work together. 

Ansible Tower provides a central solution for automation. For example, in the previous project I worked on, we were automating some domains. Then we provided the sandbox URLs to the client for them to test whether the code the vendor had provided was working properly. They were able to run it in different ways with Ansible Tower. They used the Ansible Tower jobs with which we tested things for reference. Ansible Tower is a kind of UI dashboard for Ansible end-users. That is an added advantage of Ansible Tower: Whatever Tower jobs you have run are saved in Ansible Tower.

What needs improvement?

The area which I feel can be improved is the custom modules. For example, there are something like 106 official modules available in the Ansible library. A year ago, that number was somewhere around 58. While Ansible is improving day by day, this can be improved more. For instance, when you need to configure in the cloud, you need to write up a module for that.

For how long have I used the solution?

I have been using Ansible for approximately one and half years.

What do I think about the stability of the solution?

I believe no other tool can match the stability of Ansible. It is an agentless tool; it is SSH. Other comparable tools, like Puppet, Salt, and Chef, all require some kind of agent on the target node. Ansible only requires a Python dependency, which is very common in any operating system.

What do I think about the scalability of the solution?

It's very scalable. If there were a graph showing scalability, Ansible would be at the peak on that graph.

How are customer service and technical support?

I have not used Red Hat's technical support specifically for Ansible, but when learning Ansible I used their partner program and I felt it was the best.

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

When I started in automation, Ansible was the first tool I used.

How was the initial setup?

The initial setup of Ansible is very straightforward. There are no dependencies. You just run a simple, single line command and your Ansible is ready. It hardly takes two minutes.

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

If you only need to use Ansible, it's free for any end-user, but when you require Ansible Tower, you need to pay per Ansible Tower server.

Which other solutions did I evaluate?

Apart from the fact that Ansible is agentless and open source, it's the best because you only require an IP and the credentials of any target server, and half of your work is done.

What other advice do I have?

Ansible is an open-source tool, so it can be integrated with any of the cloud services, including AWS, Google Cloud Platform, Azure, very easily.

Based on my experience, I would suggest that anyone starting out with Ansible be familiar with SSH commands and Linux administration. That should be more than enough for Ansible beginners.

Which deployment model are you using for this solution?

Private Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
Faycal Noushi
CEO/Founder at Zen Networks
Real User
Top 5Leaderboard
Provides predictability to the network by knowing exactly what's being pushed after validating it in production

Pros and Cons

  • "Ansible provides great reliability when coupled with a versioning system (git). It helps providing predictability to the network by knowing exactly what's being pushed after validating it in production."
  • "Accessibility. Ansible uses a CLI by default. Those accustomed to it can find their way and adopt the YAML files easily over time. But, some users are more comfortable using UIs..."

What is our primary use case?

Server configuration management: This is Ansible's forte as it has multiple modules to interact with servers either to orchestrate or configure them. This can take multiple forms like pushing a script and executing it, sending commands to restart services...

Network configuration management: Ansible coupled with Jinja2 allows to push parametered configurations in a reliable way. Support for network gear isn't as common as server/development use cases. But, with some hacking, it can be managed

The tool can also be used for CI/CD software deployment, But, we didn't explore this topic with it that much, yet.

How has it helped my organization?

Ansible provides great reliability when coupled with a versioning system (git). It helps to provide predictability to the network by knowing exactly what's being pushed after validating it in production.

It is very hard to manage more than a hundred servers with redundant configurations manually. It is too prone to error and troubleshooting can easily become a nightmare. This is why it is very beneficial to use an automation platform like Ansible coupled with configuration management/versioning (Gtilab, Gogs) and some best practices around that.

What is most valuable?

  • Reliability & reproducibility: Being able to design playbooks that can be validated in the development environment, QA, then production is very valuable. This helps reducing configuration errors and provides faster deployments.
  • Extensibility, versatility. Using its wide range of modules, Ansible can be used with different OSes and systems. In fact, using Ansible modules, one can interface with network gear using NAPALM, for example, or push remotely scripts for local execution on automated platforms.
  • Facts gathering: Ansible is able to extract configuration items either to be used later for reporting or to be used as conditions for playbook actions
  • Agentless: Ansible does not require to install a local agent on automated devices. It goes through communication protocols like SSH, Telnet, SQL (multiple DBS).
  • Dry runs! Better safe than sorry!

What needs improvement?

  • Accessibility. Ansible uses a CLI by default. Those accustomed to it can find their way and adopt the YAML files easily over time. But, some users are more comfortable using UIs.
  • Ansible Tower's upstream project, Ansible AWX provides a web UI. But, it can be improved to make it more user-friendly.
  • Overall, the learning curve could benefit from an easy to use UI.
  • Network gear support is still not that great but evolving. We definitely would like to see a general direction towards those. Especially since there are so many vendors and managing them all from the same platform is a rare plus.
  • For Windows, support is getting better, too. 

For how long have I used the solution?

We've been using it for three years for various automation tasks from local user management (backup & monitoring) to orchestrated configuration updates

What do I think about the stability of the solution?

It has been very stable till know. As long as you test correctly your playbooks on dev/qa environments, you reduce the major source of concerns

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

We previously were using custom-made Python scripts for automation. It can weirdly scale well when multi-threading is leveraged correctly. But, it definitely cannot replace an extensible framework like Ansible. 

The community behind Ansible and its important number of modules make it a lot more relevant.

We were also using Puppet at some point. But, it's a bit different than Ansible, it was not a competing usage for

How was the initial setup?

The initial setup is quite easy. Creating your first playbook and inventory can be challenging if you're not used to the underlying technologies.

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

It's opensource so it's free. But, not free as in beer.

The most important cost here is the learning curve. Small targets like local user management (backup/monitoring) or monitoring configuration management (Syslog/SNMP) are some of the easiest and low-risk ones can learn from. The OPEX gain is high, though. So, the ROI is definitely there.

For the UI, you might want to pay for Ansible Tower. But, there's also the opensource upstream project, AWX.

Which other solutions did I evaluate?

Chef, Puppet, Saltstack. Ansible proved to have the most traction and its orchestration use-case was a bit different than the configuration management one.

Which deployment model are you using for this solution?

Hybrid Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Amazon Web Services (AWS)
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.