Our Red Hat colleagues over on the OpenShift Container Platform team have announced the general availability of OpenShift Ansible Broker, which is a new way to easily orchestrate services external to an OpenShift-deployed containerized application by using Ansible automation. But just what is the OpenShift Ansible Broker, and how does it fit into the wider Ansible ecosystem?
At the simplest level, the Red Hat OpenShift team has given users a way to expose Ansible workloads in the OpenShift Container Platform Service Catalog via the Open Service Broker API.
If you haven’t already, we’d recommend you read What’s new in OpenShift 3.7 as this has a good explanation of the concepts and motivation behind the work.
This is a fantastic development that places Ansible in a prime position within the OpenShift Container Platform Service Broker and great news for the continued journey for Ansible as Red Hat’s language of automation. It extends the current capabilities of Red Hat OpenShift Container Platform with Ansible’s simple, powerful, and agentless capability, making the journey to hybrid cloud easier. There are some best practices about how you can use this new capability to achieve maximum benefit, and we’d like to discuss that here.
There are a few ways OpenShift Ansible Broker can be used, but the primary use case is for simply exposing off-platform services (either in the cloud or on-premises) that do not reside on your Red Hat OpenShift Container Platform deployment by using your existing Ansible skills and know-how. For the other ways I allude to, we’ll write about those in the future in conjunction with the Red Hat OpenShift team.
As you already use Ansible, you will have Ansible Playbooks perform all kinds of tasks. Create a database instance on a shared RDBMS service, create users and set up some tables. You might want to call out to your external SSL certificate provider, request changes to your network outside of Red Hat OpenShift Container Platform, hook into your big data estate, you did it in Ansible before, now you still can. It’s now possible to reuse that content, to migrate those Ansible artifacts and skills to execute in OpenShift Ansible Broker and expose it via the OpenShift Container Platform Service Catalog.
So what does it take to reuse Ansible artifacts? First, that very much depends on what was done before.
Using your existing Ansible Playbooks and Roles with OpenShift Ansible Broker is a bit more complicated than just pointing the broker at a role. Because of how the Kubernetes Open Service Broker was written, there are specific API capabilities presented by broker, and the Ansible integration needed to conform to how those APIs would expect to call external services. As a project, the Open Service Broker API aims to deliver a single simplified way of delivering services to cloud native platforms. To ensure it can do this consistently it has to be very opinionated to allow consistency and - importantly - interoperability across those platforms. The API has a selection of operations and they mean very specific things.
“In general, provisioning reserves a resource on a service; we call this reserved resource a service instance. What a service instance represents can vary by service. Examples include a single database on a multi-tenant server, a dedicated cluster, or an account on a web application.
“What a binding represents MAY also vary by service. In general creation of a binding either generates credentials necessary for accessing the resource or provides the service instance with information for a configuration change.”
Extract from https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#api-overview
While the operations of provision and bind can be wide in scope, they are very specific in intent. Therefore, functionally, the construction of normal playbooks and roles will unlikely conform to the operation types of the Open Service Broker API unless that decision was taken at the very start of the automation design process. To move playbooks and roles to OpenShift Ansible Broker, a small amount of refactoring may be required.
If we look at the construction of OpenShift Ansible Broker, it is a container with an Ansible runtime, and user-provided Ansible content (referred to as an Ansible Playbook Bundle) that functionally segregate in line with the Open Service Broker API operations (provision, deprovision, update, bind, etc.). At a minimum, each service will contain a set of commands, or more likely an Ansible Role, that aligns to a function of the API operation. The Ansible runtime, along with the user-generated Playbooks are delivered to the catalog as an Ansible container that executes as a service. When a specific operation is called in the API, the container spins up and executes the required functional playbook based on the requested action.
As long as you achieve functional parity within your role or commands, the Ansible content can be used in OpenShift Ansible Broker and normal Ansible workflow with some changes. If you don’t have functional parity you may need to adjust the way you approach your use of roles to minimize your effort in using both.
This isn’t an issue as such, just an acknowledgement that Ansible is a highly flexible tool that can be adapted to many workflows and different operating environments. It is inevitable that this will lead to subtle differences in usage, just as there is between the different cloud providers and traditional on-premise systems. But for users that will expose services to both Red Hat OpenShift Container Platform hosted applications and on other app platforms, going forward, the form required for Ansible Automation can easily be factored into the service offering to match your operating model.
Over time as the offerings evolve, we’ll be looking at ways to streamline the process and provide advice on how best to maximize benefits when using OpenShift Ansible Broker. Some of this will come from our own use of OpenShift Ansible Broker at Red Hat and some will come from customer experience and feedback, so let us know how you get on, join in community discussions (git: OpenShift Ansible Broker or IRC: #asbroker on freenode) and help us make the next version even better.
This is a great step forward bringing the ease and simplicity of Ansible Automation to the power and scale of OpenShift. We continue to work with OpenShift Container Platform to strengthen the Ansible experience with OpenShift in both available content and the user experience that is core to both platforms.
