Red Hat Ansible Automation Platform Reviews

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.

We use Red Hat Ansible Automation Platform for the automation of our servers and applications. We also use both Terraform and Ansible to automate our infrastructure.

Red Hat Ansible Automation Platform has saved our time and reduced errors in our processes. It used to take us two months to provide a server in our organization, and now it only takes a few minutes to have the same server. Automation has ensured that tasks are done in the same way every time, reducing the likelihood of errors.

The capacity to install products on the operating system is very valuable. Ansible is better at handling the final configuration of servers. We prefer Terraform for creating multiple resources in a project, but Ansible is better for final configurations.

Ansible's centric idea of servers needs to be changed. In modern infrastructure, there are more than just servers. The initial server-centric approach in Ansible is a bit strange. It should improve its functionality with cloud resources like Azure, AWS, or Google Cloud. 

Ansible could also improve its capabilities in managing several resources at the same time, similar to Terraform. Moreover, more integration with other tools would be beneficial.

I have been using Red Hat Ansible Automation Platform for about three to four years.

The stability of Ansible is rated high, around eight to nine on a scale of ten.

We haven't experienced any problems with Ansible's scalability. We use it at the project level and create around ten to 20 resources. We haven't tested it with thousands of servers, so it's difficult to say how it would perform in such scenarios.

We are using the free version of Ansible, and so far, the support has been very high, considering that it is a free version. We are in discussions with Red Hat and IBM about possibly purchasing the commercial version when we start using Ansible for patching servers.

Positive

Before Ansible, we used BladeLogic from BMC. We switched to Ansible as it was easier to use, had more functionality, and there were more people in the market who knew Ansible compared to BladeLogic. Overall, Ansible is a much better product.

The setup of Ansible is easy. It's faster to start working with Terraform. However. Ansible's setup is also straightforward. The basic installation process is quick and effortless.

I recommend using both Ansible and Terraform for automation, especially now that both are under IBM.

I'd rate the solution eight out of ten.

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.

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. 

We primarily use this solution for network configuration pushes. We use scripts from Ansible to push configurations to specific devices such as routers.

The best features are the orchestration and flexibility of the solution.

It would be helpful to have templates for common configurations. It would make it much easier and faster rather than creating a whole script. The templates would decrease the learning curve as well.

I've been working with Red Hat Ansible Automation Platform for a year.

Red Hat Ansible Automation Platform is quite stable. If you set it up correctly with the right configurations and there are no hiccups during installation and deployment, it will be stable.

I'd give stability a rating of eight out of ten.

It's a scalable solution. The capacity of the single instance is quite enough to hold up an enterprise. From a resilience perspective, you have to have a cluster that actually holds the whole thing.

On a scale from one to ten, I'd rate scalability at seven.

I would rate technical support at nine out of ten.

Positive

Once all of the components are in place, there are no issues with the initial setup. I would rate the initial deployment process at seven out of ten.

The deployment can take two days to a week depending on the requirements and resources available.

Red Hat Ansible Automation Platform is an expensive solution. There may be additional fees to use advanced features.

I would highly recommend Red Hat Ansible Automation Platform, especially to organizations that are moving toward a cloud or hybrid cloud infrastructure.

Overall, I would rate this solution at seven on a scale from one to ten.