Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Cloud Application Platform 2.1.1

22 Service Brokers

The Open Service Broker API provides (OSBAPI) your SUSE Cloud Application Platform applications with access to external dependencies and platform-level capabilities, such as databases, filesystems, external repositories, and messaging systems. These resources are called services. Services are created, used, and deleted as needed, and provisioned on demand. This chapter focuses on Minibroker but there are others.

Use the following guideline to determine which service broker is most suitable for your situation.

22.1 Provisioning Services with Minibroker

Minibroker is an OSBAPI compliant broker created by members of the Microsoft Azure team. It provides a simple method to provision service brokers on Kubernetes clusters.

Important
Important: Minibroker Upstream Services

The services deployed by Minibroker are sourced from the stable upstream charts repository, see https://github.com/helm/charts/tree/master/stable, and maintained by contributors to the Helm project. Though SUSE supports Minibroker itself, it does not support the service charts it deploys. Operators should inspect the charts and images exposed by the service plans before deciding to use them in a production environment.

22.1.1 Deploy Minibroker

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

    tux > helm repo update
  2. 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
    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.

    ServiceVersionappVersion
    MariaDB4.3.010.1.34
    MongoDB5.3.34.0.6
    PostgreSQL6.2.111.5.0
    Redis3.7.24.0.10

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

    ServiceVersionappVersion
    MariaDB7.0.010.3.18
    MongoDB7.2.94.0.12
    PostgreSQL7.0.011.5.0
    Redis9.1.125.0.5
  3. Monitor the deployment progress. Wait until all pods are in a ready state before proceeding:

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

22.1.2 Setting Up the Environment for Minibroker Usage

  1. 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
  2. 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
  3. List the services and their associated plans the Minibroker has access to:

    tux > cf service-access -b minibroker
  4. 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.
  5. 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:

    ServicePort
    MariaDB3306
    MongoDB27017
    PostgreSQL5432
    Redis6379
  6. 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

22.1.3 Using Minibroker with Applications

This section demonstrates how to use Minibroker services with your applications. The example below uses the Redis service instance created in the previous section.

  1. 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
  2. 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
  3. 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.

Important
Important: Database Names for PostgreSQL and MariaDB Instances

By default, Minibroker creates PostgreSQL and MariaDB server instances without a named database. A named database is required for normal usage with these and will need to be added during the cf create-service step using the -c flag. To find out the exact parameter to be used, reference the values.yaml file in the upstream Helm charts at https://github.com/helm/charts located in the stable directory.

Print this page