You can follow the steps here to install Spring Cloud Services.

Important Spring Cloud Services (SCS) v2.x and v3.1 use the p-spring-cloud-services org to deploy service instance backing apps. Deleting v2.1.2 or earlier deletes this org, even if SCS v3.1 is installed. If you have installed SCS v3.1 alongside v2.x, do not delete SCS v2.x until upgrading it to v2.1.3 or later. See Upgrading to SCS v3.1 and Removing SCS v2.x.

Installation steps

  1. Verify that you have completed all items listed in Requirements.

  2. Download Spring Cloud Services from the Broadcom Support portal.

  3. In the Installation dashboard of Ops Manager, click Import a Product on the left sidebar to upload the Spring Cloud Services file.

  4. In the left sidebar, under Spring Cloud Services, click the + button next to the version number.

  5. When the Spring Cloud Services tile appears in the Installation Dashboard, click it. In the Settings tab, click Assign AZs and Networks.

    Assigning AZs and Networks

    Select the availability zones for the tile to use. In the Network section, select the network used by VMware Tanzu Application Service for VMs (TAS for VMs). When finished, click Save.

  6. Return to the Installation Dashboard.

  7. Click Review Pending Changes. For more information about this Ops Manager page, see Reviewing Pending Product Changes.

  8. Click Apply Changes to install the tile.

Running alongside previous versions

Spring Cloud Services (SCS) v3.0--v3.1 can be installed alongside earlier versions of Spring Cloud Services, including v2.0 and v2.1. SCS v3.1 includes a new Config Server service, which is named p.config-server instead of p-config-server as in v2.1 and earlier versions, and a new Service Registry service, which is named p.service-registry instead of p-service-registry as in v2.1 and earlier versions.

Important If you have installed Spring Cloud Services (SCS) v3.x alongside SCS v2.x, do not delete SCS v2.x until you have updated it to v2.1.3 or later. For more information, see Upgrading Spring Cloud Services for VMware Tanzu.

Even though you can run different SCS versions in parallel, VMware recommends that you migrate all your service instances to Spring Cloud Services v3.1 to complete the upgrade. For more information, see Upgrading Spring Cloud Services for VMware Tanzu.

Network connectivity requirements

A client trying to access Config Server or Registry is going to do so over HTTPS so there would be no additional ports required. If traffic is coming to the foundation then this should work too. See Writing Client Applications.

If the service registry employs container-to-container networking, then you will need to add a network policy; but you don’t need to configure any specific ports.

The ports required for Config Server will depend on the backend used:

  • If using a Git backend, the config server will only communicate directly with the mirror service over SSH. Therefore, you'll need to allow communication over port 22. The mirror service itself may communicate with the Git server over SSH or HTTPS. Thus, both port 22 and 443 will need to be open.
  • If using Vault, you'll need to allow traffic to your vault servers. Those are external so you should know the ports to open.

You will also need all of the standard ports open for Bosh deployed VMs.

Differences between v3.0-v3.1 Config Server and earlier config server

The p.config-server service includes new features (including the CredHub backend) and can run alongside the services included in 2.1 and earlier versions. You may wish to deactivate the older p-config-server service and allow only the new p.config-server Config Server service to be created.

Older Config Server service instances cannot be upgraded to the new p.config-server service. Instead, you must recreate p-config-server service instances. Most parameters used to create a p-config-server service instance with the Cloud Foundry Command Line Interface (cf CLI), using the cf create-service command with the -c flag, can also be used to create a p.config-server service instance. The following parameters are exceptions which can be used with the p-config-server service but cannot be used with the p.config-server service:

  • git.repos
  • composite.git (see Composite Backends for information about how to configure the composite backend in the SCS v3.0--v3.1 Config Server)
  • composite.vault (see Composite Backends for information about how to configure the composite backend in the SCS v3.0--v3.1 Config Server)

SCS v3.1 service instances are backwards-compatible with version 2.0.1.RELEASE of the SCS client dependencies.

Upgrading to SCS v3.1 and removing SCS v2.x

Important SCS v3.1 and later do not include p-circuit-breaker-dashboard. To retain this functionality, you must keep SCS v2.x installed.

If you are running SCS v3.0 or v3.1 alongside v2.x, you can complete the upgrade to v3.1 using the following procedure:

  1. Upgrade SCS v2.x to >= 2.0.11 or >= v2.1.3.
  2. Upgrade SCS v3.x to the latest version.
  3. Migrate all apps to bind to p.config-server service instances instead of p-config-server. For instructions, see Migrating Spring Cloud Services v2.x or 1.5 Service Instances in the Config Server documentation.
  4. Migrate all apps to bind to p.service-registry service instances instead of p-service-registry. For more information, see Migrating Spring Cloud Services v2.x or v1.5 Service Instances in the Service Registry documentation.
  5. Restage all migrated apps.
  6. Verify that all apps are behaving as expected before moving on to the next step.
  7. Delete the SCS v2.x tile.
check-circle-line exclamation-circle-line close-line
Scroll to top icon