Red Hat Ansible Automation Platform Reviews

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.

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.

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.

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.

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. 

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.

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.

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.

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.

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.

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.

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. 

Scalability should meet our needs going forward.

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.

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.

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.

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.

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.

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. 

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.

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.

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

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.

It scales well because of the clustering.

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

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

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.