Controller of Controllers with Red Hat Interconnect
Here in this blog, we are going to learn about Controller of Controllers with Red Hat Interconnect.
Controller of Controllers
Ansible Controller is used as the parent instance in the Controller of Controllers architectural approach to automation, which allows for the instantiation, configuration, and management of Ansible Controller child instances. The Ansible Controller’s API, which enables complete configuration of the controller and automated operations, is nearly often used to accomplish this.
Instead of doing direct automation against endpoints, the parent controller configures the child controllers to carry out that automation. Since this is the Ansible ecosystem, the configuration is often defined as Ansible variables and then fed into collections like infra.controller_configuration and ansible.controller.
After setting up, the child controllers start automating against the endpoints. In hybrid cloud installations, this mirrors the “traditional” automation strategy, which involves Ansible Controller automating directly against endpoints.
Together, these two components provide a highly scalable solution that enables automation at an enormous scale while maintaining local autonomy for individual Controller deployments and highly automated configuration and management of that automation fabric.
Red Hat Interconnect
Although the Controller of Controllers design is very effective for highly dispersed automation, implementing it might be challenging due to the need to traverse different network topologies. Typically, this entails navigating through the public internet, many levels of stateful firewalls that block inbound access, poor bandwidth, unreliable connectivity, and continuously updated routing tables.
Red Hat Interconnect enters the architecture at this point. It can connect services across these network topologies as a layer 7 connection. Even if the service is located far away at a distant location on a small compute device within a highly secure network, it is presented as a real service within a Kubernetes namespace.
A Controller of Controllers architecture can be protected and extended throughout a large-scale edge deployment using Red Hat Interconnect.
In a lab setting, behind a number of routers and firewalls that can reach outward, this demonstration employs a ROSA cluster configured to operate a parent controller and a RHEL virtual machine operating the child controller.
Install the Parental Controls
On top of OpenShift, I have first deployed a copy of Ansible Controller using the Ansible Automation Platform operator. Although this can be changed, I’m using the standard aap namespace for demonstration purposes.
To handle child controllers inside the parent controller instance, I’ve configured a few things. I first added a host and made a list of child controllers:
I then made a project that had the child controllers’ YAML configuration:
Lastly, I created a job template that will execute and configure the child controllers:
For reference, the child controller configuration is shown below:
Make sure the parent and child controller are connected.
Unconfigured Ansible Controller is present at a distant location. The Skupper CLI, which is Red Hat Interconnect’s upstream, is installed.
Using the OC CLI tooling, first authenticate to the OpenShift cluster:
Next, initialize Red Hat Interconnect and change to the namespace where AAP is installed:
You can see that Interconnect has been set up in my namespace and that a few pods are currently active in this screenshot.
Then, on the distant system running Ansible Controller, initialize the gateway:
Create a service and expose it in the namespace after the gateway has been initialized:
Once finished, a service has been started within the namespace and a link has been made between it and the remote machine executing Controller:
Establish a route so that it is possible to reach the remote controller instance using the OpenShift controller ingress to make sure
Once the route has been set up, check that it works by launching a web browser, going to the route, and seeing the Controller Web Interface:
Create a service and expose it in the namespace after the gateway has been initialized
Once finished, a service has been started within the namespace and a link has been made between it and the remote machine executing Controller.
Establish a route so that it is possible to reach the remote controller instance using the OpenShift controller ingress to make sure.
Once the route has been set up, check that it works by launching a web browser, going to the route, and seeing the Controller Web Interface:
Wrap up
Red Hat Application Interconnect was used as a connection overlay in this presentation to provide connectivity between a centralized parent Controller and a child Controller across a substantially dissimilar network topology.
This may be extended out to include thousands of child controllers or it could be expanded to include additional services running in the central location, like source control or image registries for execution environments.