Red Hat Ansible Automation Platform Reviews

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 automation. It is integrated with Datavations. When we start Datavations, it calls the Ansible tower, which executes tasks like automated checks between the servers. We also use Ansible when we need to patch or upgrade our software.

Ansible has saved us lots of time. Previously, it took us much longer to deploy or make changes across systems. 

I like the fact that Ansible is agentless.

The support could be better. 

We have used Ansible for three or four years.

Ansible seems steady. It's stable all the time.

I rate Ansible eight out of 10 for scalability. 

I rate Ansible support eight out of 10. I rarely use them. It isn't the worst, but the response time could be better. 

I rate Ansible 10 out of 10 for ease of deployment. Deploying Ansible was straightforward and only takes about a minute. It starts with the CI/CD process, and it's automated so that when there is a change to the code, the changes are applied across servers or applications.

I rate Red Hat Ansible 10 out of 10. I recommend Ansible. It's easy to use. 

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.

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 to manage all configurations and deployments.

We were growing at the time. I was able to take the old build manifest and automate everything. So when it came time to spin everything up, it was quick and simple. I could spin it up and test it. When it came time to roll production, it was a done deal. When we expanded to multiple data centers, it was the same thing: Change a few IP addresses, change some names, and off we went.

It helps me do a lot more. Where previously we had a couple of guys doing what I do, now it's just me.

The ability to centralize everything, to centralize management, and to push changes quickly and reliably. That's the main use for us.

In my opinion, one thing that needs improvement is mass updates: How I can parallelize that process a little bit better? It seems right now that I run through one set of servers, and then another set of servers, and then another set of servers but I'm not sure all those checks are needed. If I could parallelize different types of servers, like web servers and DB servers, that would make everything run a little bit more efficiently.

It's reliable.

We're a small shop. It seems it could be quicker, but for what it does, it's fine.

I had briefly toyed around with Chef and Puppet, but I didn't get anywhere with them. Then I found Ansible. It was at a previous job where I picked up on Ansible. At that job, they were against putting an agent on anything. So Ansible was it. That was the easy sell. Then I figured it out and rolled with it.

The setup of Ansible is straightforward. You just download it and get started.

In terms of the documentation, I'm used to it, so it works fine for me now. At first, it took me a minute to find out exactly how to quickly find my way around the documentation, but now I'm comfortable in it and I'm happy with it.

We mostly run everything CentOS, and do the Community edition.

We are a partner, but we also use it in-house. It drives all of our demonstrations. We've used Ansible community to be able to easily deploy and set up pipelines end-to-end in Dockers or containers. Therefore, we can have an easy to go, ready demonstration set up in less than five minutes. We can also have a customer go to our GitHub page and just be able to use Ansible to have it easily deployed, then we don't have to give them any more instructions, i.e., run this playbook and you'll be set up in no time.

Our sales engineers use it a lot in order to understand how the security works between Ansible and our own product, so they can better sell it. We have been lucky enough to have a great partnership with Red Hat, so we receive a lot of great feedback directly from their solutions architects. 

We are always getting together and sharing information. We will be training them on Conjur, and on Thursday, they have us being trained on Ansible. So, it's a great partnership.

I really love the user interface:

• The first time I started to use it, I found that it was well-built and very easy to navigate around. Things were were I expected them to be. I didn't have to go clicking around too much to find what I wanted to do. 
• The documentation on their website is well done. Anytime that I need to, I can pull up its six tabs. For example, I wrote my first Ansible playbook with no Internet on a plane and those six tabs cached in my phone's browser. 

Red Hat has always done a great job with their documentation. However, I sort of grew up around most of their products.

As far as the dashboard is concerned, it is a nice, quick, easy look without having to dig in, deep dive into the different metrics, etc. I obtain a quick presentation of what's failed and what's been successful. Having an operator and/or admin get that quick of a look is beneficial because they can quickly act and react to job failures, etc.

It can use some more credential types. I've found that when I go looking for a certain credential type, such as private keys, they're not really there. I end up having to either custom-make my own credential type or trying to figure out what is already available that I can fit it into and use. I would prefer to see a lot of the more popular ones included as an out-of-the-box credential type. Because, at least for our integration with Ansible Tower, we do have to put a certificate and a key into the Tower credentials and custom-make that credential type.

We're not the only product that does it. I feel like if it's such an adopted method of dealing with third-party tools, maybe we should add in that credential type and make it easier for everyone.

Tower is stable, and AWX is not. AWX is not meant to be in production. 

Tower is very stable. Sometimes the job isolation can cause me to rip out my hair, but I know now that it is the job isolation and not an issue on my end. So, I'm good now. 

Scalability should meet our needs going forward.

I've never had to use tech support. I've always been lucky enough to be a partner, so I get direct to where I need to go. I also haven't heard any complaints from our customers.

It depends on the method that you choose. I deployed it in AWS just fine using the CloudFormation template that was provided on the website. As long as people are doing that, then they'll be good to go. I've never had an issue deploying. I can't imagine anybody having an issue deploying it. They do a pretty good job of orchestrating the orchestrator.

I learned about the solution last year through AWX. Surprisingly enough, I found AWX first, then made my way to Tower from there.

From a security standpoint, we are a security company so I will always back my product over what these other tools do. From their standpoint, we do practice adding certificates and keys into Tower credentials. We use and trust it. My preference would always be to get all of the secrets out of all the tools and manage them in a central location.

They have some room for improvement, but they're doing a great job as is.