Red Hat Ansible Automation Platform Reviews

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. 

We had a lot of manual labor. We had patching that was a manual process, and we had configuration drift. There were a lot of touch points. There were parts of the business where we knew that there could be a faster deployment and much quicker development and production. Ansible has increased our speed of deployment. We have a source of truth now. It has sped everything up, and it has saved a lot of people's time.

We've got on-prem and cloud deployment. We've got it in AWS, and we've got a proof of concept in Azure. We are looking at Azure SaaS, but at the moment, we don't know which way that would go.

We're realizing its benefits on a daily basis now. The biggest issue that we've had has been changing the way people work. We have a lot of people doing the work, and they all had a certain way of working. There were a certain set of tools that they used. We had to gradually migrate all of the tools that they were using to be more automated. There was a lot of code and a lot of tools on people's individual machines or shared drives. For example, User 1 had all of his applications and tools on his machine, and he might also have had some small scripts that he wrote personally on his machine. When User 2 came along, he didn't get to see what User 1 had because all of the scripts were on his machine. By automating more, we've put all of our code into a central repository so that everybody who is a member of that repository can see everyone's code. Nobody is siloed anymore. We have a lot more collaboration. There is a lot more progressive thinking in the way people are working. It is not where a bit of code is written for one specific purpose. It is always adaptable by just changing variables, etc.

It has effectively sped up everything from our sandpit environment to our full CI/CD process and our end deployment. Previously, we had to build everything manually in the sandpit. We had to build everything manually in the test environment, and we had to build everything manually in the production environment. Because we have environments that are matched all the way through, now, after we've built something in the sandpit, we can just promote that code. So, the copying of that code through various platforms has been eliminated with the use of Ansible and our repository system.

It has an easy-to-use interface. It is REST API driven, and it integrates with Active Directory. It provides the ability to grant permissions to other users who would not necessarily have those permissions via the GUI so that they could run other people's jobs. For example, you could have the Oracle team grant permissions to the Linux team so that they can use each of those playbooks or each other's code. It is called shift-left.

Ansible has just been upgraded, and the only issue that we are seeing at the moment is that the user interface can be slow. We're currently investigating the refresh period with Red Hat when you click a job and run a job. It seems that the buffer no longer runs in real-time. We haven't discovered whether that's partially an issue with our environment, but Red Hat has come back and said that they're working on a couple of bugs in the background. We've upgraded to that version in the last six months, and that's the only issue that we've seen.

There should be a more adaptive search feature. For example, if you had the name Mr. Smith, and you type in Smith, sometimes, it doesn't find Smith. You've to type Mr. first and then Smith. The search feature has certainly taken a little bit of a step backward from what we were used to in Ansible Tower.

I feel if we took this to the customer now and asked the customer to start using the product as it is, we'd be getting a lot of pushback because as an automation platform, it feels as if it is very early in its life cycle and development. I know that within Red Hat, a lot of the tests that they perform are automated tests. Somebody doesn't necessarily sit at the GUI. When you speak to Red Hat, they always say that a lot of the customers don't use the GUI. They might have got a front end or some sort of ServiceNow provider that runs all these jobs, but the search and job updates are the main challenges at this time.

It has been five years with Ansible Core and three years with the Red Hat Ansible Tower offering.

Its stability has been good. There are odd glitches within Ansible AAP, but within Core, there are no problems.

It is scalable. We just add more nodes if we need them.

It is used at multiple locations and in multiple departments, and our end users have multiple operating systems. There are probably over a hundred thousand users. We're going to put some more nodes in at some point in the future.

Their technical support has been good. Because we're a big organization, we have our own allocated SME within Red Hat, and we normally liaise with him. The Ansible support itself has been okay if we need to raise a ticket, but we're usually raising tickets just to get something on their system. We normally speak with the SME allocated to us, and he has been excellent. Our SME is called Pat, and I would rate him a ten out of ten. 

I would rate the support team within Red Hat an eight out of ten. The trouble is that if you raise a support case with Red Hat, they don't appreciate how much experience a specific customer has got or how much troubleshooting they've already done. So, the first thing they do is they'll ask for a basic set of files, which is understandable, but when we've already passed that point where we've already done all the checks, instead of going in at the first line, we need to go in at the third line to get something resolved. That's where Pat picks it up.

Positive

We didn't use any other solution previously. There has been a scattering of other automation tools around, but nothing that had physically been a business directive. It was always bash scripts, secure CRT scripts, etc. They were just scattered everywhere. There was no semblance of order. If we had anything, it could be a guy that was working two days a week, but you never knew what day he was working or who was supporting it. We had nothing like that other than Puppet.

The main factor for going for Ansible was that within our environment, there were already a lot of people who had Ansible engine experience or had worked with Ansible Core. Ansible is an easy-to-use language. It is very easy to pick up, and you can start automating quite quickly with Ansible. It is not as complicated as Python or anything like that. There is ease of use. It is not like writing Python code where there is a lot out there, but there is no front-end GUI that we could bring users into quite quickly. It is not as scary because you can look at the GUI, and you can click around and run jobs within the GUI. You don't need to have any deep Python experience or complicated Ansible coding experience. Once you've got a playbook in your repository, you can just run it from the web front end, and we couldn't find anything else that had a web front end like that.

It has got a big community. There are always people out there writing new modules, and you've got Ansible Galaxy, and you've got Ansible Collections where one is vendor-provided and one is community-provided. It is just very progressive. 

It was straightforward. The deployment took about a week.

We liaised with Red Hat. For Tower, we followed the deployment guide, and for the automation platform, we followed the upgrade process. We fed back any issues we had to Red Hat, and they were quick to resolve them.

There are ten people on our team, but not all of them were involved in deployment. It is a two or three-man job. We're all engineers.

In terms of maintenance, we have regular maintenance windows. Whenever there is a new version of AAP, we update it. We obviously run all our Linux patches on a regular basis, and we always sit and wait till we've done some testing on Ansible before we update the Ansible version on that box. There are ten people on our team, and we normally just pick slots between us so that the same person is not doing the same maintenance window all the time. The majority of it is automated, and it is just a case of somebody sitting in and checking that the job has run, and there haven't been any issues.

At the moment, it is just time saved.

I don't see the pricing or licensing features, but from what I understand, it is fairly reasonable.

Don't be narrow-minded. Don't be put off by adopting something that you've never worked with before. There is plenty of documentation out there to help you. It has a thriving community, and there is plenty of information online. Red Hat's documentation is also very good. You can get yourself up and running across a variety of platforms quite quickly by just looking at the Ansible site.

I would rate it a nine out of ten because there are a few quirks with the GUI at the moment. I would've rated Ansible Tower 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 group at Oracle has been using the product for at least a year. I have only been using the product for four months.

We have done a lot of work to do automation. Previously, it wasn't in the DNA of Oracle at all. Ansible has brought a platform which has allowed us to automate a lot of services, not just server services, but network services as well.

This solution allows us to stitch a lot of different parts of the workflow together. We have integrations with some of our ticketing and monitoring systems, which allows work to start work happening.

The community support is broad with a lot of available plugins and modules. People have shared a lot of information about how to do things with the solution.

• How do you democratize Ansible across more engineers that don't have a large body of scripting knowledge to leverage? 
• Do you bring Ansible down to that common denominator, or do you bring the engineer up to some common level of scripting capabilities? 

I think we need to meet in the middle. We are trying to build tools which allow engineers who don't have a lot of scripting capabilities to still leverage the power of Ansible in more standardized ways without just a choose your own adventure approach. We are trying to make Ansible simpler for more engineers to be able to use and raise the level of engineering skills. We are trying to do both.

Ansible could probably help here with better documentation.

It is stable.

We definitely don't have any scale challenges at Oracle. I came from Microsoft, where scale was an issue. We have a small six figures of servers, so it's not a massive environment, so scalability is okay.

The setup is straightforward. It's as easy as anything else to set up.

We do use Puppet and Chef in some other areas. However, Ansible is our dominant platform.

It's an effective solution for the problem space.

In terms of learning about the solution and finding new ways to do things or solving problems, I think you are a quick Google search away.

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.

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.

For my client, it has improved a lot of the problems that we had. For example, with package management, I wrote a script in Bash to check all the different PHP versions in Red Hat. With Ansible, I can do it for all my systems at once, which is huge.

There are a lot of different, little nuances that I like about Ansible. The biggest is the checking and validating, since it makes sure our packages are properly patched. We are running the latest version (PHP, etc.) on our different packages and validating them.

I like learning and challenging myself with it, finding out if there are different problems that we can automate. I always look to see if there is a community solution first on the Internet. By looking at what other people have done, I can see if I can try to emulate their work.

Ansible could use more public relations and marketing.

It is stable.

It is scalable.

We do have a support license with Red Hat. I can call them and ask them questions, if I am stuck somewhere. However, our Linux department is really smart, and they know what they are talking about if I run into something, so I reach out to my resources first before I go to Red Hat.

The setup is simple and easy.

Puppet and Chef are cool, and have been in the game much longer, but Ansible is way better.

I like what Red Hat did with Ansible. They are keeping the community focus as a whole and building around the grass roots movement that Ansible started. They are keeping that and putting a fresh face on it.

Tower is user-friendly too.