Job | Status |
---|---|
Unit | |
Conformance | |
Deploy | |
Dockerhub |
A simple service broker conforming to the Open Service Broker API specification that hosts a dashboard showing information on service instances and bindings created by any platform the broker is registered with.
Other fun features this broker provides include:
- Edit the broker catalog without redeploys to speed up testing
- History of recent requests and responses
- Ability to enable different error modes to test platform integrations
- Change the response mode on the fly (sync only/async only/async where possible)
- A range of configuration parameter schemas for provision service instance, update service instance and create service binding
- Asynchronous service instance provisions, updates and deletes
- Asynchronous service binding creates and deletes
- Fetching service instances and bindings
- Generic extensions for fetching the Health and Info for a service instance
The Open Service Broker API project allows developers, ISVs, and SaaS vendors a single, simple, and elegant way to deliver services to applications running within cloud native platforms such as Cloud Foundry, OpenShift, and Kubernetes. The project includes individuals from Fujitsu, Google, IBM, Pivotal, RedHat and SAP.
The latest version of overview-broker
can always be found on
Dockerhub. You can
pull and run the latest image with:
docker pull ismteam/overview-broker
docker run ismteam/overview-broker
git clone [email protected]:mattmcneeney/overview-broker.git
cd overview-broker
npm install
# Start overview-broker
npm start
# Or to run the tests
npm test
- To set the BasicAuth credentials, set the
BROKER_USERNAME
andBROKER_PASSWORD
environmental variables. Otherwise the defaults ofadmin
andpassword
will be used. - To expose a syslog drain service, set the
SYSLOG_DRAIN_URL
environmental variable to a url. - To expose a volume mount service, set the
EXPOSE_VOLUME_MOUNT_SERVICE
environmental variable totrue
. - To generate many plans with a range of configuration parameter schemas, set
the
ENABLE_EXAMPLE_SCHEMAS
environmental variable totrue
. - By default, all asynchronous operations take 1 second to complete. To override
this, set the
ASYNCHRONOUS_DELAY_IN_SECONDS
environmental variable to the number of seconds all operations should take. - To specify how long platforms should wait before timing out an asynchronous
operation, set the
MAXIMUM_POLLING_DURATION_IN_SECONDS
environmental variable. - To specify how long Platforms should wait in between polling the
/last_operation
endpoint for service instances or bindings, set thePOLLING_INTERVAL_IN_SECONDS
environmental variable to the number of seconds a platform should wait before trying again. - To change the name of the service(s) exposed by the service broker, set the
SERVICE_NAME
environmental variable. - To change the description of the service(s) exposed by the service broker,
set the
SERVICE_DESCRIPTION
environmental variable. - To set the response mode of the service broker (note that this can also be
changed via the broker dashboard), set the
RESPONSE_MODE
environmental variable to one of the available modes. - To set the error mode of the service broker (note that this can also be
changed via the broker dashboard), set the
ERROR_MODE
environmental variable to one of the available modes.
- First you will need to deploy the broker as an application:
cf push overview-broker -i 1 -m 256M -k 256M --random-route -b https://github.com/cloudfoundry/nodejs-buildpack
- You can also use an application manifest to deploy the broker as an
application:
wget https://raw.githubusercontent.com/mattmcneeney/overview-broker/master/examples/cloudfoundry/manifest.yaml cf push
- The overview broker dashboard should now be accessible:
open "https://$(cf app the-best-broker | awk '/routes:/{ print $2 }')/dashboard"
- To register the broker to a space (does not require admin credentials), run:
The basic auth credentials "admin" and "password" can be specified if needed (see Configuration).
cf create-service-broker --space-scoped overview-broker admin password <url-of-deployed-broker>
- The services and plans provided by this broker should now be available in the
marketplace:
cf marketplace
- Now for the exciting part... it's time to create a new service instance:
You can give your service a specific name in the dashboard by providing the
cf create-service overview-service small my-instance
name
configuration parameter:cf create-service overview-service small my-instance -c '{ "name": "My Service Instance" }'
- If you now head back to the dashboard, you should see your new service instance!
- To bind the service instance to your application, you will need to first push
an application to Cloud Foundry with
cf push
. You can then create a new binding with:cf bind-service <app-name> my-instance
- Deploy the broker and a load balancer that will be used to access it:
You can check this has succeeded by running
wget https://raw.githubusercontent.com/mattmcneeney/overview-broker/master/examples/kubernetes/overview-broker-app.yaml wget https://raw.githubusercontent.com/mattmcneeney/overview-broker/master/examples/kubernetes/overview-broker-service.yaml kubectl create -f overview-broker-app.yaml kubectl create -f overview-broker-service.yaml
kubectl get deployments
andkubectl get services
. - Once the load balancer is up and running, he overview broker dashboard should
be accessible:
open "http://$(kubectl get service overview-broker-service -o json | jq -r .status.loadBalancer.ingress[0].ip)/dashboard"
- To register the broker, you first need to install the Service Catalog. The instructions to do this can be found here. If service catalog fails to install due to permissions, you might want to look at this guide.
- You should now be able to register the service broker you deployed earlier
by creating a
clusterservicebrokers
custom resource:Note that if you changed the default basic auth credentials (see Configuration), then you will need to change the Secret defined above.BROKER_URL="http://$(kubectl get service overview-broker-service -o json | jq -r .status.loadBalancer.ingress[0].ip)" cat <<EOF | kubectl create -f - apiVersion: v1 kind: Secret metadata: name: overview-broker-secret namespace: default type: Opaque stringData: username: admin password: password EOF cat <<EOF | kubectl create -f - apiVersion: servicecatalog.k8s.io/v1beta1 kind: ClusterServiceBroker metadata: name: overview-broker namespace: default spec: url: ${BROKER_URL} authInfo: basic: secretRef: name: overview-broker-secret namespace: default EOF
- The services and plans provided by this broker should now be available:
kubectl get clusterserviceclasses kubectl get clusterserviceplans
- Now for the exciting part... it's time to create a new service instance:
cat <<EOF | kubectl create -f - apiVersion: servicecatalog.k8s.io/v1beta1 kind: ServiceInstance metadata: name: my-instance namespace: default spec: clusterServiceClassExternalName: overview-service clusterServicePlanExternalName: small EOF
- If you now head back to the dashboard, you should see your new service instance!
- Creating a service binding with service-catalog will result in a new Secret
being created which represents the information returned from the service
broker for the binding. To create a new service binding, you can run:
To see the contents of the service binding, you can get the associated secret with:
cat <<EOF | kubectl create -f - apiVersion: servicecatalog.k8s.io/v1beta1 kind: ServiceBinding metadata: name: my-instance-binding namespace: default spec: instanceRef: name: my-instance secretName: my-instance-secret EOF
Note that the data shown will be base64 encoded.kubectl get secret my-instance-secret -o yaml