Red Hat Ansible Automation Platform Reviews

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.

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.

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.

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.

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.

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

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

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.

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

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.

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.

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.

Ansible could use more public relations and marketing.

It is stable.

It is scalable.

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.

The setup is simple and easy.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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

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

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

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

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.

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.

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.

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.

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.

It is a reliable, stable product.

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.

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

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.

We just started using Community with Ansible. We are trying to install agents to either a cloud or a local virtual machine. We are still in the starting phase as it has only been implemented for two months.

My team thinks it is easy to work with, especially when working with the nodes. When the nodes increase, from say five to 15, I don't have to do anything extra.

1. There are so many models that I don't have to create one. I don't have to worry about anything. In these two months, everything was easily available.
2. Since it is in YAML, if I have to explain it to somebody else, they can easily understand it. 

One problem that I'm facing right now is the mismatch between the new version of Python and Ansible. Sometimes it's Python 2, and sometimes it's Python 3. When things get a bit dicey, I wish that Ansible would solve this issue by itself. I don't want to have to specify if it is Python 3 or version 2.

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

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

The community is enough for me.

The initial setup is pretty straightforward.

I researched with other tools, but I still chose Ansible. One reason, it was agentless. With other tools, I had to install agents. Ansible has a big plus factor being agentless.

The primary use case is network automation. I have been trying to use it to roll out new offices and update things, like NTP server changes. I would like to roll NTP server changes out with a couple of clicks instead of having to go and manage several hundred devices.

I have been using the product since 2016.

It's helped in my department, or at least in my role, because I use it a lot. NTP is a big one. We just rolled out GPS-based NTP. Instead of spending several days going to each device and ripping out config and putting new config in, I just batched our branches, batched our data center, ran three jobs, and called it a day.

The network modules.

There has been put a heavy focus on the network, so it is getting better. Some of the Cisco modules could be expanded, which would be great, along with not having to do so much coding in the background to make it work.

It has become a more stable product over the past two years. Ansible has put a focus on network, so a lot of things have changed rapidly. I have been trying to stay on a release for awhile until I can figure out how the new stuff works. For example, they just changed the connection type to network CLI from local.

It hasn't been always stable, but when it has been unstable, it was for a good reason: To get to a better place. The stability is getting there, if it is not already there.

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

Since I use Community, it's all community-based. Most of my questions go to Network to Code, which has a Slack channel, and the Red Hat Ansible team is on it along with a lot of industry people. If you ask a question, it's pretty likely that you are going to get a response.

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

I have looked at Puppet because they are now trying to get into the network space, but it is not that easy. The feeling of the product is not as good.