Red Hat Ansible Automation Platform Reviews

Our use case for it is as an automation tool. For the Linux side, we have very few automation tools. We do have Puppet Enterprise as a matter of fact, and we're looking at tools for automating our day-to-day operations, server builds, configuration management, etc.

We've got a demo version of Tower. We've been playing with it, using it for patching. One of our first goals is to automate patching.

The improvement is going to come in that we are going to be able to maintain configuration management, through the use of both Puppet and Ansible. Currently, in a manual process, hands-on - that is what kills us. When we have a system administrator trying to do his job, that kills us every time. We have 2,500 servers and if a project comes to him, we have 15-minute time-outs. I don't like that. He'll go in there and he'll change it. And we can't control that and we don't know when it gets changed.

The hope is that we automate and then it's there, we know it's there. And then we'll use Puppet to come in at the back, and just maintain it. That is our plan.

If somebody tries to change something through Puppet, we're going to get reports. Ansible is going to be used on the front end, and if somebody comes up and says, "We need this patch pushed out. It's an urgent patch. It's high criticality. We need to do it now," we'll do it through Ansible. We'll write a Playbook or a module and just, boom, get it done.

The most valuable feature is the Playbooks and pushing them out.

We'll probably use it in conjunction with Puppet, because Puppet is more a solution where every 30 minutes it's going to check, whereas as Ansible doesn't do that. You have to push, from my understanding. That's what I thought. I could be wrong.

It has been stable so far.

It's scalable. We're looking at an enterprise configuration, when we get it done. It's a matter of getting it licensed.

So far, in our interactions with technical support, they've been knowledgeable. We're very happy.

The setup looks pretty straightforward. From what I've seen, although it was done by another person, it seemed to be pretty simple. I think it was an RPM.

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

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.

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.

It's a catch all. We now have a central way of pushing out updates. As long as we have every name of all the hosts on the network that we want to patch on Linux primarily, we have it covered, from one person logging on and issuing the commands, then looking for the feedback from the servers.

I like being able to control multiple systems and push out updates quickly with just a couple of clicks of a button and commands. I like the automation because it is a time saver.

I have seen indications that the documentation needs improvement. They are providing a "How to Improve Your Documentation" presentation at this conference.

It is stable and reliable. I don't see any problems with it.

We patch every week and have seven different environments, so now we are dealing with about 300 servers. However, we could increase that to 20,000 servers, as long as we have them in our catalog. We could push that out and be fine.

We haven't had to use tech support, but they are there. If we need to, I am sure we could easily reach out to them. We have an account.

We chose this solution simply because we use Red Hat. We trust Red Hat, and whatever Red Hat puts out, it is pretty solid.

The setup was done by another team of ours that we worked closely with. They walked us through setting up our own, and it's pretty straightforward. Once you install it, stand it up, and get all the configuration files in place, it seems pretty straightforward. 

I was surprised that it was so straightforward.

It has seamless integration because we are not using Ansible to manage our services. We are creating roles, and those roles configure servers. The way we design the role is we split into multiple roles and each role has its own action to perform. This helps a lot to design our overall architecture.

1. It's written in Python. It is not using Ruby. Python is already available on most of Linux backdrops. If you are using any of their distributions, YUM or DNF, both are using Python. 
2. It is agentless. I don't have to think about which client system my unit has understanding in or not, because I can execute from my system. It will go and configure it, and any module that it is looking for will be shipped out.

Documentation could be improved. Many times, if I'm looking for something, I have to Google it in a lot of places, then figure out what the best approach will be. There are some best practices documents, but they don't give you the information.

If we could have more information on how to figure out the IP address or the specific host, this type of information would help. We could get started up easily.

It is a reliable, stable product.

It is scalable. You can easily configure one or more nodes.

It has a lot of good features. For example, if you want to create a leader, you can execute a role on one node, then ask it to run on all the remaining nodes. It can easily scale this way.

There is always a learning curve when you are using a new tool. Other than that, the initial setup is straightforward.

I looked at Puppet and Chef. They are good tools, but there is a language barrier.

I've been using Python for more than six years. Using Ansible was a piece of cake for me.

Also, Puppet requests an agent. As with many places that I looked at it, it was a no-go if you have to install agent. We have a client system and need to install a client to configure or maintain our systems, so it is a no-go with an agent.  

With Ansible, it can remotely execute tasks and do its job.