The Service Broker and Instances

See below for information about Spring Cloud® Data Flow’s deployment model and other information which may be useful in administering Data Flow service instances or deployed applications.

Note: Ops Manager administrators can use Role-Based Access Control (RBAC) to manage which operators can make deployment changes, view credentials, and manage user roles in Ops Manager. Therefore, your role permissions might not allow you to perform every procedure in this operator guide. For more information about roles in Ops Manager, see Understand Roles in Ops Manager.

The Service Broker

Spring Cloud Data Flow provides a Spring Cloud Data Flow server as a Managed Service on Pivotal Cloud Foundry (PCF). It uses Cloud Foundry’s Service Broker API to manage this service. See below for information about Spring Cloud Data Flow’s broker implementation.

The Spring Cloud Data Flow service broker’s functionality is contained in the following Spring Boot application instance, which is deployed in the system org to the p-dataflow space.

  • p-dataflow-[version]: Implements the Service Broker API to act on provision, deprovision, bind, and unbind requests.

The broker relies on the MySQL for PCF product for the following service instance.

  • p-dataflow-db: A MySQL database used as a backing store for the service broker.

Note: You can configure an alternate relational database service for the broker to use. See the Configure Broker Database Service and Plan section of the Tile Configuration topic.

Service Broker Upgrades

The Spring Cloud Data Flow product upgrade process checks before redeploying the service broker to see whether the product’s version has changed. If the version has not changed, the upgrade process will continue without redeploying the service broker.

The service broker application is deployed using a blue-green deployment strategy. During an upgrade of the service broker, the broker will continue processing requests to provision, deprovision, bind, and unbind service instances, without downtime.

Access Via Apps Manager

To view the broker application in Pivotal Cloud Foundry® Apps Manager, log into Apps Manager as an admin user and select the system org.

Viewing system Org

The application is deployed in the p-dataflow space.

Viewing p-dataflow Space

Get Broker Build Information

The Spring Cloud Data Flow broker provides build information using the Spring Boot Actuator info endpoint, which is mapped to /info. You can access this endpoint by appending /info to the path of the Spring Cloud Data Flow broker.

If the Spring Cloud Data Flow service broker application is located at the following URL:

https://p-dataflow.apps.example.com

then you can access the info endpoint by visiting:

https://p-dataflow.apps.example.com/info

The service broker returns a JSON response, as in the following example.

{
    "git": {
        "commit": {
            "time": 1549665522000,
            "id": "03a54af"
        },
        "branch": "03a54af8030a977f94c0ff0b4376a79a3317668c"
    },
        "build": {
            "version": "1.3.2",
            "artifact": "scdf-for-pcf-service-broker",
            "name": "scdf-for-pcf-service-broker",
            "group": "io.pivotal.springcloud.dataflow",
            "time": 1549901709000
    }
}

The response contains information about the build of the service broker application, including the Maven project coordinates and build time. It also contains information about the Git repository for Spring Cloud Data Flow for PCF at build time.

Note: Fields such as those for Git repository information are for diagnostic purposes and intended to provide Pivotal Support with information to help in troubleshooting.

Service Instances

See the following sections for information about service instances deployed by the Spring Cloud Data Flow for PCF service broker.

Service Instance Architecture

Product Architecture

For each Spring Cloud Data Flow service instance created, the service broker provisions the following resources, all within the space from which the service instance was created (“the user space”) unless noted otherwise.

  • A new space within the p-dataflow org, named using the service instance GUID and containing:
    • A Data Flow server application.
    • A Data Flow metrics application.
    • A Spring Cloud Skipper package management application.
    • A relational database service, bound to the Data Flow server application.

      Note: This relational database service is a “p.mysql” service instance by default. You can configure an alternate relational database when you create the service instance.

    • A relational database service, bound to the Skipper package management application.
    • A messaging data service, bound to the Data Flow metrics application.

      Note: This messaging data service is a “p-rabbitmq” service instance by default. You can configure an alternate messaging service when you create the service instance.

    • A Redis database service, bound to the Data Flow server application.

      Note: This Redis database service is a “p-redis” service instance by default. You can configure an alternate Redis database when you create the service instance.

  • The following resources are created in the originating user space where the service instance command was targeted at:
    • A “p-dataflow” service instance.
    • A “p-dataflow” relational database service instance (providing access to the relational database service created in the service instance’s space within the p-dataflow org).
    • A “p-dataflow” messaging service instance (providing access to the messaging data service created in the service instance’s space within the p-dataflow org).
    • A “p-dataflow” analytics service instance (providing access to the analytics service created in the service instance’s space within the p-dataflow org).

Set a Domain for Service Instance Backing Apps

When deploying a backing app for a Data Flow service instance, the Spring Cloud Data Flow service broker uses the following strategy to select a domain for the app:

  1. The broker looks for a private domain shared with the p-dataflow org. If it finds one or more, the broker uses the first for the app.
  2. If the broker finds no private domain shared with the p-dataflow org, it looks for a shared domain. If it finds one or more, the broker uses the first for the app.

To cause the service broker to use a particular domain for service instance backing apps, configure the domain as a private domain and share it with the p-dataflow org. This will not affect the choice of domain for apps deployed by a Data Flow service instance.

Capacity Requirements

Below are the usage requirements of the Spring Cloud Data Flow service broker.

Application Memory Allocated Disk Allocation
Service Broker 2 GB 1 GB

The service broker is bound to a relational database service instance, which stores data relating to the broker’s service instances. The relational database service to use is configurable, as described in The Service Broker section above.

Below are the usage requirements of the Data Flow server and metrics applications that back each Spring Cloud Data Flow service instance.

Backing Application Memory Allocation / App Instance Disk Allocation / App Instance
Data Flow Server 2 GB 2 GB
Data Flow Metrics 1 GB 1 GB
Spring Cloud Skipper 1 GB 2 GB

Spring Cloud Data Flow service instances are also backed by instances of other PCF services. These are either services from PCF data service products or custom services provided to a Data Flow service instance at create time. These data services include a relational database service, a messaging service, and an analytics database service instance for each Data Flow service instance created. The Skipper backing application uses a MySQL database service for its backing store.