Spring Cloud Services for Cloud Foundry 3.2

Managing Spring Cloud Services service instances

Last Updated February 27, 2025

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

Available parameters

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

ParameterFunctionExample
countThe number of nodes to provision: 1 by default, more for running in high-availability mode‘{“count”: 3}’
peer-timeoutThe 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 Tanzu Platform for CF foundations, orgs, or spaces. For more information about 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 Tanzu Platform for CF 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

  1. Target the correct org and space:

    $ cf target -o myorg -s development
    
  2. 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
    
  3. Create the service instance using cf create-service, optionally using the -c flag to provide a JSON object that specifies the configuration parameters.

  4. To create an instance:

    • With the default of a single node, run:

      $ cf create-service p.service-registry standard service-registry
      
    • While 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
      

You may notice a discrepancy between the status given for a service instance by the cf CLI (by the cf service command, for example) 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 CLI 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
  • 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.

ParameterFunctionExample
countThe number of nodes to provision‘{“count”: 3}’
peer-timeoutThe timeout, in milliseconds, used when connecting to any of the peers. Default: 200‘{“peer-timeout”: 1000}’
upgradeWhether to upgrade the instance‘{“upgrade”: true}’
forceWhen 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 Tanzu Platform for CF foundations, orgs, or spaces. For more information about 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 return status 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 that has been registered with a Service Registry service instance, see Writing Client Applications.

Sharing a service registry

A Service Registry service instance or its service registrations can be shared across Tanzu Platform for CF spaces in either of two situations:

  • Across spaces on same Tanzu Platform for Cloud Foundry foundation: VMware recommends using Cloud Foundry service instance sharing to share a Service Registry service instance across spaces on the same Tanzu Platform for CF foundation.
  • Across spaces on different Tanzu Platform for Cloud Foundry 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 Tanzu Platform for CF 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 instructions here to migrate an older Service Registry service instance (SI).

  1. Rename the existing SI (for example, adding a suffix -old to the original name):

    $ cf rename-service my-service-registry my-service-registry-old
    
  2. 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 }'
    
  3. For each app bound to the existing SI, bind the app to the new SI:

    $ cf bind-service myapp my-service-registry
    
  4. For each app bound to the existing SI, unbind the app from the existing SI:

    $ cf unbind-service myapp my-service-registry-old
    
  5. For each app bound to the existing SI, restage the app:

    $ cf restage myapp
    
  6. For each app bound to the existing SI, ensure that the app is registered with the new SI.

  7. Delete the existing SI:

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