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

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.

Server name differences in SCS v3.x

SCS v3.x includes a new Config Server service, and a new Service Registry service. Both have been renamed compared to their v2.x versions:

  • Config Server service: p.config-server (instead of p-config-server)
  • Service Registry service p.service-registry (instead of p-service-registry)

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.x 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.x Config Server)
  • composite.vault (see Composite Backends for information about how to configure the composite backend in the SCS v3.x Config Server)

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

Upgrading from SCS v3.0-v3.1 to SCS v3.2

In SCS v3.2, Config Server uses main as default label, instead of master in earlier versions. If all your service instances are configured with a label explicitly, the upgrade can be done simply by running upgrade-all-instances errand during 3.2.x tile installation or after. But if the service instances have been relying on the default value (master) for the label, you need to take the following actions before running the upgrade-all-instanes errand:

  • Git backends: You can rename the master branch to main or create a new branch called main from the master branch. Alternatively, you can update all service instances by setting label to master explicitly.

  • CredHub backends: You need to update all secrets by replacing master with main in their path.

check-circle-line exclamation-circle-line close-line
Scroll to top icon