Warning: Pivotal Spring Cloud Services v1.5 is no longer supported because it has reached the End of General Support (EOGS) phase as defined by the Support Lifecycle Policy. To stay up to date with the latest software and security updates, upgrade to a supported version.
Page last updated:
See below for information about configuration options and capacity requirements of the Spring Cloud® Services tile.
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 Spring Cloud Services tile includes settings for various options. You can configure these by visiting the Installation Dashboard of Pivotal Cloud Foundry® Operations Manager, clicking the Spring Cloud Services tile, and then navigating to the Spring Cloud Services pane.
By default, the Spring Cloud Services broker will only provision up to 100 service instances. This service instance limit is also used to determine the memory quota for the org in which service instance backing applications are deployed; the org’s memory quota will be equal to 1.5G times the service instance limit. You can configure this limit in the Spring Cloud Services tile settings.
In the Service Instance Limit field, enter the new service instance limit. Click Save, return to the Installation Dashboard, and apply your changes. The broker now can provision up to as many service instances as you specified.
By default, the Spring Cloud Services service broker allows four (4) minutes for a service instance backing application to be staged and start. To use another timeout interval, you can specify a different number of minutes in the Spring Cloud Services tile settings.
In the App push timeout field, enter the desired number of minutes. Click Save, return to the Installation Dashboard, and apply the change. The broker will now allow the specified number of minutes for service instance backing applications to start.
By default, the Spring Cloud Services service broker stages service instance backing applications using the buildpack chosen by the platform’s buildpack detection; normally, this will be the highest-priority Java buildpack. To cause the broker to use a particular Java buildpack regardless of priority, you can set the name of the buildpack to use in the Spring Cloud Services tile settings.
In the Buildpack field, enter the name of the desired Java buildpack. Click Save, return to the Installation Dashboard, and apply your changes. The broker will now use the selected buildpack to stage service instance backing applications.
By default, Spring Cloud Services checks the Pivotal Application Service (PAS) or Elastic Runtime SSL certificate for the domains listed in Requirements. You can disable this validation by selecting the Do not validate that SSL certificates are properly configured checkbox.
Click Save and return to the Installation Dashboard, then apply your changes. Spring Cloud Services will not validate the Elastic Runtime certificate as part of its installation process.
Spring Cloud Services can store its service instances’ credentials in the Runtime CredHub. You can enable this behavior by selecting the Secure service instance credentials checkbox.
Important: To use this feature, you must be using PAS 2.0 or later and have configured the Runtime CredHub, with at least one job instance in the PAS tile’s Resource Config settings tab.
Click Save and return to the Installation Dashboard, then apply your changes. Spring Cloud Services will secure credentials for new service instances in the Runtime CredHub (credentials for previously-existing service instances will not be moved to CredHub).
The Spring Cloud Services tile includes four lifecycle errands. You can view these by visiting the Installation Dashboard of Pivotal Cloud Foundry® Operations Manager, clicking the Spring Cloud Services tile, and then navigating to the Errands pane.
Spring Cloud Services includes three post-deploy errands and one pre-delete errand. These errands can be individually set to run conditionally (When Changed), to always run (On), or to never run (Off).
Important: To ensure that your PCF installation receives important updates to the tile, Pivotal recommends that all Spring Cloud Services lifecycle errands be set to On.
In the post-deploy errands, Broker Deployer pushes the Spring Cloud Services service broker and worker applications to PCF. Broker Registrar registers the service broker with the Cloud Controller and makes its service plans available to all orgs. Smoke Tests runs several tests to ensure service availability and correct configuration. The pre-delete errand, Broker Deregistrar, deletes all orgs and spaces specific to Spring Cloud Services and deregisters the broker from the Cloud Controller.
Below are usage requirements of the applications backing a single service instance (SI) of each Spring Cloud Services service type.
|Service Type||Memory Limit / SI||Disk Limit / SI|
|Config Server||1 GB||1 GB|
|Service Registry||1 GB||1 GB|
|Circuit Breaker Dashboard||2 GB||2 GB|
Spring Cloud Services service types may also be backed by non-SCS service instances. For example, a Circuit Breaker Dashboard service instance uses a RabbitMQ for Pivotal Cloud Foundry service instance for communication between its two backing applications.