Minibroker is deployed using a Helm chart. Ensure your SUSE Helm chart repository contains the most recent Minibroker chart:

tux > helm repo update

Use Helm to deploy Minibroker:

tux > kubectl create namespace minibroker
	     
tux > helm install minibroker suse/minibroker \
--namespace minibroker \
--set "deployServiceCatalog=false" \
--set "defaultNamespace=minibroker" \
--values minibroker-values.yaml

If you are using SUSE Enterprise Storage, you must copy the Ceph admin secret to the minibroker namespace:

tux > kubectl get secret ceph-secret-admin --output json
--namespace default | \
sed 's/"namespace": "default"/"namespace": "minibroker"/' | kubectl create
--filename -

Note

Platform users provisioning service instances will be able to set arbitrary parameters, which can be potentially dangerous, e.g. if setting a high number of replicas. To prevent this, it is possible to define override parameters per service in the according fields of the provisioning chart value. If defined, the user-defined parameters are dropped and the override parameters are used instead.

The below is an example values.yaml file where the provisioning chart value contains a series of override definitions for different services. When the override parameters (or other configurations) are defined in a values.yaml file, ensure the file is used by including --values FILE in the helm install command.

### Example configuration file
### minibroker-values.yaml

provisioning:
  mariadb:
    overrideParams:
      db:
        user: "dbuser"
        name: "default"
      replication:
        enabled: false
      metrics:
        enabled: false
      resources:
        limits:
          cpu: 500m
          memory: 512Mi
        requests:
          cpu: 200m
          memory: 256Mi
  postgresql:
    overrideParams:
      postgresqlUsername: "dbuser"
      postgresqlDatabase: "default"
      replication:
        enabled: false
      metrics:
        enabled: false
      resources:
        limits:
          cpu: 500m
          memory: 512Mi
        requests:
          cpu: 200m
          memory: 256Mi
  redis:
    overrideParams:
      cluster:
        enabled: false
      networkPolicy:
        enabled: false
      securityContext:
        enabled: true
      sentinel:
        enabled: false
      resources:
        limits:
          cpu: 500m
          memory: 512Mi
        requests:
          cpu: 200m
          memory: 256Mi
  rabbitmq:
    overrideParams:
      rabbitmq:
        username: "dbuser"
      replicas: 1
      networkPolicy:
        enabled: false
      ingress:
        enabled: false
      metrics:
        enabled: false
      forceBoot:
        enabled: false
      resources:
        limits:
          cpu: 500m
          memory: 512Mi
        requests:
          cpu: 200m
          memory: 256Mi
  mongodb:
    overrideParams:
      volumePermissions:
        enabled: false
      service:
        type: ClusterIP
      replicaSet:
        enabled: false
      ingress:
        enabled: false
      metrics:
        enabled: false
      resources:
        limits:
          cpu: 500m
          memory: 512Mi
        requests:
          cpu: 200m
          memory: 256Mi

The following tables list the services provided by Minibroker, along with the latest chart and application version combination known to work with Minibroker.

If your deployment uses Kubernetes 1.15 or earlier, use the following versions.

If your deployment uses Kubernetes 1.16 or later, use the following versions.

Monitor the deployment progress. Wait until all pods are in a ready state before proceeding:

tux > watch --color 'kubectl get pods --namespace minibroker'

Begin by logging into your Cloud Application Platform deployment. Select an organization and space to work with, creating them if needed. Be sure to replace example.com with the system_domain set in your kubecf-config-values.yaml.

tux > cf api --skip-ssl-validation https://api.example.com
 tux > cf login -u admin -p PASSWORD
 tux > cf create-org MY_ORG
 tux > cf create-space MY_SPACE -o MY_ORG
 tux > cf target -o MY_ORG -s MY_SPACE

Create the service broker. Note that Minibroker does not require authentication and the USERNAME and PASSWORD parameters act as dummy values to pass to the cf command. These parameters do not need to be customized for the Cloud Application Platform installation:

tux > cf create-service-broker minibroker USERNAME PASSWORD http://minibroker-minibroker.minibroker.svc.cluster.local

After the service broker is ready, it can be seen on your deployment:

tux > cf service-brokers
 Getting service brokers as admin...

 name               url
 minibroker         http://minibroker-minibroker.minibroker.svc.cluster.local

List the services and their associated plans the Minibroker has access to:

tux > cf service-access -b minibroker

Enable access to a service. Refer to the table in Section 22.1.1, “Deploy Minibroker” for service plans known to be working with Minibroker.

This example enables access to the Redis service:

tux > cf enable-service-access redis -b minibroker -p 5-0-5

Use cf marketplace to verify the service has been enabled:

tux > cf marketplace
 Getting services from marketplace in org org / space space as admin...
 OK

 service      plans     description
 redis        5-0-5     Helm Chart for redis

 TIP:  Use 'cf marketplace -s SERVICE' to view descriptions of individual plans of a given service.

Define your Application Security Group (ASG) rules in a JSON file. Using the defined rules, create an ASG and bind it to an organization and space:

tux > echo > redis.json '[{ "protocol": "tcp", "destination": "10.0.0.0/8", "ports": "6379", "description": "Allow Redis traffic" }]'
 tux > cf create-security-group redis_networking redis.json
 tux > cf bind-security-group redis_networking org space

Use following ports to define your ASG for the given service:

Create an instance of the Redis service. The cf marketplace or cf marketplace -s redis commands can be used to see the available plans for the service:

tux > cf create-service redis 5-0-5 redis-example-service

Monitor the progress of the pods and wait until all pods are in a ready state. The example below shows the additional redis pods with a randomly generated name that have been created in the minibroker namespace:

tux > watch --color 'kubectl get pods --namespace minibroker'
 NAME                                            READY     STATUS             RESTARTS   AGE
 alternating-frog-redis-master-0                 1/1       Running            2          1h
 alternating-frog-redis-slave-7f7444978d-z86nr   1/1       Running            0          1h
 minibroker-minibroker-5865f66bb8-6dxm7          2/2       Running            0          1h

Obtain the demo application from Github and use cf push with the --no-start flag to deploy the application without starting it:

tux > git clone https://github.com/scf-samples/cf-redis-example-app
 tux > cd cf-redis-example-app
 tux > cf push --no-start

Bind the service to your application and start the application:

tux > cf bind-service redis-example-app redis-example-service
 tux > cf start redis-example-app

When the application is ready, it can be tested by storing a value into the Redis service. Be sure to replace example.com with the system_domain set in your kubecf-config-values.yaml.

tux > export APP=redis-example-app.example.com
 tux > curl --request GET $APP/foo
 tux > curl --request PUT $APP/foo --data 'data=bar'
 tux > curl --request GET $APP/foo

The first GET will return key not present. After storing a value, it will return bar.