MindSphere Managed Backing Services

This section gives an overview of the included Backing Services. Each instance of a Backing Service runs on a dedicated virtual machine. These virtual machines and services are operated by MindSphere.

Available Backing Services

The following Backing Services are currently included:

Backing Service	Description	Plan
MongoDB	MongoDB is a document data base that stores data in flexible, JSON-like documents, meaning fields can vary from document to document and data structure can be changed over time	mongodb-xs and mongodb-m
PostgreSQL	PostgreSQL is a powerful, open source object-relational database system.	postgresql-xs and postgresql-m
Redis	Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker.	redis-xs and redis-m
RabbitMQ	RabbitMQ is the most widely deployed open source message broker.	rabbitmq-xs and rabbitmq-m
Elasticsearch	Elasticsearch is a distributed, RESTful search and analytics engine capable of solving a growing number of use cases. As the heart of the Elastic Stack, it centrally stores your data so you can discover the expected and uncover the unexpected.	elasticsearch-xs and elasticsearch-m
LogMe	LogMe allows to provision Elasticsearch, Logstash and Kibana, i.e. the ELK-stack. Simply bind your Cloud Foundry app to LogMe and it will automatically start collecting metrics and syslogs from your apps and services.	logme-xs and logme-m

Service Plans

All service plans (*-xs and *-m) are enabled for every Org. Those plans are all marked as paid plans as you can buy additional instances of those. Depending on your offering a certain amount of concurrent instances is included. The following table lists those for the MindAccess Developer Plan:

Offering	Concurrent instances included
Developer Plan S	2 XS instances
Developer Plan M	4 XS instances
Developer Plan L	6 XS instances

You can buy additional service instances in different sizes via the MindSphere Store. Therefore, the Cloud Foundry quota of your Org does not reflect allowed number of concurrent service instances.

Update to a larger Service Plan

Upgrade the service plan using the following command:

cf update-service <serviceName> -p <largerPlanName>

Disk Alerts

Every service instance is monitored by a Parachute component to evaluate the ephemeral and persistent disk usage. If a disk usage reaches the configured threshold Parachute stops all of this instance's processes and writes a message into the log directory:

Limit reached for: <persistent/ephemeral> disk

Restart Stopped Instances

The disk usage threshold for service instances is set to 80% by default. When restarting a stopped service instance, the threshold can be configured using the max_disk_threshold parameter. It accepts integer values between 0 and 100. The following sample shows how to restart a service instance with a threshold of 90%:

cf update-service <serviceName> -c '{"max_disk_threshold": "90"}'

Restarting the service instance takes a few minutes.

Attention

This is only a temporary solution. The service instance is stopped when the threshold is reached again. For a long-term solution, the service instance must be updated to a larger plan size if available.

Sharing Service Instances

Sharing a service instance between spaces allows apps in different spaces to use the same instance of a MindSphere managed backing service. This eliminates the need to use service keys and user-provided services to bind apps to the same service instance.

Refer to the Cloud Foundry documentation about sharing instances for further details.

Features

• Service instances can be shared among multiple spaces within one Cloud Foundry org.
• Sharing service instances among spaces requires the Space Developer role in these spaces.
• Service instances can be bound or unbound in spaces it is shared with, but cannot updated, renamed or deleted.
• Configuration parameters used for provisioning or updating the service instance can be read from all spaces the instance is shared with.
• Sharing a service instance to another space does not decrease the remaining service count quota of your org.
• Shared service instances only count as one instance in the service count quota of your org.

Example scenario

Consider two development teams who deployed apps in their own spaces. Their apps shall communicate using a messaging queue.

1. The development team in space A creates a RabbitMQ service instance, binds it to their app, and shares the service instance with space B.
2. The development team in space B binds their app to the same service instance and the apps can begin to communicate.

Refer to the How Tos for instructions.

Backing Service Dashboard API

All backing services (except LogMe) provide an API for their service dashboard. With this API you can:

• List backups and restores
• Create backups
• Restore backups

Accessing the API

For Authentication and Authorization, you can use your WebKey user or create CloudFoundry Service Credentials in MindSphere and use this user.

Note

Your user needs SpaceDeveloper role for the space where your service is located.

Get bearer token with CF CLI

The following description shows how to get the bearer token for CloudFoundry Service Credentials created in MindSphere, using the CF CLI.

cf api https://api.cf.eu1.mindsphere.io
cf auth ${service_credentials_user} ${service_credentials_password}
oauth_token=$(cf oauth-token)
bearer_token=$(echo ${oauth_token} | grep bearer)

Get bearer token using curl

The following description shows how to get the bearer token for CloudFoundry Service Credentials created in MindSphere, using curl.

login_res=$(curl -XPOST -H "Application/json" -u "cf:" --data "username=${service_credentials_user}&password=${service_credentials_password}&client_id=cf&grant_type=password&response_type=token" https://login.cf.eu1.mindsphere.io/oauth/token)
bearer_token="bearer $(echo ${login_res} | jq '.access_token' | tr -d \")"

Using the API

For using the API, you need the service dashboard URL. Get the dashboard URL with cf service {instance_name}, e.g.:

$cf service my-postgresql

Service instance: my-postgresql
Service: postgresql
Bound apps:
Tags:
Plan: postgresql-xs
Description: This is a service creating and managing dedicated PostgreSQL service instances and clusters, powered by the anynines Service Framework
Documentation url:
Dashboard: https://postgresql-dashboard.aws.ie.apps.eu1.mindsphere.io/service-instances/ca16f111-5073-40b7-973a-156c75dd3028

Last Operation
Status: update succeeded
Message:
Started: 2017-10-26T08:28:38Z
Updated: 2017-10-26T08:28:38Z

List Backups and Restores

Lists all available backups and restores that have been applied.

curl --cookie test.cookie --cookie-jar test.cookie --location --insecure --header "Authorization: ${bearer_token}" "${dashboard_url}/backups"

Response

Note

The response description contains only the relevant fields.

Status Code	Description
200 OK	If the request has been processed successfully. The response body is below.

Body

For success responses, the following fields are defined:

Response Field	Type	Description
instance_id	string	The internal ID of the service instance. This ID is needed for restoring a backup.
backups	array of Backup Objects	Schema of backup objects defined below. The array may be empty.
restores	array of Restore Objects	Schema of restore objects defined below. The array may be empty.

Backup Object

Response Field	Type	Description
id	integer	The internal ID of the backup. This ID is needed for restoring a backup.
backup_agent_task	Backup Agent Task object	Schema of backup agent task object defined below.

Restore Object

Response Field	Type	Description
backup_agent_tasks	array of Backup Agent Task objects	Schema of backup agent task objects defined below.

Backup Agent Task Object

Response Field	Type	Description
status	string	The status of the task. The following stati exist: queued, running, done, failed, deleted.
created_at	datetime	The date the task was created.
updated_at	datetime	The date on which the status of the task was last changed.

Create Backup

Trigger the creation of a backup of the service instance.

curl --cookie test.cookie --cookie-jar test.cookie --location --insecure --header "Authorization: ${bearer_token}" -X POST "${dashboard_url}/backups"

Response

Status Code	Description
201 Created	If the backup has been scheduled.

Body

For success responses, the following fields are defined:

Response Field	Type	Description
id	integer	The ID of the backup.
message	string	Backup creation status message.

Restore Backup

Trigger the restore of a backup of the service instance.

Request Body	Type	Description
instance_id	integer	The internal ID of the service instance.
backup_id	integer	The internal ID of the backup.

You can get the IDs by listing all Backups and Restores.

curl --cookie test.cookie --cookie-jar test.cookie --location --insecure --header "Authorization: ${bearer_token}" -X POST "${dashboard_url}/backups/restore" --data "instance_id=${instance_id}" --data "backup_id=${backup_id}"

Response

Status Code	Description
200 OK	If the restore has been scheduled.
412 Precondition Failed	Either instance_id or backup_id does not exist or match.

Body

For success responses, the following fields are defined:

Response Field	Type	Description
restore_id	integer	The internal ID of the restore.

For error responses, the following fields are defined:

Response Field	Type	Description
msg	string	Restore failure message.

Backing Service Documentation

• Elasticsearch
• LogMe
• MongoDB
• PostgreSQL
• RabbitMQ
• Redis

Any questions left?

Ask the community

---

Except where otherwise noted, content on this site is licensed under the MindSphere Development License Agreement.