We have been big fans of CoreOS etcd since it first came out. A simple to use distributed key value store. Many of our own distributed systems built for customers have used etcd for coordination of components. Cloud Foundry itself has used Etcd for many years.
Whilst there is a wonderfully maintained etcd release for BOSH (thanks to the Cloud Foundry Foundation member companies for continuing to invest in etcd-release!), there has not been a service broker to share etcd with Cloud Foundry applications.
To fill this gap and to make etcd available to more developers, we’ve written etcd-cf-service-broker.
This is the first iteration, and as discussed in the v0.1.0 release notes, several things could change in future versions based on user feedback (and our own feedback as we use it).
The service broker has no additional state aside from the shared etcd cluster that it manages. It can be deployed to Cloud Foundry or any other way you’d like to deploy it.
Binding credentials
The format of the credentials from service broker bindings is important as it is what is expected by applications. Service brokers should not change their credentials schema between versions.
Nonetheless, this is v0.1.0 and it is possible that the concepts of authorisation (basic auth vs certificates), authorized paths and URIs may change based on people using the service broker and having revised opinions on what should be in credentials.
Currently the credentials schema looks like:
Bound applications/service keys will receive credentials that look similar to:
{
"credentials": {
"host": "http://23.159.100.202:4001",
"username": "user-8c0d5822-f806-11e6-84f6-a79e3c5fe739",
"password": "WVmH8Qr365",
"base_path": "/v2/keys/service_instances/92122d42-f806-11e6-bcb2-4b77b9de2108",
"uri": "http://user-8c0d5822-f806-11e6-84f6-a79e3c5fe739:[email protected]:4001/v2/keys/service_instances/92122d42-f806-11e6-bcb2-4b77b9de2108"
}
}
Testing
The project includes an integration test harness via delmo and docker-compose which launches a single etcd server, adds root authentication, runs the broker, and then runs a test script that goes thru a normal usage sequence: get catalog, provision service, get binding credentials, use credentials inside allocated path, fail to use credentials outside allocated/authorized path, delete binding and credentials no longer work, re-create binding and the password is different, delete the binding and delete the service and the stored data is no longer in etcd. A big shell script. Perhaps ugly; but it did the trick of enabling test driven development of the broker itself.
Feedback
Any feedback on the broker is appreciated and the Github Issues are an ideal initial place for proposals/bugs/feedback.
Spread the word
