A skeleton project for creating new service brokers that implement the Open Service Broker API. Our goal is eventually to make this project a full-featured SDK that handles the subtleties of implementing the API and allows broker authors to focus on the business logic of provisioning and binding to their services.
This is intended as a starting point for new broker implementations that will run inside a kubernetes cluster. The intent is for broker implementers to fork this repository and fill in their own broker specific logic/resource definitions into the skeleton that is provided.
We are specifically most interested in brokers that will integrate with the Kubernetes Service Catalog.
This project is currently in the pre-alpha phase of its existence. The current usage pattern for this project is to fork/clone it and modify it in order to implement your own broker.
Our next step is to take existing brokers and reimplement them using this project. This will allow us to find pitfalls and bugs as well as determining what the lifecycle of a project based on this SDK should look like.
$ make images
$ # start up an openshift/kube cluster
$ # have admin credentials
$ cd install
$ cd <kubernetes|openshift>
$ ./install.sh
$ cd ../../test-scripts
$ ./provision.sh
$ ./bind.sh
$ ./unbind.sh
$ ./deprovision.sh
- Fork the repository
- Clone your fork
- Run
hack/fork-rename.sh <your github org name> <your github repo name>- this will rename all the package imports to match your project
In writing your own Broker implementation, you will primarily be concerned with the following 3 areas:
- Broker API implementation - pkg/openservicebroker/operations
- Broker State Resources - pkg/apis/broker, pkg/registry/broker/serviceinstance
- Provision Controller implementation - pkg/controller
The main logic of what your broker will do when provision/deprovision/bind/unbind/catalog/lastoperation requests
are made is implemented in the pkg/openservicebroker/operations package. These functions
are automatically bound to the appropriate API endpoints by the Broker SDK and will be invoked
by the Service Catalog.
You can customize this logic to implement whatever actions you want to take in response to requests from the Service Catalog.
The provided implementation executes the following flow:
-
On provision, a
ServiceInstanceresource is create. This is a Kubernetes resource that is provided by the Broker SDK itself and stored in a local etcd instance that will be running in the same pod as the Broker. A controller(see next section) will observe the new ServiceInstance and process it to complete the provision operation, and add the Ready condition -
On a lastoperation request, the
ServiceInstanceobject conditions will be checked to see if it is Pending, Ready, or Failed. -
On bind, the broker confirms the presence of a
ServiceInstancewith a matching uuid, and if found, returns some credential information associated with the ServiceInstance. -
On unbind, the broker confirms the presence of a
ServiceInstancewith a matching uuid and based the success/failure response on the existence of that object. -
On deprovision, the broker deletes the
ServiceInstanceobject. The controller could, but does not currently, take some additional action upon receiving the deletion event. -
On a catalog request, the broker returns a valid, but hardcoded, list of catalog entries.
The Broker SDK defines its own API group resource which is served by the API server which is part of the Broker process.
This API group defines one resource type, a ServiceInstance. This resource is used to store the state of provision requests.
Defining additional resources or customization to this resource are expected during usage of the SDK. Since the Broker calls
itself to access these resources, no special permissions should need to be granted to users to access the resources, they
can be considered internal only. The resources are backed by etcd storage in a local etcd process running in a second container
with in the Broker SDK pod that is defined. Real world implementations will need to take into account the backup/restore
strategies for this data.
The Broker SDK provides a single controller which watches for ServiceInstance objects. This allows it to implement an
asynchronous provision flow in which the provision call returns immediately after defining a new ServiceInstance (
effectively a service provision request). The controller is free to implement any business logic necessary to handle
the request, such as creating backend resources needed by the service instance being provisioned. Once the service
instance is prepared, the controller updates the ServiceInstance object condition to indicate it is ready. This
information is used by the lastoperation API when checking on the state of a provision request.
On provision, the current controller implementation simply updates the ServiceInstance to indicate it is ready.
On deletion, the controller simply logs the event but a real Broker would be expected to cleanup the provisioned resources
here.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent