crossplane-service-broker

README

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:

1. using make run (provide your own env variables)
2. using make kind-run (uses KIND to install a cluster in docker and provides its own kubeconfig in testbin/)
3. 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"
      },
      "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.