Red Hat SummitRed Hat blog
With the release of Red Hat OpenShift Container Platform 3.7, Service Catalog and Brokers graduates out of Technology Preview. This is an incredible step forward to enable easy to use service consumption and publication on Red Hat’s Enterprise Kubernetes product: OpenShift.
Why Service Catalog?
If you haven’t heard the motivation behind the service catalog, it is about removing manual error-prone processes that can occur when a service consumer looks to acquire a service from a provider.
The Pieces
In order to facilitate self-service and automated processes, we need a place for service consumers to find and acquire services. We also need a place for various service providers to list their services to these consumers. This place is the Service Catalog.
Next, we need a way for the Service Catalog to facilitate getting details about services offered, the ordering of services, provisioning instances of these services, and finally connecting their application to this service. This is the role of the Service Brokers.
Like details? You need to check out Paul Morie’s (Red Hat Principal Software Engineer, Kubernetes SIG Service Catalog co-lead) various OpenShift Commons Briefings on OpenShift 3.7 Service Catalog Deep Dive and Kubernetes Service Catalog 0.1.0, as well as PodCTL Podcast: Service Catalog all the Things!.
Brokers, Brokers, Brokers
As you could easily figure out, a Service Catalog isn’t very interesting if there is no content. One of the roles of the Service Broker is to provide the interesting content and interacting with it. The ease of use and the openness of the API the Service Catalog uses to interact with the Service Broker is extremely important.
In comes the Open Service Broker API (OSB API), where the working group completed the 2.13 version of the specification in September.
With the release of OpenShift Container Platform 3.7, comes a number of ready to use Service Brokers. Also be sure to check back for more announcements around additional Service Brokers coming available soon!
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).
Service Broker: OpenShift Templates
The OpenShift Template Service Broker allows 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.
An Evolved Experience
In OpenShift Container Platform 3.6, you could enable an alternative experience for the OpenShift’s Web Console initial landing page. In 3.7 we’ve further improved this experience and now have it on by default for all to enjoy! Influenced by the Service Catalog, we designed the new experience around bringing the services to the user. This experience does more than just focus on helping users get started, it looks at streamlining for common tasks.
Not only do we provide a “Guided Tour” to help you navigate and understand the various parts of the page, there is getting started material, recently used services, and the ability to easily filter/search for what you need.
Once you quickly get what you need, you can then easily “order” your service which may require a step to either build or deploy. Then you’ll be guided on how to bind (connect) your application to the desired service.
What’s Next?
We’ll focus on continuing to improve the overall experience, especially focusing on automatically injecting binding results into the connection application. Currently, all Service Brokers and their services are exposed at a cluster level, we’ll look to be able to restrict access to appropriate groups of users. We’ll look to provide additional Service Brokers and also additional services, as well as plans, to existing Service Brokers.
