Red Hat Ansible Automation Platform Reviews

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.

We use it for patching and configuration management.

We are a healthcare institution. We have less than 500 hosts. Ansible is used between the infrastructure and applications, and primarily has Red Hat as the OS.

It has improved our organization through provisioning and security hardening. When we do get a new VM, we have been able to bring on a provisioned machine in less than a day. This morning alone, I provisioned two machines within an hour. I am talking about hardening, installing antivirus software on it, and creating user accounts because the Playbooks were predesigned. From the time we got the servers to the actual hand-off, it takes less than an hour. We are talking about having the servers actually authenticate Red Hat Satellites and run the yum updates. All of that can be done within an hour.

• Ad-hoc commands
• Playbooks
• Setting up and deleting users
• Patching
• Using it for quick and dirty deployment of scripts.
  

The YAML syntax is easy to use, but it takes some getting used to. I feel like Microsoft Visual Studio helps with the YAML syntax, lining it up correctly. However, if you're doing it from the command line without actual spacing, that could be a little problematic. The new version of Visual Studio is quite helpful because Git is integrated with it. The YAML markdowns are also in place. My staff doesn't need special coding skills to use it.

We have multiple Playbooks to configure a server. We can break it up or make one main YAML script to push out all the individual dependencies.

When you set up Playbooks, I may have one version of the Playbook, but another member of the team may have a different vision, and we will not know which version is correct. We want to have one central repository for managing the different versions of Playbooks, so we can have better collaboration among team members. This is our use case for using Git version control.

Collaboration across teams is a great goal to accomplish, but that would necessitate more visibility to other teams of what Ansible is capable of with the database teams and other individual applications. Because we have so many applications, I don't know if they are aware of how Ansible could be beneficial to them. That would necessitate a broader conversation within the IT infrastructure application teams.

While it saves time with fewer moves, there could be still room for improvement because we do not actually manage the VMs. Instead, this is managed by the Windows team, who spins up the VM. Then, once the VM is handed off, we do the security hardening. If we received the request from the application owner to spin up the VM to hand it off, then we could take that entire process and get it streamlined. Whereas, it is handled by a different team right now.

It would be great if we could leverage Ansible Tower and Red Hat Satellites more. 

API integration would help because right now our security team uses Splunk, and they are independent of my team, which is the Unix team. Therefore, if we could tie in Splunk with products, like Ansible, Cylance, and Rubrik for backup, then we could get all that information in a central console. We have not previously raised this suggestion because our Ansible Engine needs to be upgraded so we can get support for the Ansible product.

We have been using Ansible for at least four years.

We have not had any issues with Ansible. One of the projects that we have allocated for this year is to migrate our control station from RHEL 6 to RHEL 7.

We really don't have anyone maintaining it. It was a plug and play solution. We downloaded Ansible and ran it, because everyone knows how to use Ansible on the team at this point. Right now, I am trying to get to the next phase of using Git to set up more version control.

The scalability is excellent.

Four guys use it on the Unix team.

We were previously using Bash scripting. 

We did try BigFix for two years. However, because of costs, Ansible proved to be better cost-wise. The licensing fee was a big issue with using BigFix. Control from the BigFix perspective was a concern, because you were locked into the GUI. With Ansible, we were able to do everything from the command line and touch the entire environment from the command line. Once you use BigFix and an issue, you then have to log out or go into the box from one of the servers, but you were locked into the GUI in BigFix.

It is agentless. All we had to do is set up the control station, then Python was installed on all our Linux hosts. So, it was easy. The deployment took less than an hour.

The SSH keys were already in place. We already had the account, where we tested it out beforehand. Therefore, we knew exactly what we needed to do to deploy it. The keys were the hardest thing to set up and that was already in place (prior to Ansible).

The entire Linux group of four guys was involved in the deployment. We never had to use Red Hat resources to set up Ansible.

Ansible is primarily used for provisioning or hardening our servers. The realization of getting a server from testing to actual production is very short in our environment because the processes have been streamlined. Before Ansible, the processes were a lot more unwieldy. We went from a week to less than a day where you can get your server hardened, provisioned, and handed off to the application owner.

Costs are negligible when using Ansible. The costs are just learning to use the solution's various options. We save time and efficiency versus other solutions.

We have tested out Ansible Tower, but there is a budget issue, so that is in our next phase.

Red Hat's open source approach was a factor when choosing Ansible, since the solution is free as of right now.

We have Red Hat Satellites and looked into Red Hat Insights, which we are still not fully deployed on yet. The integration between Red Hat solutions is seamless.

We looked into BigFix. I also looked at SaltStack and Puppet, but didn't get anywhere with that. I wanted something that had ease from a management perspective. Other solutions besides Ansible needed us to use agents, and I felt that would cause too many problems. Management didn't want a disruption of servers or downtime. I couldn't give them the assurance that installing something with an agent would not cause issues. So, this affected our decision to go with Ansible.

I don't think any product that we looked into could compare to Ansible.

Test the environment because it is easy to use. Once you are proficient with Unix and Linux, it is extremely easy to use it: Setting up the inventory system, YAML files, and SSH keys.

I have no complaints about Ansible. I just wish I had more time to really delve into it.

I think we not using Ansible to its fullest potential, because of:

1. Training.
2. Time.
3. Not knowing all the options available.

I haven't been exposed to Ansible Tower much. I have only tested it out three times. Right now, I am a little rusty on it, so it will take some getting used to again. It is more GUI-based, so it is pretty user-friendly.

The biggest lesson learnt: There are multiple ways of doing the same thing.

I would rate this solution as a nine (out of 10) because of the configuration management for all our servers in the environment. It can be used within the networking field for all devices, such as Cisco switches. The solution speaks to Windows hosts as well. It just takes time to use all the functionality and get it visible across the organization.

We use it for the bot. It helps to keep tracking all the automation processes that are ongoing in your ecosystem

It helps with patching and keeping everything compliant.

Automation tracking is the most valuable feature. 

The SSM connection access needs improvement because right now, they do everything through SSH.

I have been Red Hat Ansible Automation Platform for a few years. 

The solution is very stable. 

If there's some cloud add ons, we would increase the usage. Only admins use the solution. 

We just create a server, and then we use that server to on-premesis.

Ansible has good performance. Overall, I rate the solution an eight out of ten. 

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 it mostly for remote execution.

The most valuable feature of Ansible is repeatability because when you're working at the DoD, you want things to be cookie-cutter and replicable.

Red Hat Ansible Automation Platform helps us achieve our mission because it's easy to write.

The Red Hat solutions fit together pretty well and work in conjunction with one another.

Networking needs to be improved.

I've been using Ansible for at least a year.

As long as it can communicate with the target, there's usually no problem with the stability.

We used Puppet and switched to Ansible because it's an agentless solution.

On a scale from one to ten, I would rate this solution at nine.

We primarily use the solution for automation purposes. We also use it for CI/CD plus DevOps. So these are the three main uses. We can use it for operational automation plus DevOps. We handle applications, pipelines, deployments, et cetera.

With this solution, we're able to cover our client's needs. 

The automation is very good. The operational automation and DevOps are the most valuable features for us. 

It's easy to set up.

The solution can scale.

It's very stable. 

Now, there is a GitHub solution that came on the market. GitHub's integration with Ansible is adding value for the customer as GitHub has the capability to push/pull architecture plus it can bring in collaboration and versioning. As long as they continue to develop this integration, it will continue to be useful. What is next is to look into the infrastructure.

The improvement is already there in GitHub's capability. GitHub is already there, however, they can bring something like that into the solution as well too. They can bring AOPs capability. They should think of this product as an end-to-end solution and begin to develop it that way. 

The solution costs a lot. It's not cheap.

I've been using the solution for the last four years. 

The solution is extremely stable. that's why so many organizations end up using it. There are no bugs or glitches. It doesn't crash or freeze. It's reliable. 

The solution can scale well. It works for small or large enterprises. There is no limitation. 

Technical support has been good. We are very satisfied with the level of service we get. They are continuously improving their services as well. As long as they continue to improve we will remain happy.

Positive

The solution is very straightforward. It's easy to set up. It's not difficult at all. 

How many engineers you need to handle the implementation depends on the project and use case. It depends, for example, on how many automations will be created, et cetera. The time it takes to deploy also varies. Different use cases have different deployment times. 

Our company provides the implementation for our clients. We are able to handle the setup ourselves. 

We've seen an ROI. It is reducing the resources needed by the customers.

It's an expensive product. It's costly. 

We're charged between $8 to $13 a month per license. There are some limitations as well, however, specifically in AOPs.

We're partners. 

Which version we use depends on the customer If they have a license the latest is fine. We can also work with an older version. Whatever's possible we can do. We have the list of the scripts available, which can help us do the automation for the customer.

It's on the cloud we utilize Azure and AWS. It can also be used on-premises.

It's an effective tool. We weren't sure about it at first, however, it helps reduce resources and has been helpful to customers. 

I'd rate it an eight out of ten. 

We use the solution for Linux patching automation. Currently, we are using the solution for patching normal configuration-related work. However, we also plan to use it for the provisioning of the servers.

The most valuable features of the solution are automation and patching.

The solution is slightly expensive, and its pricing could be improved.

I rate the solution ten out of ten for stability.

Red Hat Ansible Automation Platform is a scalable solution. Around 300 to 400 users are using the solution in our organization.

The solution’s technical support is very good.

The solution’s initial setup is very easy.

The solution can be deployed within a day if you have all the resources. To deploy the solution, you need to check if you have a proper infrastructure and everything in place.

Users with the right environment, like Linux, should go for Red Hat Ansible Automation Platform. With the Red Hat Ansible Automation Platform, we don't have to do manual things, increasing our efficiency. The solution helps us complete our complex work very easily, increasing efficiency.

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

We use the Red Hat Ansible Automation Platform for infrastructure provisioning as well as application deployment on Kubernetes and virtual machines.

We don't use Tower very often. We are currently primarily using the Ansible Playbook.

There are new modules available, which help to simplify the workflow. That is what we like about it.

When compared to Terraform, the execution speed of Ansible is very slow due to the way it executes things.

Improvements should be made in terms of execution speed, which is, I believe, the most lacking feature. Aside from that, re-triggering a failed task is another useful feature.

I have been working with the Red Hat Ansible Automation Platform for approximately one year.

I don't remember the exact version we're working with, but it's N-1.

Red Hat Ansible Automation Platform is a stable solution.

I've had no issues with the scalability of the Red Hat Ansible Automation Platform.

Our organization has four to five administrators who use this solution.

We have contacted technical support. I would rate them a four out of five.

Positive

We are also using Terraform.

The initial setup is quite straightforward.

This solution does not require specific maintenance.

The deployment was done in-house.

The cost is determined by the number of endpoints.

A license is required, if you are using Tower, we don't use it very often.

It is slower than other solutions.

Terraform is better for infrastructure provisioning. However, once the infrastructure is provisioned, we don't see any alternatives to Ansible.

I have a partnership with Red Hat.

It's clear and simple, and there's plenty of help available.

I would rate the Red Hat Ansible Automation Platform an eight out of ten.