Red Hat Ansible Automation Platform Reviews

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.

We use it to manage all configurations and deployments.

We were growing at the time. I was able to take the old build manifest and automate everything. So when it came time to spin everything up, it was quick and simple. I could spin it up and test it. When it came time to roll production, it was a done deal. When we expanded to multiple data centers, it was the same thing: Change a few IP addresses, change some names, and off we went.

It helps me do a lot more. Where previously we had a couple of guys doing what I do, now it's just me.

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

In my opinion, one thing that needs improvement is mass updates: How I can parallelize that process a little bit better? It seems right now that I run through one set of servers, and then another set of servers, and then another set of servers but I'm not sure all those checks are needed. If I could parallelize different types of servers, like web servers and DB servers, that would make everything run a little bit more efficiently.

It's reliable.

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

I had briefly toyed around with Chef and Puppet, but I didn't get anywhere with them. Then I found Ansible. It was at a previous job where I picked up on Ansible. At that job, they were against putting an agent on anything. So Ansible was it. That was the easy sell. Then I figured it out and rolled with it.

The setup of Ansible is straightforward. You just download it and get started.

In terms of the documentation, I'm used to it, so it works fine for me now. At first, it took me a minute to find out exactly how to quickly find my way around the documentation, but now I'm comfortable in it and I'm happy with it.

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

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 use it for any sort of automation. We started using Ansible about 18 months back. But then we realized, as we expanded Ansible, that we needed controls around it. We didn't want people just running around crazily running Playbooks. And that's where Tower came in. We bought licenses and it's kind of worked out, though we expect a lot more. I did have a meeting yesterday with the Product Manager for Tower. I did give some suggestions. It's worked out but we've got more expectations, and I hope they work out as well.

Some examples of the tasks we've automated include OS patching to begin with - everyone does that. We have been using Ansible and Tower for a lot of data collection, for auditing, collecting data from across different servers: network, OS, Windows, Linux, etc. That's one of our major automations. In addition, AWS and various clouds, if we have to spin something up.

We're not using it for compliance yet. I saw a demo about that yesterday and we'll probably explore that.

In terms of staff or the amount of effort involved, Ansible is great. That Tower uses Ansible is amazing. Creating Playbooks takes less time. Tower has its own features. If there were more that would be great. But because Tower uses Ansible, it's not a lot of effort and we can get things done quickly.

• The Organizations feature, where I can give clear silos and hand them over to different teams, that's amazing; everybody says that it's their own Tower. It's like they have their own Tower out there.
• RBAC is great around Organizations and I can use that backend as our lab.
• Ingesting stuff into the JSON logs, into any sort of logging collector; it works with Splunk and there are other collectors as well. It supports Sumo and that helps. I can go create reports in Sumo Logic.
• Workflows are an interesting feature. I can collect a lot of templates and create a workflow out of them. 
  
• Also, the fact that Tower exposes APIs so other Playbooks can consume the APIs, it does complement other programs we use internally.

We are not using the Dashboard a lot because we have higher expectations from it. The default Dashboard from Tower doesn't give that much information. We really want to get down into more than if the job succeeded or what was the percentage of success. We want to get down to task-level success. If, in a job, there are ten tasks, we want to see this task was a success, and this one was not, and how many were not. That's the kind of granularity we are looking for, that Tower does not give right now.

There could be more stuff in the workflows. I hope that if I have ten templates with different services on it, workflow could auto-populate all the template-based services.

It's definitely stable and reliable.

Regarding scalability, we had issues initially. The biggest issue we ran into is, while yes, the documentation says if you want to run on 100 machines you need to have this many CPUs and this much memory - and we started following that - if my job template has 50 tasks in it and I enable verbosity and I run it on 1,000 servers, I am out of memory right away. The moment I have to expand to 1,000 or 2,000 or 3,000 servers, I cannot run verbosity. That has been one of the major problems that we have faced.

Scalability-wise, if I'm not enabling the debug log, it's good. Normally I do that. I have to cut down the list, shorten the number of target hosts, and then I can enable debug. That's been a problem.

Technical support has been good with the limited number of things that are supported in Tower. The Tower modules are not supported by Red Hat, which was disappointing. If I have to do updates to Ansible Tower, not somewhere else, I have to call the API, look at the right JSON, and post the JSON. If I had the module, and I had the feature of the module, I could use it. Right now the modules available on community don't have all the features. If Red Hat was supporting it they would have added those features. So there are things that are still missing.

The initial setup was pretty straightforward.

In addition to the developers who use it most, we hand over job access to different teams. Security needs some data, we clear jobs for them, we hand it over to them. But most of it is with Operations and the Development team.

I rate it a seven out of ten because there are a couple of things which I expect from Tower which are not there yet. As I mentioned already, things like services being populated from templates, job tags are not there on workflows right now, I have to go to another tool like Splunk or Sumo or some other logging tool to look at graphs. If those were possible in Tower it would be amazing. Anybody could run a job and go and look at a graph and see what happened, instead of having to log into another tool. There are things which I think can be added to Tower, but it's a good tool.

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

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

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

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

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

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

Ansible could probably help here with better documentation.

It is stable.

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

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

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

It's an effective solution for the problem space.

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

We are still implementing it.

Ansible automation has benefited our organization.

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

There needs to be improvement in the orchestration.

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.