Managing Spring Cloud Services service instances

Here you will find information about managing Service Registry service instances using the Cloud Foundry Command Line Interface (cf CLI). You can also manage Service Registry service instances using VMware Tanzu Application Service for VMs Apps Manager.

Available parameters

General parameters accepted for the Service Registry, passed to the cf create-service and cf update-service commands using the -c flag, are listed below.

Parameter	Function	Example
`count`	The number of nodes to provision: 1 by default, more for running in high-availability mode	`'{"count": 3}'`
`peer-timeout`	The timeout, in milliseconds, used when connecting to any of the peers. Default: 200	`'{"peer-timeout": 1000}'`

A Service Registry service instance can also be configured to replicate its registry with peer Service Registry service instances in other VMware Tanzu Application Service for VMs (TAS for VMs) foundations, orgs, or spaces. For more information on the configuration parameters used to activate peer replication, see Activating Peer Replication.

App Security Groups (ASGs)

A Service Registry service instance can use one or more App Security Groups (ASGs). You can use this to activate a service instance to connect to external apps or services (for example, to configure peer replication for a Service Registry service instance with another Service Registry service instance that is located on a different TAS foundation). ASGs are applied to the space of the backing app for the service instance. You can configure the list of ASGs for the service instance by passing an application-security-groups parameter, a JSON array of ASG names, to cf create-service or cf update-service.

To create a Service Registry service instance that uses an ASG called my-asg, you might run:

$ cf create-service p.service-registry standard my-service-registry -c '{ "application-security-groups": [ "my-asg" ] }'

Creating an instance

Target the correct org and space:

$ cf target -o myorg -s development

You can view plan details for the Service Registry product by running cf marketplace -s.

$ cf marketplace -s p.service-registry
Getting service plan information for service p.service-registry as user...
OK

service plan   description     free or paid
standard       Standard Plan   free

Create the service instance using cf create-service, optionally using the -c flag to provide a JSON object that specifies the configuration parameters.

To create an instance with the default of a single node, run:

$ cf create-service p.service-registry standard service-registry

To create an instance, specifying that three nodes should be provisioned, run:

$ cf create-service p.service-registry standard service-registry -c '{"count": 3}'

As the command output suggests, you can use the cf services or cf service commands to check the status of the service instance. When the Service Registry instance is ready to be used, the cf service command will give a status of create succeeded:

$ cf service service-registry
Showing info of service service-registry in org myorg / space development as user...

name:            service-registry
service:         p.service-registry
bound apps:
tags:

[...]

Showing status of last operation from service service-registry...

status:    create succeeded

Note You may notice a discrepancy between the status given for a service instance by the cf CLI (e.g., by the cf service command) versus that shown on the Service Instances dashboard. The dashboard is updated frequently (close to real-time); the status retrieved by the cf CLI is not updated as frequently and may take time to match the dashboard.

Updating an instance

You can update settings on a Service Registry service instance using the Cloud Foundry Command Line Interface tool (cf CLI). The cf update-service command can be given a -c flag with a JSON object containing parameters used to configure the service instance.

To update a Service Registry service instance's settings, target the org and space of the service instance:

$ cf target -o myorg -s development

Then run cf update-service SERVICE_NAME -c '{ "PARAMETER": "VALUE" }', where SERVICE_NAME is the name of the service instance, PARAMETER is a supported parameter, and VALUE is the value for the parameter. For information about supported parameters, see the next section.

Configuration parameters

General parameters accepted for the Service Registry are listed below.

Parameter	Function	Example
`count`	The number of nodes to provision	`'{"count": 3}'`
`peer-timeout`	The timeout, in milliseconds, used when connecting to any of the peers. Default: 200	`'{"peer-timeout": 1000}'`
`upgrade`	Whether to upgrade the instance	`'{"upgrade": true}'`
`force`	When `upgrade` is set to `true`, whether to force an upgrade of the instance, even if the instance is already at the latest available service version	`'{"force": true}'`

A Service Registry service instance can also be configured to replicate its registry with peer Service Registry service instances in other TAS foundations, orgs, or spaces. For more information on the configuration parameters used to activate peer replication, see Activating Peer Replication.

To update a service instance and set the count of nodes for running in high-availability mode, run:

$ cf update-service service-registry -c '{"count": 3}'

As the command output suggests, you can use the cf services or cf service commands to check the status of the service instance. When the update is complete, the cf service command will give a status of update succeeded:

$ cf service service-registry
Showing info of service service-registry in org myorg / space development as user...

name:            service-registry
service:         p.service-registry
bound apps:
tags:

[...]

Showing status of last operation from service service-registry...

status:    update succeeded

The service instance is now updated and ready to be used. For information about registering an app with a Service Registry service instance or calling an app which has been registered with a Service Registry service instance, see Writing Client Applications.

A Service Registry service instance or its service registrations can be shared across TAS spaces in either of two situations:

Across spaces on same TAS foundation: VMware recommends using Cloud Foundry service instance sharing to share a Service Registry service instance across spaces on the same TAS foundation.
Across spaces on different TAS foundations: VMware recommends using Service Registry's peer replication feature to share service registrations with a Service Registry service instance in a space on a different TAS foundation.

Migrating Spring Cloud Services v2.x or v1.5 service instances

The Service Registry (p-service-registry) service offering of the Spring Cloud Services v2.x or v1.5 tile cannot be upgraded to the Service Registry (p.service-registry) service offering of the Spring Cloud Services v3.x tile. After installing Spring Cloud Services v3.x alongside the older version of Spring Cloud Services, follow the below instructions to migrate an older Service Registry service instance (SI).

Rename the existing SI (for example, adding a suffix -old to the original name):
```
$ cf rename-service my-service-registry my-service-registry-old
```
Create a new Spring Cloud Services v3.x (p.service-registry) SI, using the existing SI's original name and passing the existing SI's configuration using the -c flag:
```
$ cf create-service p.service-registry standard my-service-registry \
  -c '{"count": 3 }'
```
For each app bound to the existing SI, bind the app to the new SI:
```
$ cf bind-service myapp my-service-registry
```
For each app bound to the existing SI, unbind the app from the existing SI:
```
$ cf unbind-service myapp my-service-registry-old
```
For each app bound to the existing SI, restage the app:
```
$ cf restage myapp
```
For each app bound to the existing SI, ensure that the app is registered with the new SI.

Delete the existing SI:

$ cf delete-service my-service-registry-old