The wonders of automation have been thoroughly enjoyed by sysadmins in recent years with tools like Ansible enabling rapid deployment of applications and services across servers and cloud-based platforms. But as the IT world evolves to more container-based technologies, tools like Ansible have not translated well to orchestration-level actions.
This is changing rapidly, thanks to the new Automation Broker project. Part of the OpenShift ecosystem, Automation Broker connects the gap between provisioning servers and provisioning containers.
In an optimal container deployment, containers will each hold individual services that, when linked together, will make up a complete application. Such “links” are managed with orchestration applications, particularly Kubernetes, initially developed by Google and now stewarded by the Cloud Native Computing Foundation. Orchestration is a good name for what Kubernetes does: managing various containers across a deployment to get them working together to create a “symphony”–otherwise known as a fully optimized application.
But, as conducting an orchestra is not a trivial pursuit, nor is orchestrating containers. Kubernetes has a fairly rigorous learning curve, and provisioning applications across multiple containers is not a simple exercise. Given these non-trivial challenges, any sort of automation within Kubernetes would most certainly be a welcome feature.
This is where Automation Broker will step in. The idea behind Automation Broker is that it acts as a service broker that uses a lightweight, container-based application definition called an Ansible Playbook Bundle (APB) to automate service provisioning using Ansible. These playbooks can perform actions on Kubernetes-orchestrated clusters, as well as on the OpenShift platform.
Ansible Playbooks are not particularly new. Collecting separate Ansible roles within a single playbook is a feature that’s been available for server deployments for some time. What’s new, explains Michael Hrivnak, is Automation Broker’s capability to combine roles, playbooks, the Ansible runtime itself, and other tools or data into a single container that deploys an application on Kubernetes.
Right away, the benefits of this combination become apparent. Kubernetes deployments are complex enough as is. But the capability to reuse and automate complex container deployments is a clear advantage for anyone pulling container apps together.
APBs model applications as a collection of Ansible Playbooks within a portable container with an Ansible runtime. This means that the APB itself can be managed as part of the deployment. APBs can also handle provisioning, binding (connecting multiple services together into a larger application), and updating of simple to complex services running both on- or off-platform.
The next challenge ahead for Automation Broker will be moving beyond these deployment-centric actions and integrating with the same kind of functions provided in the CoreOS-based Operator Framework. Besides the build-and-deploy features shared with Automation Broker, the Operator Framework application also handles more operator actions.
“So how does Automation Broker figure out what Day-Two operations look like?” Hrivnak posed as a question during our conversation. “What do data rollbacks and upgrades look like?”
These hurdles are definitely something Hrivnak wants to tackle because this path could lead Automation Broker to provide new day-two operator features, only now focused on container-based services. Getting to a world where end users can select a configuration and deploy applications and services on-demand with containers is a big goal for Automation Broker moving forward.