Red Hat Ansible Automation Platform Reviews

The primary use case is for configuration management. We use it for patching and updating. We also use it to send out new configs to all our servers.

It saves time; it cut our configuration time. 

It is very easy to use, and there is less room for error. For exampe, if we had 10 servers, and we need to update a file on each server. So, you would have to go into every server and update the file manually, then sign out. You can mess up on the sixth one and have configuration issues. It is easier to use one server to create a playbook, then you just hit "push" and the playbook is distributed to all the servers.

Ansible Tower offers use a UI where we can see all the pushes that have gone into the server.

It is very easy to grasp. Multiple users on my team can utilize it without me giving them a thorough tutorial. This has been helpful.

For Ansible Tower, there are three tiers with ten nodes. I would like them to expand those ten nodes to 20, because ten nodes is not enough to test on.

It needs better documentation when setting it up. It is not very clearly stated how exactly to set up Ansible Tower, though it is pretty self-explanatory.

It is definitely a workhorse. It does our back-end deployment, so we utilize it very heavily. We're committing too much to it, so we have it highly available. We built some redundancies around it just in case it ever goes down, because it's a big part of our work.

We are about 50 servers. It is not very big, but we are continuing to grow.

If we want to utilize technical support, we would need to use a more premium solution since Ansible Tower is free.

The integration and configuration in our AWS environment was super easy to set up. It does all our tasks. Having it integrate with our front-end and back-end deployment has all been seamless. There is no custom configurations.

Ansible Tower is free. Until they lower the cost, we are holding off on purchasing the product.

We considered Chef and Puppet, which are very similar to Ansible. However, they have a more Ruby-based programming language. Therefore, it takes more time to learn and incorporate into a company. Ansible is easier for everyone to understand what is going on without actually knowing the programming language.

We chose Ansible for simplicity. Ansible is easy to set up, then get up and running in about a day or so. With Chef, I would have had to sit there and learn it, so the time constraints didn't really work out.

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.

We have a lot of Red Hat servers in our data center environment, so we use this solution to manage the configuration, deploy and push configuration management. In addition, we use the Red Hat Ansible Automation Platform to automate deployment tasks.

We can manage all the configuration consistency between all our servers. It is a configuration management tool, so we can easily manage our consistent configuration course over different Red Hat or Linux servers. We have not used Windows recently and are using only Linux now.

We like the GUI-based interface for the tower. Before, we only had a command-line interface to run all the Ansible tasks. Now, the Ansible tower provides the complete GUI functionality to run, manage, and create the templates and the Ansible jobs. This includes the code and YAML file we can create. The GUI interface is the added advantage of this solution, including some integration with the different plugins.

It should support more integration with different products. For example, it is for network security automation, and with the VMware product, they don't have an integration for NFTX right now. So they should include this integration capability so we can automate more tasks with this solution.

We have been using Red Hat Ansible Automation Platform since 2021, and we are using version 3.2. It is deployed on-premises.

It is a stable solution. 

It is a scalable solution and is based on your node license. We are using more than 400 servers right now, and it requires one senior system engineer for maintenance and deployment. We plan to increase the usage using Windows automation.

I rate the technical support an eight out of ten. 

Positive

We used a Puppet configuration in the past. We staged with Puppet and then moved to Red Hat Ansible Automation Platform.

The initial setup and deployment were easy, but the first two days of operations were a bit complex. We completed the deployment in-house.

There is a return on investment as a technical person. It has saved time and effort in maintaining the deployment environment. So on the technical side, it's saved lots of time and effort on the configuration.

I believe the cost per node basis is around $125 per node.

I rate this solution a nine out of ten. Regarding advice, for the deployment, I would suggest working on inventory first. They should also consider their use cases and which workflow they want to implement. In the next release, they should have VMware tight interrogation.

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.

On the network side, I already have a lot of our firewall-related processes automated. If it's not automated all the way from the ticket system, our network team members, our tier-one guys in India, can just go into the Tower web interface and fill in a couple of survey questions. We've used Ansible even longer than that, organizationally, for web servers mainly. Some guys are doing some of the Kubernetes stuff, but I'm personally not involved with those modules.

The community is very important. Right now, I'm focusing on Palo Alto and automating a lot of our firewall processes related to when a developer requests new firewall rules. Right now, that's a totally manual process. I'm three weeks away from putting in an automated process from a third-party tagging system flowing into Ansible and actually writing to our Palo environment through our data centers throughout the world.

Some of the module documentation could be better, but I don't know if that's Red Hat Ansible's fault. Specifically, I've done a lot of Palo, and I've done some Cisco ACI. The Cisco ACI, I don't know who actually produces those particular modules, whether it's Cisco or the community.

Also, it is a little slow on the network side because every time you call a module, it's initiating an SSH or an API call to a network device, and it just slows things down. For the web server guys, all the work is done on the destination server, whereas for network devices, all the work is done on Tower. And then, as I said, it's either SSH-ing or using an API call to the device. Every time you do a module, that slows it down. I heard some rumors, I don't know if they're true, that the Ansible team is looking at improving that performance. But that's hearsay, as far as I know.

I'm going to have to learn more about the Tower and the sharding of jobs that's coming because, right now, I'm just writing stuff to a couple of individual devices - for Cisco ACI and Palo - but once I get into the Cisco IOS, we're talking thousands of devices. 

The setup is pretty straightforward. Getting started with Ansible, training on Pluralsight, it's about three hours. You do some labs and, from there, it's off to the races.

I did some training and I've messed around with Terraform. They do have providers for Palo, specifically. But in network, I'm dealing with mostly bare metal devices. And Terraform, that's just not what it's meant to do. I was trying to see if I could do some things with it, but it's not the right solution.

Some of my peers dealing with servers, they use a lot of Terraform because they can say, "Well, we have an environment that needs to be four to eight servers. Create the Terraform configuration and the TF files and TFR files and just let it do its thing." But I can't really do that with 1,500 physical devices that already exist.

I'll start on Cisco IOS stuff in Q1, 2019. I'm pretty excited to learn about the network engine today, here at AnsibleFest 2018, because I haven't looked at it at all yet.

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.

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

Ansible provides a central solution for automation for our customers.

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

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

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

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

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

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

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

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

I have been using this solution since 2015.

The solution is stable.

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

Technical support is very good, especially from Red Hat.

We have used Red Hat Satellite and Red Hat CloudFormation.

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

Initial setup was complex.

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

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

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

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

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

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

I would give this solution 10 out of 10. 

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

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

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.