Page last updated:
See below for information about configuring Spring Cloud Services tile options and lifecycle errands.
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 Ops 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 apps 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. The broker will 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 app 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. The broker will allow the specified number of minutes for service instance backing apps to start.
By default, the Spring Cloud Services service broker assigns routes to service instances using the VMware Tanzu Application Service for VMs (TAS) application domain. To use a custom domain for service instance routes, you can specify the domain in the Spring Cloud Services tile settings.
Important: Your custom domain must be available to the
p-spring-cloud-services org. If you are installing Spring Cloud Services, you must manually create this org before configuring the custom domain in the Spring Cloud Services tile settings.
In the Service instances domain field, enter the desired domain. The broker will use this domain for creating routes for service instances.
By default, the Spring Cloud Services service broker stages service instance backing apps 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. The broker will use the selected buildpack to stage service instance backing apps.
By default, Spring Cloud Services checks the TAS 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. This setting does not disable SSL certificate validation for app instances running on TAS.
WARNING: Disabling Spring Cloud Services’ validation of the PAS SSL certificate is an extreme action that should not be taken unless absolutely necessary, and can cause unexpected behavior across your installation of Spring Cloud Services. Do not disable this validation unless you are completely certain that you must do so.
With the checkbox selected, Spring Cloud Services will not validate the TAS certificate as part of its installation process.
By default, the Spring Cloud Services service broker uses MySQL for VMware Tanzu for a MySQL database and RabbitMQ for VMware Tanzu for a message bus. You can configure alternate services in the Spring Cloud Services tile settings.
These settings should be configured only during the Spring Cloud Services tile installation process. If you have already completed the tile installation process, do not alter these settings.
WARNING: Configuring the service broker’s dependent services after installing the tile can cause corruption or loss of the broker’s service instance data.
In the Persistence store service and Persistence store service plan fields, enter the names of the service and service plan to use for the service broker’s MySQL database. In the Message bus service and Message bus service plan fields, enter the names of the service and service plan to use for the service broker’s message bus. Spring Cloud Services will use these services and service plans for its dependent service instances.
Note: The persistence store service must provide a MySQL database.
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: This feature is not available in TAS v2.4 or later. Before upgrading to vTAS 2.4 or later, turn off this option in the Spring Cloud Services tile configuration and apply your changes.
Important: To use CredHub with Spring Cloud Services, you must be using VMware Tanzu Application Service for VMs 2.0 or later, have configured the Runtime CredHub, and have at least one CredHub job instance configured in the PAS tile’s Resource Config settings tab.
With the checkbox selected, 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 in Ops Manager by visiting the Installation Dashboard, 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 always run (On) or to never run (Off).
Important: To ensure that your TAS foundation receives important updates to the tile, VMware 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 apps to TAS. 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.