Red Hat Ansible Automation Platform Reviews

We use Ansible for automation. It is integrated with Datavations. When we start Datavations, it calls the Ansible tower, which executes tasks like automated checks between the servers. We also use Ansible when we need to patch or upgrade our software.

Ansible has saved us lots of time. Previously, it took us much longer to deploy or make changes across systems. 

I like the fact that Ansible is agentless.

The support could be better. 

We have used Ansible for three or four years.

Ansible seems steady. It's stable all the time.

I rate Ansible eight out of 10 for scalability. 

I rate Ansible support eight out of 10. I rarely use them. It isn't the worst, but the response time could be better. 

I rate Ansible 10 out of 10 for ease of deployment. Deploying Ansible was straightforward and only takes about a minute. It starts with the CI/CD process, and it's automated so that when there is a change to the code, the changes are applied across servers or applications.

I rate Red Hat Ansible 10 out of 10. I recommend Ansible. It's easy to use. 

We use the solution for Linux patching automation. Currently, we are using the solution for patching normal configuration-related work. However, we also plan to use it for the provisioning of the servers.

The most valuable features of the solution are automation and patching.

The solution is slightly expensive, and its pricing could be improved.

I rate the solution ten out of ten for stability.

Red Hat Ansible Automation Platform is a scalable solution. Around 300 to 400 users are using the solution in our organization.

The solution’s technical support is very good.

The solution’s initial setup is very easy.

The solution can be deployed within a day if you have all the resources. To deploy the solution, you need to check if you have a proper infrastructure and everything in place.

Users with the right environment, like Linux, should go for Red Hat Ansible Automation Platform. With the Red Hat Ansible Automation Platform, we don't have to do manual things, increasing our efficiency. The solution helps us complete our complex work very easily, increasing efficiency.

Overall, I rate Red Hat Ansible Automation Platform ten out of ten.

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. 

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.

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.

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.

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

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.

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.

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.

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.

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.

It is stable.

It is easy.

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

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

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.

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.

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

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

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

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

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

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

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.

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

We use it mostly for remote execution.

The most valuable feature of Ansible is repeatability because when you're working at the DoD, you want things to be cookie-cutter and replicable.

Red Hat Ansible Automation Platform helps us achieve our mission because it's easy to write.

The Red Hat solutions fit together pretty well and work in conjunction with one another.

Networking needs to be improved.

I've been using Ansible for at least a year.

As long as it can communicate with the target, there's usually no problem with the stability.

We used Puppet and switched to Ansible because it's an agentless solution.

On a scale from one to ten, I would rate this solution at nine.