Crossplane Service Broker
Open Service Broker API which provisions Redis and MariaDB instances via crossplane.
Documentation
Most of the explanation on how this all works together currently lives in the VSHN Knowledgebase.
Contributing
You'll need:
- A running kubernetes cluster (minishift, minikube, k3s, ... you name it) with crossplane installed
- kubectl and kustomize
- Go development environment
- Your favorite IDE (with a Go plugin)
- docker
- make
These are the most common make targets: build, test, docker-build, run.
Folder structure overview
.
├── cmd
│ └── crossplane-service-broker # main file
├── deploy
│ └── base # deployment files
├── docs # antora docs
├── e2e # e2e testing files
├── pkg
│ ├── api # exposed HTTP API server
│ ├── brokerapi # service broker implementation
│ ├── config # app config
│ ├── crossplane # crossplane service layer
│ ├── integration # utilities for integration tests
│ └── reqcontext # request context mapping
└── testdata # integration testing files
Run the service broker
You can run the operator in different ways:
- using
make run(provide your own env variables) - using
make kind-run(uses KIND to install a cluster in docker and provides its own kubeconfig intestbin/) - using a configuration of your favorite IDE (see below for VSCode example)
Example VSCode run configuration:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Launch",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${workspaceFolder}/cmd/crossplane-service-broker/main.go",
"env": {
"KUBECONFIG": "path/to/kubeconfig",
"OSB_USERNAME": "test",
"OSB_PASSWORD": "TEST",
"OSB_SERVICE_IDS": "PROVIDE-SERVICE-UUIDS-HERE",
"OSB_NAMESPACE": "test",
"OSB_PLAN_UPDATE_SIZE_RULES": "xsmall>small|xsmall>medium|small>medium"
},
"args": []
}
]
}
Run integration tests
"Integration" testing is done using envtest and crossplane's integration test helper.
make integration-test
Example VSCode run configuration (to be able to debug things):
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Integration tests",
"type": "go",
"request": "launch",
"mode": "test",
"program": "${workspaceFolder}/pkg/brokerapi",
"env": {
"KUBEBUILDER_ASSETS": "../../testdata/bin",
"DEBUG": "true" // optional
},
"args": [],
"buildFlags": "-tags=integration"
}
]
}
Run E2E tests
The e2e tests currently only test if the deployment works. They do not represent a real e2e test as of now but are meant as a base to build upon.
You need node and npm to run the tests, as it runs with DETIK.
To run e2e tests for newer K8s versions run
make e2e-test
To remove the local KIND cluster and other resources, run
make clean
Integration tests
The integration tests aren't very clever yet and will need some improvements to catch issues. They set the boundary at Kubernetes and avoid therefore the need to have a working crossplane installation with all the custom resources necessary set up.
This means that certain kinds of bugs can't be catched (interaction between crossplane provisioner and this code).
All integration tests are currently within the brokerapi package. envtest is used
to setup a Kubernetes API server, and an etcd instance. Public CRDs from crossplane are being downloaded on first run, while
the CRDs for this service broker are manually copied in and live within testdata/crds/*.syn.tools.yaml.
If tests for CRDs within the syn.tools API group are written, ensure the corresponding CRD definition is within the aforementioned directory.