Here you will find information about Spring Cloud Services tile options, resource configuration, and lifecycle errands.
Note Tanzu Operations 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 (SCS) tile includes a number of settings for the service broker. You can configure these by visiting the Installation Dashboard of Ops Manager, clicking the Spring Cloud Services tile, and then navigating to the SCS Service Broker pane.
By default, the Config Server and Service Registry services are made available globally (i.e. to all orgs). You can configure service availability in the Spring Cloud Services tile settings, under Config Server access and Service Registry access.
For each service, select Global to make the service available to all orgs, or select None to make the service unavailable to all orgs.
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, under Java Buildpack.
Enter the name of the desired Java buildpack. The broker will use the selected buildpack to stage service instance backing apps.
By default, the Spring Cloud Services service broker will wait 30 minutes before considering a service instance operation to have failed. You can specify a different timeout interval in the Spring Cloud Services tile settings, under Status change timeout.
Enter the desired number of minutes. The broker will allow the specified number of minutes for service instance operations to complete.
When running upgrade-all-instances errand, by default, the Spring Cloud Services service broker will upgrade 5 service instances concurrently. You can specify a different number in the Spring Cloud Services tile settings, under Concurrent Service Instance Upgrade.
Enter the desired number. The broker will use the specified number to upgrade service instances, concurrently, during upgrade-all-instances errand.
By default, the Spring Cloud Services service broker assigns routes to service instances using the VMware Tanzu Application Service for VMs (TAS for VMs) application domain. You can specify a custom domain for service instance routes in the Spring Cloud Services tile settings, under Service instances domain.
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.
Enter the desired domain. The broker will use this domain to create routes for service instances.
By default, the use of service keys is deactivated for service instances. To allow the use of service keys on service instances, select Enable off platform service key access.
The Spring Cloud Services tile includes two co-located 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 one 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.
The register-brokers errand registers the Spring Cloud Services service broker, and the broker for the Config Server's mirror service, with the Cloud Controller, and makes all Spring Cloud Services service plans available to all orgs. The destroy-brokers errand deletes all orgs and spaces specific to Spring Cloud Services and deregisters the Spring Cloud Services broker and mirror service broker from the Cloud Controller.
The upgrade-all-instances errand attempts to update all SCS service instances to the latest version. A service instance will not be upgraded if:
- There is a current operation in progress
- The most recent operation has failed
- The service instance cannot be found for whatever reason
An upgrade will be considered failed after a time configured by Status Change Timeout which defaults to 30 minutes. If a service instance upgrade fails, errand exits with an error and does not continue the upgrade of the remaining service instances.
After the errand completes, any service instance that was skipped must have the upgrade reattempted once its most recent operation is in a successful state. Additionally, depending on available resources the maximum number of concurrent upgrades can configured by the Concurrent Service Instance Upgrade option which defaults to 5.
To upgrade a single instance with cf CLI use the following command:
$ cf update-service <SERVICE INSTANCE NAME> -c '{"upgrade": true}'
To configure system logging for Spring Cloud Services, visit the Installation Dashboard, click the Spring Cloud Services tile, and then navigate to the Syslog pane.
For information about system logging in TAS for VMs, see Configuring Logging in TAS for VMs.
The Spring Cloud Services Config Server relies on a "mirror service" to make mirrors of Git repositories used by Config Server service instances. You can configure the size of the persistent disk used to store these Git mirrors. In the Spring Cloud Services tile settings, navigate to the Resource Config pane.
For the spring-cloud-services job, select the desired disk size value from the dropdown under Persistent Disk Type. The default value is 10 GB. Consider setting a size equal to the disk space required to mirror all Git repositories potentially used by Config Server service instances, with some additional disk space.