With the release of OpenShift 3.6 comes a technology preview of Service Catalog and Brokers. This feature reaches across many areas across OpenShift, Red Hat's Enterprise Kubernetes, and is focused on bringing more self-service capabilities through standardized interfaces.
Motivation
Have you ever had to put in a request for resources from an IT group? Oftentimes you want a DB instance or a message queue. Typically you’d submit a request from some ticketing system, which would get routed to the appropriate team to fulfill the request based on some internal service level agreement (SLA). Hopefully you filled in the request properly, otherwise you may have to go back and forth to provide the right details. The team member fulfills the request at some point and transfers you the connection details properly. If these connection details are wrong for some reason or lost, often you need to repeat this process.
The Service Catalog aims to provide a means for IT to manifest services directly to the end user (consumer) of these services. The service is mediated by a broker for the service request. The goal is to have the end user initiate the request and the system to fulfill the request in an automated fashion. It goes a step further to define a simple way to inject the connection details into the consuming application to remove error-prone manual steps.
Kubernetes Service Catalog
The Kubernetes Service Catalog project is in Kubernetes incubation; it is intended to bring integration with Service Brokers to the Kubernetes ecosystem via the Open Service Broker API (more below). A Service Broker is an endpoint that manages a set of services. The end goal of the Service Catalog project is to provide a way for Kubernetes/OpenShift users to consume services from Brokers and easily configure their applications to use those services, without needing detailed knowledge of how those services are created or managed.
The Service Catalog project introduces the Service Catalog API and Service Catalog Controller as depicted:
The goal of these components is to translate the Open Service Broker API requests into Kubernetes requests, the Broker requests are:
| Catalog Management | List of services offered |
| Provision | Allocation of new resources |
| Bind | Create resources to allow applications to communicate with the provisioned resource |
| Unbind | Removal of resources created by the binding action |
| Deprovision | Removal of resources created by the provisioning action |
The key new Service Catalog resources are:
| Broker | Entity that provides ServiceClasses for use in the Service Catalog |
| ServiceClass | Represents an offering in the Service Catalog |
| Instance | Represents intent to provision a ServiceClass |
| Binding | Relationship between an application and an Instance and ServiceClass |
Checkout the OpenShift Commons Briefing on Service Catalog and Broker Deep Dive for additional details. Check back at blog.openshift.com for additional blogs on these topics as well.
NOTE: These are currently alpha APIs in the Kubernetes community. Naming and APIs may (and probably will) change.
New Experience
The OpenShift Web Console is a browser-based interface for OpenShift end users to define, deploy, and develop their applications. With OpenShift 3.6, a redesigned experience is in technology preview that blends a number of concepts into a seamless flow to allow you to focus on the task at hand. This includes improving the initial experience for defining applications and consuming services. You’ll see this with the new initial landing page in OpenShift:
This view combines your existing builder images with templates provided through the Service Catalog and the template broker, see below. Because it is backed by the Service Catalog additional Brokers can be registered to provide additional services and content to the platform.
Checkout the What’s new in OpenShift 3.6 - Enhanced Usability blog post for additional details.
Open Service Broker API
The Open Service Broker API (OSB API) defines the API standard on the interaction semantics between the Service Catalog and a Broker. This API is the successor to the Cloud Foundry Service Broker API. Due to this, there is an existing ecosystem provided along with the API. In July the working group completed the 2.12 version of the specification.
Service Broker: OpenShift Templates
This broker presents OpenShift templates as Service Catalog services, allowing you to provision an OpenShift template as a Service Catalog service, as well as bind to it. For example, this means you can now provision a database from a template and then bind your application to it. Your application will get database connectivity details automatically injected as part of the binding.
Service Broker: Ansible Playbook Bundles
The Ansible Service Broker (ASB) is an implementation of the OSB API that manages applications defined by Ansible Playbook Bundles (APBs).
APBs provide a new method for defining and distributing container applications in Kubernetes and OpenShift, consisting of a bundle of Ansible playbooks built into a container image with an Ansible runtime. APBs are a lightweight application definition and leverage Ansible to create a standard mechanism for automating deployments. Metadata defined in apb.yml spec file contains a list of required and optional parameters for use during deployment. The following shows an example directory structure of an APB:
example-apb/
├── Dockerfile
├── apb.yml
└── roles/
│ └── example-apb-openshift
│ ├── defaults
│ │ └── main.yml
│ └── tasks
│ └── main.yml
└── playbooks/
└── provision.yml
└── deprovision.ymlHere is an explanation of some of the files:
| apb.yml | Defines the specifics details about the application | required |
| provision.yml | Playbook called to handle installing application to the cluster | required |
| deprovision.yml | Playbook called to handle uninstalling | required |
| bind.yml | Playbook to grant access to another service to use this service. For example, generating credentials | optional |
| unbind.yml | Playbook to revoke access to this service | optional |
The required named playbooks correspond to methods defined by the OSB API. For example, when the ASB needs to provision an APB, it will execute the provision.yml. APBs allow you to do more than just deploy the standard resource manifest files with oc create; with APBs you can provision remote services through external APIs and consume the resulting service in your Kubernetes and OpenShift application.
Checkout the OpenShift Commons Briefing on Deploying Multi-Container Applications using Ansible Service Broker.
Service Broker: SDK
There may be cases where you want to expose your own services through a custom Broker. There is an evolving Open Service Broker SDK project to help those in this case. This project is still early on, perhaps even too soon to call it alpha. However, it is a great opportunity to get involved early to help flesh out the SDK based on your user cases.
Enabling and Limitations in 3.6
Enabling
If you are looking to just experiment with the Service Catalog and Brokers in an isolated environment, writing your own broker or developing/testing your own Ansible Playbook Bundles or OpenShift Temples, you can leverage the updated oc cluster up --service-catalog to launch an all-in-one instance of OpenShift with the UI and service catalog enabled. See Getting Started with the Ansible Service Broker for installing ASB with oc cluster up.
If you want to enable via the 3.6 installer, you can look here for details on opting-in for feature to enable it.
Limitations
As mentioned, the Service Catalog and Brokers are technology preview in OpenShift 3.6. You should NOT enable these features on a production cluster or a cluster that you plan on becoming a production cluster. The Template Service Broker needs to operate in an insecure manner in order to work in the technology preview, but this will be fixed in an upcoming release. You will not be able to upgrade a 3.6 cluster with Service Catalog enabled.
Categories
