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.
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.
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" ] }'
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.
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.
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:
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.1 tile. After installing Spring Cloud Services v3.1 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.1 (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