When deploying applications in a Kubernetes cluster, certain types of services are commonly required. Many applications require a database, a storage service, a message broker, identity management, and so on. You have enough work on your hands containerizing your own application. Wouldn’t it be handy if those other services were ready and available for use inside the cluster?
The Service Catalog
Don’t get stuck deploying and managing those other services yourself; let the Service Catalog do it for you. The Kubernetes Service Catalog README[1] states:
“The end-goal of the service-catalog project is to provide a way for Kubernetes users to consume services from brokers and easily configure their applications to use those services, without needing detailed knowledge about how those services are created or managed.”
Anyone can make a broker that advertises one or more services to the Service Catalog by implementing the Open Service Broker API[2]. But today we are looking at the Automation Broker[3], which enables you to easily make your application or service deployable from the Service Catalog.
The Service Bundle
At a basic level, all you need to do is provide the Automation Broker with a specially crafted container that knows how to provision and de-provision your service. We call this container a Service Bundle. Inside this container, you employ any means necessary to provision your service, but most examples so far utilize Ansible[4].
Writing an Ansible role to create resources in a cluster feels very familiar if you have ever created a Kubernetes resource directly from YAML. Using a general automation tool such as Ansible means you are free to integrate with resources both inside and outside the cluster. For example, your Service Bundle may