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

18 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.

18.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.

18.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 "defaultNamespace=minibroker"

    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'

18.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:

    tux > cf api --skip-ssl-validation https://api.example.com
     tux > cf login -u admin -p password
     tux > cf create-org org
     tux > cf create-space space -o org
     tux > cf target -o org -s 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 18.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 4-0-10

    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        4-0-10    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 4-0-10 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

18.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:

    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. For example:

tux > cf create-service postgresql 9-6-2 djangocms-db -c '{"postgresDatabase":"mydjango"}'
 tux > cf create-service mariadb 10-1-34 my-db  -c '{"mariadbDatabase":"mydb"}'

Other options can be set too, but vary by service type.

18.1.4 Upgrading SUSE Cloud Application Platform When Using Minibroker

If you are upgrading SUSE Cloud Application Platform to 1.5.2 and already use Minibroker to connect to external databases and are using Kubernetes 1.16 or higher, which is the case with SUSE CaaS Platform 4.1, you will need to update the database version to a compatible version and migrate your data over via the database’s suggested mechanism. This may require a database export/import.

Print this page