Bulk API in Automation Controller

Automation Controller API:

Automation controller has a rich ReSTful API. REST stands for Representational State Transfer and is sometimes spelled as “ReST”. It relies on a stateless, client-server, and cacheable communications protocol, usually the HTTP protocol. REST APIs provide access to resources (data entities) via URI paths. You can visit the automation controller REST API in a web browser at: http://<server name>/api/

API Usage:

Many automation controller customers use the API to build their own event driven automation type solutions that draw data from their environment and then trigger jobs in the automation controller. This type of architecture can lead to incredibly high frequency and volume of requests to the controller API pushing controller’s API to the breaking point.

The API is the simplest and most straightforward way to interact with automation controller for any external system. These external systems and tools integrate with the automation controller API to mainly launch the jobs and get results about the jobs. Additionally, the inventory information is stored in an external system and pushed to the automation controller via API too. Given the fact that we have seen enterprises manage thousands of hosts via automation controller, the number of API calls Continue reading

Enhancing/Maximizing your Scaling capability with Automation Controller 2.3

Red Hat Ansible Automation Platform 2 is the next generation automation platform from Red Hat’s trusted enterprise technology experts. We are excited to announce that the Ansible Automation Platform 2.3 release includes automation controller 4.3.

In the previous blog, we saw that automation controller 4.1 provides significant performance improvements as compared to Red Hat Ansible Tower 3.8. Automation controller 4.3 is taking that one step further. We will elaborate on an important change with callback receiver workers in automation controller 4.3 and how it can have an impact on the performance.

Callback Receiver

The callback receiver is the process in charge of transforming the standard output of Ansible into serialized objects in the automation controller database. This enables reviewing and querying results from across all your infrastructure and automation. This process is I/O and CPU intensive and requires performance considerations.

Every control node in automation controller has a callback receiver process. It receives job events that result from Ansible jobs. Job events are JSON structures, created when Ansible calls the runner callback plugin hooks. This enables Ansible to capture the result of a playbook run. The job event data structures contain Continue reading

Performance Improvements in Automation Controller 4.1

Red Hat Ansible Automation Platform 2 is the next generation automation platform from Red Hat’s trusted enterprise technology experts. With the release of Ansible Automation Platform 2.1, users now have access to the latest control plane – automation controller 4.1.

Automation controller helps standardize how automation is deployed, initiated, delegated, and audited, allowing enterprises to automate with confidence while reducing sprawl and variance. Users can manage inventory, launch and schedule workflows, track changes, and integrate into reporting, all from a centralized user interface and RESTful API.

Automation controller 4.1 provides significant performance improvements when compared to its predecessor Ansible Tower 3.8. To put this into context, we used Ansible Tower 3.8 to run jobs, capture various metrics while jobs were running/finished, and compare that with automation controller 4.1. This post highlights the significant performance improvements in automation controller 4.1.

Benchmark framework

In order to deep dive into the prospective performance enhancements with the latest automation controller, we at the performance engineering team at Red Hat created a benchmarking framework consisting of the following workflow:

Installation of RHEL 8.3 virtual machines with 4 CPU and 16 GB RAM deployed within the IBM Cloud
Continue reading