What is your primary use case for Red Hat Ansible Automation Platform?

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.

We can use the solution for a group deployment if we have an infrastructure where we need to deploy software onto multiple machines at the same time. The tool should be on an Ansible server, and the server should be able to do SSH to the multiple hosts on which it wants to act.

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.

I use the solution for all kinds of automation, network automation, compliance security, software installation, and software configuration. I started using the solution as a configuration management tool, and now I also use it for automation. I also use Red Hat Ansible Automation Platform within the CMP platform Morpheus.

I am using Red Hat Ansible Automation Platform as a part of the scale-up of the nodes in OpenShift. Mostly, we use the solution for upgrading-related stuff.

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.

We primarily use this solution for network configuration pushes. We use scripts from Ansible to push configurations to specific devices such as routers.

We are using the Red Hat Ansible Automation Platform for storage and for confirmation management. We are using a template in VMware. The solution can be deployed on the cloud or on-premise.

Our company use the solution to automate IT for many government use cases.

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.

Our company uses the solution for clients with private or multi-cloud platforms. The solution automates the process of integrating multi-cloud applications. We have more than 1,000 users across our clients.

Our company uses the solution for automations, patching, scheduling, and installations. We have 500 users throughout the company and two or three people per team who handle ongoing maintenance.

We can use it to configure or to change the configuration in a large number of servers. Also, if there are some issues in comprehension, for example, permission or ownership, we can fix that with the Ansible label. We can use other advanced features. Currently, for example, we are using BigFix for automation. We use Ansible since it doesn't need agents to install on every server. For BigFix, in contrast, you do need to have a BigFix agent for every server. Not having to do that with Ansible is a benefit for us.

We deploy the production environment using the provisioning for Terraform. We provision the cluster we need. If we need three or four nodes, like provisioning for hardware, OS provisioning, and bootstrap provisioning, we will use Terraform. After Terraform, we have to do any configuration changes. To install some packages, I do the cluster configuration changes and use Ansible with Terraform. I will integrate and deploy products based on the Ansible configuration files by writing playbooks. There are many configuration management tools currently in the market. If there is a huge cluster, we use Chef. For minimum nodes, we use Ansible. I'm using the latest version. It's version 2.13.4. The solution is deployed on AWS cloud.

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

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 use it to configure operating systems, apply security, and for day-to-day management. Our use cases include collecting information from end nodes, rather than writing shell scripts or any other types of scripts, as was done historically, and rather than even logging in manually and collecting information from the nodes. These days, you write an Ansible playbook and it does things for you. And if you don't have a playbook, you can simply gather the facts from the nodes, and that's available out-of-the-box without writing anything. You simply utilize the Ansible modules. Our Ansible deployment is for a hybrid environment. We have on-premises services that we use Ansible to configure as well as cloud instances.

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.

My use cases with Ansible include configuring network devices. That is what I used it for when I was first learning Ansible. I then automated PKI (public key infrastructure) compliance. That particular domain has different servers and I developed an automation solution, using Ansible, to automate the configuration of the PKI servers. And for the last eight or nine months, I have been working on automating cloud solutions, such as deploying services or upgrading or migrating to a specific version of a product. I am working on a client network, and that client also has clients who are hiring our client for hosted services, such as websites or internal applications for their employees or for their end-users. All the database-related activities and operations are being handled by our client. What I am doing, in that context, has to do with patches. There are patch releases, or bundles, or package upgrades, but the developers of those packages can't go and directly upgrade the particular sites of every customer. So we have developed an automation solution for them, using Ansible, that can directly trigger these processes. They can point out that "this is the package," and our automation in the backend, using Ansible, takes care of it. It's a tool to automate different domains and Ansible can reduce human efforts for two domains in particular. One is DevOps and the other is network automation.

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.

Server configuration management: This is Ansible's forte as it has multiple modules to interact with servers either to orchestrate or configure them. This can take multiple forms like pushing a script and executing it, sending commands to restart services... Network configuration management: Ansible coupled with Jinja2 allows to push parametered configurations in a reliable way. Support for network gear isn't as common as server/development use cases. But, with some hacking, it can be managed The tool can also be used for CI/CD software deployment, But, we didn't explore this topic with it that much, yet.

It is used to support WAN network equipment.

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.

So far, the main thing we've been doing with it is using it to automate our monthly patching of servers. Since we have the whole inventory, we can patch this project's servers. We can use the exclude, exclude others, and, in one hour, do a patch that would take people one night to do.

We use it for any sort of automation. We started using Ansible about 18 months back. But then we realized, as we expanded Ansible, that we needed controls around it. We didn't want people just running around crazily running Playbooks. And that's where Tower came in. We bought licenses and it's kind of worked out, though we expect a lot more. I did have a meeting yesterday with the Product Manager for Tower. I did give some suggestions. It's worked out but we've got more expectations, and I hope they work out as well. Some examples of the tasks we've automated include OS patching to begin with - everyone does that. We have been using Ansible and Tower for a lot of data collection, for auditing, collecting data from across different servers: network, OS, Windows, Linux, etc. That's one of our major automations. In addition, AWS and various clouds, if we have to spin something up. We're not using it for compliance yet. I saw a demo about that yesterday and we'll probably explore that.

We use it to manage all configurations and deployments.

Our use case is to stitch together all the units, all the teams writing roles and Playbooks, and provide a central point for execution, and a way of managing what is executing against the infrastructure.

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.

We use it both internally on our managed services offerings, which are new for us, and I've used it for the last two years in my customers' environments to help me with deployments, primarily on the networking side. We also place a big focus on source control and the software development lifecycle.

Our primary use case is automating security compliance tasks. It has met our expectations. Automating security compliance tasks is what drew us towards the product initially. It definitely checked the boxes for what we needed to be able to implement.

We just started using Community with Ansible. We are trying to install agents to either a cloud or a local virtual machine. We are still in the starting phase as it has only been implemented for two months.

The primary use case is network automation. I have been trying to use it to roll out new offices and update things, like NTP server changes. I would like to roll NTP server changes out with a couple of clicks instead of having to go and manage several hundred devices. I have been using the product since 2016.

We use it to deploy our infrastructure.

You can literally automate everything. Whatever you want to do if you did it with shell scripts, you can do it in Ansible. There is also the ability to use Tower AWX, which allows you to store your variables in a hierarchy. If you're familiar with the Puppet product from more than six years ago, it allowed you to do inheritance on variables. Ansible made sure that they had that in their product. It's also not agent-driven. Therefore, you don't have the added extra bloat to your deployments. Just run your command, then get the code. You can deploy using packages on Ansible or you could deploy binary files by copying over.

Everyone gets super excited about when we show them the automation part of Ansible: * How can you orchestrate things? * How do you operationalize it? * How do you take it to a group of people who don't have the experience writing playbooks themselves nor experience with command line? Tower allows control for more people to use it and have some safety nets behind it.

We have reached the stage where we really need to automate all our tasks. That is why we are trying to use Ansible Tower. We are trying to help our customers simplify their deployment process for deploying their private clouds, like Red Hat object tags. We start by the deploying the director Undercloud, Overcloud, etc. We are trying to develop automation for White box switches: Integration, deployment, NOS installation, etc.

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 are still implementing it.

We are using Ansible to automate the infra for various companies in the ASEAN region. The tasks include the creation of virtual machines, provisioning volumes/disks, database installation, user creation, and configuration. The environment includes Linux boxes and Nutanix for software-defined storage.