This release is no longer maintained or used, and is retained for reference purposes only
This repo contains an broker application, responsible for communication between CloudFoundry and Kubernetes cluster, in order to create Marketplace Services on the Kubernetes existing side-to-side with TAP.
It requires go 1.6, grab it from here: https://storage.googleapis.com/golang/go1.6.linux-amd64.tar.gz
make run
to start locallymake push
to push to CFmake tests
to run unit testsPlease note that shell scripts are provided temporarly for convinience - they will be gone later on.
Demiurge app is required to be running (https://github.com/trustedanalytics/demiurge) and its credentials has to be known. Having this knowledge user provided service has to be added:
cf cups kubernetes-creator-credentials -p '{"username":"demiurge_username","password":"demiurge_password","url":"demiurge_URL"}'
e.g.:
cf cups kubernetes-creator-credentials -p '{"username":"admin","password":"admin","url":"http://demiurge.dev.example.com"}'
Upon start, broker scans it's catalog structure
(described below), in order to be able to return CF-requested /catalog data.
After that, it listens for 5 possible API calls:
In broker's directory there is an folder named catalog
. It has subdirectories per service
.
In each service
directory, there are two files and a directory per service plan
:
credentials-mappings.json - describes credentials
CF returns on service bindings:
Every service plan
directory contains:
replication controllers
JSON schema, which can contain $-prefixed values - those will be filled by the kubernetes-broker.service
JSON schema, which can contain $-prefixed values - those will be filled by the kubernetes-broker.*service accounts
JSON schema, which can contain $-prefixed values - those will be filled by the kubernetes-broker.At this point, please create new services based on the existing ones, as the schema is not stable.
Typical core labels are:
"labels": {
"org": "$org",
"space": "$space",
"catalog_service_id": "$catalog_service_id",
"catalog_plan_id": "$catalog_plan_id",
"service_id": "$service_id",
"idx_and_short_serviceid": "$idx_and_short_serviceid",
"managed_by": "TAP"
}
Vars like $random1 to $random9 are being filled with a short random text string.
Most of our providers works out-of-box, but few of them requires additional configuration. Some clustered services needs access to private or public image repository where builded images can be found.
[Images] (custom_images) can be build using simple docker command
docker build -t mysql56-cluster .
One has to build provided custom images and provide to broker informations how to connect to repository:
More info can be find on their catalogs:
You can set desired log level by setting system variable BROKER_LOG_LEVEL_
. Available levels are:
One can use own image to provide new service offering in catalog. For now there is no persistence for dynamic offering (all information are in memory of broker till it restarts). More information how to add such offerings can be found here
To run microservices on Kuberentes, following steps are required:
make docker_build_template_repository
make docker_build_container_broker
kubectl create -f app/template_repository/service.json
kubectl create -f app/template_repository/replication_controller.json
kubectl get pod
kubectl create -f app/container_broker/replication_controller.json