Red Hat Ansible Automation Platform Reviews

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.

1600 host environment, which is mainly used for software updates. As a production environment, it is used for security compliance.

We are still implementing it. I have used it in a very small environment (10 hosts), and it performed well.

Role-based access control and agentless architecture are the main features which may attract users. It is also easy to learn. 

Ansible Tower provides a GUI, which is an enhancement, and a well-liked feature by operation teams.

The cost is high but it sill works well.

The beauty of Ansible is the easy ramp-up to get started.  You really only need Python and SSH access. Configuration is generally done in YAML, which is easy to understand, and there is a progression from ad hoc tasks, to playbooks, then to roles, which means you can start with one server and continue building up to datacenters worth of servers with the same methodology. Also, shared by most configuration management tools, the idea of creating a desired state scales better than trying to specify procedural steps to set up new hosts. There are no agents by default, so adding a new server is a matter of a couple lines of configuration (on a new server and the configuration master).

There is some overhead in setting up the initial playbooks, but it now takes less time to set up 10 servers than it did to configure one in the past. Also, the setup is consistent because there is not the concern that someone forgot to copy/paste a config line or run another command. Whatever is in the playbook gets done.

Because Ansible is establishing SSH sessions to perform tasks, there is a limit on scalability. Speed and the sheer number of open connections start to become issues past a couple hundred servers. There are some workarounds, but that is a key area for improvement. Ansible could also improve support for private package repos, to ensure that new batches of servers are getting the same package versions as earlier batches.

I have been using Ansible for about two years.

SSH is pretty good, but it was not designed for the access pattern of hundreds of connections out of configuration targets. Other tools solve this with a listening agent process, so the initial connection to configure is much faster.

I have not used customer service. Ansible is well established, so there is plenty of documentation, examples, and third-party resources.

Manual configuration and "Golden" templates for virtual machines were used.  The former is tricky to maintain consistency with. The latter seemed to require constant updating and it did not help maintain the configuration of already installed servers.

Initial setup boils down to installing Ansible and ensuring you have SSH access to a target that is running Python. Standard packaging is available on major Linux distros to install some level of Ansible. I recommend following instructions on Ansible's site to get the latest stable release as they have been improving rapidly.

Not applicable.

Although Red Hat has an enterprise add-on to manage Ansible through a web application and offers commercial support, I have not used it. Like many Red Hat products, they have a no-cost version of the web application (AWX, formerly Ansible Tower), but you are on your own to install and it is a little more complicated than just installing Ansible. AWX will probably be required in most shops for the RBAC functionality. With AWX, non-admins can be limited to perform some tasks, but not be allowed free reign with Ansible.

Salt (or SaltStack) is a similar tool, but does have an agent. There are other tools like Chef or Puppet that use languages other than Python. Ansible was chosen based on these characteristics and the others were not evaluated after this initial choice.