Red Hat Ansible Automation Platform Reviews

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.

The primary use case is mostly automation. In technical terms, the solution uses a playbook. The playbooks contain code. If you have written all the code in the playbook, you just execute that code. You can automate depending on the environment.

The playbooks and the code the solution uses are quite useful.

It would be good to make the solution more user-friendly for customers who aren't skilled in coding and don't know how to use the playbook's code. If we have many customers and the modules already exist, the user can just plug and play.

I have been using the solution for one year.

We don't have many issues with stability, so I rate the solution's stability a nine out of ten.

I rate the solution's scalability a nine out of ten. We have two customers using the solution.

The technical support is good.

The initial setup is complex, and OpenShift would be much easier. It took a week to deploy the solution. When deploying the solution, you must download the installer and install the solution on the server.

It requires two engineers for maintenance and deployment.

Customers need to pay yearly for the license. The pricing is acceptable. It is not expensive.

If you know the basics of coding for you to write the playbook's code, and if you have a midrange environment with up to 1,000 servers, Red Hat Ansible Automation Platform is a good option to automate daily tasks.

I rate the solution a seven out of ten.

We use the solution for provisioning on different providers like VMware, and OpenStack because it was so easy to implement. This product is also helpful to create a job workflow including the approval steps.

It also includes DevOps tools for making an easy automation process. 

It brings a lot of time-saving.

The API for exposing all our infrastructure services is the most valuable feature.

I have been using Red Hat Ansible Automation Platform for three months.

It is a stable solution.

It is a scalable solution.

The technical support is very good. We asked the support team about applications, and they answered us. I rate the technical support a nine out of ten.

Positive

We used multiple tools in the past three years, but we did not use any other similar product to Red Hat Ansible Automation Platform.

The initial setup was easy. I was not a part of the deployment process, but my team members told me about the deployment process.

The in-house team asked the support team questions.

It is an open source product but needs a license subscription to use it. The price depends on the number of nodes supported by the platform (the nodes correspond to a host which can be for example a VM or a data center).

The price is really different depending on the customer's needs.

We have evaluated other solutions but this is the one that best meets our need for provisioning automation and addresses the different infrastructure and cloud providers we use

The product can be very easy to use, provided what you are using in it. I did not use the product myself, but it was really impressive when they showed the POC process. I rate it eight out of ten.

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

I use the product mostly to configure virtual machines.

The solution helps us to have a standard configuration for all the virtual machines. It helps our virtual machines have the same configuration every time they restart. It also helps with automation.

The most valuable feature of the solution is that we don’t need an agent for it to work.

The product could do a better job at building infrastructure. 

The product should add a feature that alerts us if someone changes the configuration.

I have been using the solution for two years.

The product has high stability.

The solution has high scalability. It can be deployed on thousands of machines. Seven people in our organization use the solution.

The initial setup was straightforward.

We use the open-source version of the solution. The product can be used for free.

The tool should be used for server configuration but not for creating resources on the cloud. Overall, I rate the solution a seven out of ten.

We use Red Hat Ansible Automation Platform in our company to implement a software-defined infrastructure, which involves defining the desired configuration of machines in terms of their components, setup, security, user roles, software deployment, and certificate deployment. With this platform, we are able to set up new environments and manage the lifecycle of instances across various stages, such as development, production, and pre-production. We also use it for routing up and back of new software.

Feature-wise, the solution is a good open-source software offering broad support. Also, it's reliable.

I think some community projects support Ansible Playbooks, but they often break with version updates. It's a difficult problem to solve. DevOps should have a library with common components to make Ansible more productive when there are updates to Ansible and the operating system. What we need is model-driven, declarative software infrastructure management. However, things tend to break with new versions, requiring a lot of work to fix. It becomes a cost-benefit analysis of reusing old Ansible scripts versus rewriting them from scratch after updates. The problem is that it becomes quite fragile over time, and this fragility is a problem.

If the IDE and auto-completion of the solution are based on Checkpt, it is important to ensure that the AI coding tools support writing in a more declarative way. While I have not yet tried coding with this assistance, Microsoft and Keylabs both offer AI coding assistants. The focus should be on improving the support for Ansible in the area of AI coding. It is crucial to see how well they work with the new versions of Ansible.

I have been using Red Hat Ansible Automation Platform for almost five years. My company is an end-user of the solution.

The product's stability is very good. I rate it an eight out of ten.

Ansible is a configuration tool that doesn't have to scale like other tools. So scalability does not apply to the solution. Also, it's not a tool used by thousands of users. I am unsure if it can be used to manage thousands of servers. Small teams, like the DevOps team, use the solution. We service large groups of servers with it using a very small team of about two or three and a maximum of four people.

I have never contacted technical support. We use open-source support.

The solution's initial setup process was simple. The solution gets used in various ways, and it's essentially a configuration tool you run from any node with access to other nodes. It has got server versions as well. So, you can use it either way.

We compared it to other configuration management tools before choosing Red Hat Ansible Automation Platform. We did not choose others since they were not as centralized. It doesn't need a server since you can run it from your clients, and it doesn't need a central deployment service or server.

Red Hat Ansible Automation Platform is a declarative infrastructure management system that works fine if supported by the environments you use to set up. I rate the overall product an eight or nine out of ten.

I'm a software architect at a DevOps platform called Jihu. We use Ansible to provision Kubernetes clusters. For example, if the cluster has dependencies, we provision for the specific package manager version and dependencies, so they can scale for the CI/CD line. Ansible helps us provision the Kubernetes cluster for single-cloud or hybrid-cloud scenarios.

I like Ansible's ease of use. If you have Linux skills, you can create a reusable template for the dependencies and other configurations. I can store the templates in a repository and share them with my customers or other developers. It's a popular solution, so there is a large user base that can share templates. 

It could be easier to integrate Ansible with other solutions. No single tool can do everything. For example, we use Terraform for infrastructure and other solutions for configuration management and VMs. 

I have used Ansible for around four years. 

Ansible is stable as long as you have the connections between the machine and the server you use for all of this. 

Ansible has some built-in mechanisms to help you scale. There are different playbooks or steps. I have various multi-project partners that handle these kind of jobs, so I can do the provisioning simultaneously. Of course, we still need to do some prerequisites and there are dependencies between various jobs. 

I don't typically raise support tickets, but I frequently work with the Red Hat presales staff because we sell their solutions.

Setting up Ansible is straightforward because we use the Docker image. There may be some challenges if you have large-scale VMs. It's typically fine if we use configuration management for the credentials and SSH. If you want to use Ansible to provision VMs like TerraForm, then we need to clearly understand the mechanism. The time needed to deploy Ansible depends on the type of applications and infrastructure you're dealing with. It isn't only about the specs of the VM. The network speed and complexity also factor into it.

I rate Red Hat Ansible Automation Platform seven out of 10.  I give it a seven in the Hong Kong context. It's about the culture, not the technology. Most of the infrastructure and network people in Hong Kong find it hard to accept a new solution, and it isn't easy to transform this kind of culture. They have one or two OEMs running on some simple web servers. Their teams are not familiar with the infrastructure cost calculators and configuration management stuff. 

We don't push them to use anything like this, but if they have lots of things they need to manage, then it's an opportunity for us to sell them solutions. We ask them questions. How many standard operations are you using? What is the approval flow? How long would take if you want to release or deploy applications? We make the case that they could shorten the time spent on SOP by eliminating manual work in the approval flow.