Red Hat Ansible Automation Platform Reviews

I use the solution for all kinds of automation, network automation, compliance security, software installation, and software configuration. I started using the solution as a configuration management tool, and now I also use it for automation. I also use Red Hat Ansible Automation Platform within the CMP platform Morpheus.

The most valuable features of the solution are its configuration management, drift management, workflow templates with the visual UI, and graphical workflow representation.

The solution should add a nice self-service portal.

The standard single-node installation is easy. When you have a protection grade installed, and the customer wants DR, it creates a problem. For example, if you have the database built in, but the customer wants to use RDS, you have to tweak it. Then, you have to use the governance policies and everything accompanying them. Some customization takes place, but overall, it's easy if vendors use a straightforward method.

I have been using Red Hat Ansible Automation Platform for many years.

Red Hat Ansible Automation Platform is a very stable solution. I rate Red Hat Ansible Automation Platform an eight out of ten for stability.

Around 10 users use the solution in our organization, a presales and sales company. Around 1,000 users used the solution in my previous organization.

I rate Red Hat Ansible Automation Platform a nine out of ten for scalability.

The solution's initial setup is not it's not hard. The steps to install the solution seem to be easy.

Users have to pay a per-node cost of around $ 100 per node. The solution's pricing depends upon the volume.

Users have to lay out how they want to build the solution. They should first build smaller job templates and then add them together to build workflow job templates.

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

We deploy the production environment using the provisioning for Terraform. We provision the cluster we need. If we need three or four nodes, like provisioning for hardware, OS provisioning, and bootstrap provisioning, we will use Terraform. After Terraform, we have to do any configuration changes. To install some packages, I do the cluster configuration changes and use Ansible with Terraform. I will integrate and deploy products based on the Ansible configuration files by writing playbooks.

There are many configuration management tools currently in the market. If there is a huge cluster, we use Chef. For minimum nodes, we use Ansible.

I'm using the latest version. It's version 2.13.4. The solution is deployed on AWS cloud.

I like the agentless feature. This means we don't install any agent in worker nodes.

The solution requires some Linux knowledge.

I have worked with Ansible for eight years.

The solution is stable.

Scalability is not a requirement for this solution because it's a configuration management tool.

We also use Chef.

Setup is straightforward. There's no complexity. We had to learn some Linux information before setup.

The length of deployment depends on the nodes. It will show if everything is deployed or not, any changes, and if there are any failed nodes.

Security patching is enough for maintenance.

I installed the basic version myself. We also have the enterprise version, which is open source.

I would rate this solution as 10 out of 10. 

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.

You can literally automate everything. Whatever you want to do if you did it with shell scripts, you can do it in Ansible. There is also the ability to use Tower AWX, which allows you to store your variables in a hierarchy. 

If you're familiar with the Puppet product from more than six years ago, it allowed you to do inheritance on variables. Ansible made sure that they had that in their product. It's also not agent-driven. Therefore, you don't have the added extra bloat to your deployments. Just run your command, then get the code. You can deploy using packages on Ansible or you could deploy binary files by copying over.

It allows people without a lot of knowledge or expertise in a CI/CD pipeline to deploy it other than knowing how to write code. It allows them to look at what someone else has done and easily read it, then copy and paste into their own if they're creating a new app. They can also utilize what is already there.

It is very extensible. There are many plugins and modules out there that everybody helps create to interact with different cloud providers as well. Roles that sum up all the playbooks that you might have. You might have a giant playbook which is doing a lot of things just for one app. However, there may be other people who have also tried to do the same thing. So, they create these roles, and you're able to automate easier without needing all those playbooks. You can have role declaration with a couple of Rs.

In Community, there's a lot of effort towards testing, standardizing, and testing for module development to role development, which is why Molecule is now becoming real. Same thing with Zuul, which we are starting to implement. Zulu tests out modules from third-party sources, like ourselves, and verifies that the modules work before they are committed to the code. Currently, Ansible can't do this with all the modules out there.

It is stable.

The only issues that I have ever had were with brand new modules, which weren't really ready yet, and they were marked as testing or development modules.

I have never had any scalability problems. I have deployed 2000 computers all at once in the past for a previous employer. 

I usually just use the community. If you hop on IRC Channel, the Ansible channel, there are tons of people who are helping each other out all the time and helping the community grow. 

There is a lot of documentation on their website as well, which is unlike most tools out there. It is very thorough and detailed. It has how-tos and examples. You can even deep dive into Jinja and its more advanced features to understand what you're doing.

You install Ansible and are done. Even YUM or DNF installs, they are pretty easy to install. All the core modules support Python 3, so if you're moving to Python 3, it works. Python 2.7 is pretty much standard.

I was a very big Bash script guy years ago on automating deployments. Then, I moved into Puppet. I did Puppet for a few years, and was very involved in the community there as well. After that, I moved over to SaltStack. The design of SaltStack was a bit complicated, as it felt very split brain. So, I did that for about six months, then I decided to look more at Ansible, which I dabbled with for about two years before I started using it. It was a little complicated to use as the action system was weird, but they have over come a lot of those issues. Now, the Ansible modules are simple and easy to use, so I moved to Ansible and haven't changed since then.

It simplifies everything. You can see what is happening actively on your screen. Now, with Tower and AWX, you are able to see the output afterwards. You can set up cron through the web interface and see what happens.

I am using Red Hat Ansible Automation Platform as a part of the scale-up of the nodes in OpenShift.

Mostly, we use the solution for upgrading-related stuff.

The most valuable feature is that Ansible is agentless.

For my day-to-day operations, the one module that I am using is very good, and it is giving the intended results. Ansible has a lot of modules to perform your day-to-day activities. I don't think there will be room for improvement based on the current instances or use cases.

The scalability of the solution has some shortcomings. Thus, the solution's scalability has some room for improvement.

Though not much, I have experience with Red Hat Ansible Automation Platform for two years. I am a customer of the solution.

Stability-wise, I rate the solution a ten out of ten.

Scalability-wise, I rate the solution a nine out of ten.

The initial setup for Ansible is very easy.

I'm not using the solution in this containerization. In the present environment, we are not using something like Red Hat Ansible Tower. We are using just an Ansible node which is something we use as a server for accessing all of our nodes and managing all of the nodes. Also, building an Ansible node as a bastion or jump host is a pretty easy task.

Actually, when you are building Ansible Tower, I think you need to go for the pricing. For other things, you don't need to do that, I guess. So it's a pretty good tool to automate your day-to-day or daily tasks or activities that can be done with Ansible. It has a lot of features, helping materials, and modules, which will be helpful in automating one's day-to-day jobs. It's pretty easy for us to upgrade and work with the nodes on Red Hat Ansible Automation Platform.

If you go with any other tools, like Chef or Puppet, they are very hard to configure. Red Hat Ansible Automation Platform is agentless and pretty straightforward. It will reduce a lot of our headaches in general.

I rate the overall solution a ten out of ten.

We use Ansible for infrastructure code. We also use CloudFormation. 

Ansible provides a central solution for automation for our customers.

We deploy this solution on AWS. We are a cloud company so that is why we don't have anything on-premises. We prefer a cloud approach, and we have almost everything in GCP or in AWS. The solution hasn't required us to change our existing infrastructure. We are using the server version 17. We use Ansible plus Ansible Tower, which is Ansible AWS.

The solution is user-friendly for our staff, although some activities are unique and are not being repeated several times, so we need to do those things manually.

We have around 25 people doing this same job. Before using this solution, we had more than 100 people for the same amount of work. This solution has definitely helped us to reduce and optimize our efforts.

One of the most valuable features is automation. We are doing automation infrastructure, which allows us to automate regular tasks. This solution provides us with a service catalog, like building new services and automating daily tasks.

The language is very intuitive. The solution is easy to learn. The solution enables us to deliver incrementally. We are able to expand this facility by implementing more templates and using them digitally.

We are an international company, so we use this solution with a collaborative approach internationally. 

The solution enables us to enforce the same security settings, so it's quite easy to maintain. There can be human mistakes, which can make security unreliable, so that is why we prefer this security policy.

We would like support for the post-integration of this product before cloud frameworks because right now their approach is to avoid using on-premises activities and move everything to the cloud. This is why we choose Ansible, but we would like Ansible to stay as close as possible to recent trends coming through AWS, for instance. We have a chance to automate those processes by using Ansible, so there is interoperability of those products.

I have been using this solution since 2015.

The solution is stable.

The solution has reduced the amount of downtime for users. It can automate some maintenance activities, which are out of operating time. If those activities can be automated, that can dramatically reduce downtime. If those activities can't be re-automated, then it's semi-automated, which would mean human effort plus automation together. In general, yes, we can automate maintenance or downtime activities, but that depends on the input for this. If there is some sort of disaster, then there would be a different approach.

Technical support is very good, especially from Red Hat.

We have used Red Hat Satellite and Red Hat CloudFormation.

CloudFormation is like a showcase of our service catalogs. We provide that to our customers. It's tightly integrated with Ansible and frameworks. The customer can choose from the service catalog, and if it's automated, the customer can see how much it was from a cost point of view. CloudFormation reduces work activities on the ground.

Initial setup was complex.

To deploy everything from the Red Hat portfolio took one week per customer.

Our strategy combines very closely with cloud, which is why our approach is complex. We are trying to persuade and migrate customers to the cloud, AWS, or GCP, and as an additional value, we can automate and more or less migrate it to an environment to bring new approaches and make this cloud solution beneficial to customers.

Yes. We saw ROI three or four years after implementing the solution.

You don't need to buy agents on servers or deploy expense management when using the solution, which affected our decision to go with it.

We also bought this solution because it was better than some competitors, like Puppet and Chef, and because of the automation.

It has helped our organization save time when it comes to service deployment, moves, and updates. We used to have 120 employees, and now we have just 25 for the same amount of activities.

I would give this solution 10 out of 10. 

The lesson I've learned is that automation is the way because without automation, it's quite impossible right now to maintain a very large environment, especially in public clouds like AWS or GCP.

We're quite unique because we use the public cloud environment together with one product.

Basically, Ansible is a configuration management tool. Mainly, I've been using Ansible for making changes and for deployments, such as of web servers. I also use it for servicing instances, mostly from AWS. I use AWS Cloud, and I configure the instances that I've launched.

Recently, I've also created an Ansible role. Basically, you can contribute to Red Hat in the form of an Ansible role. Everybody can share their code with just simple commands, such as Ansible Galaxy. With a few commands, we can share each other's infrastructure.

It helps us to create an environment. I'm a student. As students, when we get into newer technologies, we can't share our infrastructure with each other, and it gets difficult to explain to everybody. For example, I want to tell my friend to do certain things so that his infrastructure is similar to mine. In such a case, I'll just create a playbook from Ansible, and I'll just share it with him. He will just run that playbook, and we both will have the same infrastructure. 

It doesn't require us to change our existing infrastructure in any way. We just need Ansible software on the managed host. So, it just needs to have Ansible. The host with which we are going to connect should have the Python interpreter installed, and nothing else. 

It saves time when it comes to service deployment, moves, or updates. We have created playbooks, which are very easy to create. They are scripts in Python. A playbook also acts as a documentary for you. You can refer to a playbook any time, and it definitely saves a lot of time. It gives very good results in a long run. You just have to invest time in creating the first playbook. After that, you just use it. While creating a playbook, you can specify keywords by using Ansible variables. For example, to launch an instance in AWS Cloud, I need to specify a name to it. If I need to launch two to three instances at once, I will create a variable for it and pass it externally through the Ansible playbook. Next time, you can change the keyword and run the playbook.

Ansible is agentless. So, we don't need to set up any agent into the computer we are interacting with. The only prerequisite is that the host with which we are going to interact must have the Python interpreter installed on it. We can connect to a host and do our configuration by using Ansible. 

Its dynamic inventory capability is very useful. For example, we are provisioning instances in AWS, and I want a particular name tag. My name tag is my instance, and I've been running a lot of instances in AWS Cloud. If I want, I can filter and configure all instances running with a specific name. I can also dynamically fetch IPs. What happens in the AWS cloud is that if you shut your operating system down, and you do some reboot and stuff like that, then you'll lose the public IP. Being able to dynamically fetch IP is the main capability that I like in Ansible.

It is very easy to use. Anybody who has studied computer science or is from the mathematical field can easily use Ansible. You just have to know how to do a certain task. For example, if you want to make some changes to your firewall and maybe set up a web server, you don't have to know all the commands with respect to different operating systems such as Linux and Windows. You don't need to know commands, and you just need to have a basic idea about how you want to do it. It is very easy to use. You just have to know how to do it.

Ansible is great, but there are not many modules. You can do about 80% to 90% of things by using commands, but more modules should be added. We cannot do some of the things in Ansible. In Red Hat, we have the YUM package manager, and there are certain options that we can pass through YUM. To install the Docker Community Edition, I'll write the yum install docker-ce command, but because the Docker Community Edition is not compatible with RHEL 8, I will have to use the nobest option, such as yum install docker-ce --nobest. The nobest option installs the most stable version that can be installed on a particular system. In Ansible, the nobest option is not there. So, it needs some improvements in terms of options. There should be more options, keywords, and modules.

I've been using Ansible for about one and a half years.

It is quite stable. It has been good so far. I didn't find any bugs. 

We do our operating system-related configurations and router configurations by using Ansible. I am focusing on operating system-based configuration because I use it in the operating system, and it has been quite stable.

It is scalable. You just need to know the IP address of the new operating system with which you are going to interact. You just need to enter credentials into Ansible inventory. You have to make entries to this inventory, and you are good to go. You can use the same configuration that you have been using in your previous host.

I have not interacted with their technical support because I didn't come across any issues from Red Hat's side. It has been stable, and there was no need to contact them.

There is an open-source community of Red Hat and Ansible Galaxy where users contribute. I've contributed two to three times. 

I just started using Puppet and Chef. The main thing where Ansible stands out is that you don't need to make any changes to the upcoming hosts. With Puppet and Chef, you have to install an agent program that will act as a layer for interacting with the host. You need to install an agent in between, which takes time as well.

It is a very straightforward process. There is a package available on their site. After we download their software for the respective distro, we just write the installation command, and everything runs greatly. After installing the product, most people make use of Ansible roles. Ansible Galaxy is already filled with a lot of roles. A lot of developers have already contributed to a great setup with their proper codes. As a user, I have to just install a role or just download it from the site. It was not a lengthy or complex process. It was very easy.

For the initial setup, it takes about 10 to 15 minutes in going through sites and searching for a particular version. The installation will take about 5 minutes. After that, you have to configure Ansible properly, which might take a little bit of time, but it also depends on whether you know the IP address of the host. If you know the IP address and credentials, then you just have to enter it in the Ansible configuration file, and it is done. 

There is good integration between RHEL and Ansible. There are repositories configured for Ansible and you just enter the yum install ansible command, and it will do all the setup and it will also create a basic configuration file. The only remaining task would be to configure that inventory. You need to know the IP address of the host to which you are going to connect and the password. After you enter it into the inventory, it runs very quickly. There is no need to download it from any site. If you're using Ansible with Red Hat, then there is very little chance of any error while using Ansible.

Ansible's documentation is well-maintained and updated very frequently. You just need to go through the documentation. It is very easy to read. There is nothing much to worry about.

Ansible Tower has great integration capabilities with enterprises solutions such as OpenShift and many more. I've seen many people integrating OpenShift with Tower, but I have not done it.

Before going for automation, one must first know the manual approach to it. After you've applied a manual approach, you can easily understand what type of automation you can do for your environment and infrastructure and how to do the automation.

When it is utilized with RHEL, things are very easy to understand. If someone has knowledge of RHEL, then they also have knowledge of Ansible. There is no need to study more about this. While using Ubuntu or different distros, you have to know more about Ansible, your OS-based package managers, and your internal configuration.

I'm currently preparing for the Ansible examination. I connect with their products remotely. They have configured every repository that one needs in their licensed products. Subscription will definitely be needed if you want to use it in the industry. If you just want to know about it, a subscription is not required.

I would rate Ansible an eight out of 10.

Our company uses the solution for automations, patching, scheduling, and installations. 

We have 500 users throughout the company and two or three people per team who handle ongoing maintenance. 

The solution has improved our productivity and functionality. The automations we have done for patching save a lot of time and effort for many users. 

We always have plans to increase usage because we have automations in the pipeline for installations and patching. 

The solution is very simple to use and we chose it for the simplicity. 

Being an Agent Plus makes our lives easier. 

There is always room for improvement in features or customer support. 

I have been using the solution for three years. 

The solution is stable with no issues. 

I am a user so am not familiar with scalability. Another team handles the platform and its scalability. 

Technical support is good and very helpful. 

I rate support an eight out of ten. 

Positive

We previously used Puppet. 

The setup is pretty straightforward. The government on our side makes things a bit tough but that has nothing to do with the solution. 

We implement the solution in-house. 

We also considered UDeploy but did not get to the point of comparing it to the solution.

The solution is a wonderful tool and is simple to learn and use. There is much flexibility in the open-source environment when using the solution. 

I rate the solution an eight out of ten.