tc Server includes a feature to download components from remote repositories. The current components which can be downloaded are the following:

  • tc Runtimes
  • Templates

There are multiple options for repository servers. VMware tc Server includes access to the VMware Tanzu Network repository. In addition customers may host a repository on their internal network via a HTTP server.

A deprecated repository is available in tc Server version 4.0.x and 4.1.x which will be removed in the next major release. This repository does not require configuration and will remain the default until Q3 of 2022.

It is possible to use Tanzu Network for tc Runtimes and an internally hosted repository for templates. This documentation covers both tc Runtimes and templates.

Tanzu Network Repository

The VMware Tanzu Network Repository is available to all users. A configuration step is required in order to enable this repository as it requires a unique token for identifying the user.

It may be obtained by logging into VMware Tanzu Network, clicking on the username in the top right, clicking on Edit Profile, and then clicking on the button next to UAA API TOKEN.

There can only be one token per Tanzu Network user. Once generated it is only provided to the user once and can not be obtained again. If the token has already been generated, choosing REQUEST NEW REFRESH TOKEN will invalid the previous token.

In order to use the Tanzu Network Repository for both tc Runtimes and templates the following key/value properties must be configured in conf/tcserver.properties:

tcserver.repository.runtime.deprecated=false
tcserver.repository.template.deprecated=false
runtimes.tanzunet=true
templates.tanzunet=true

It is possible to configure different repositories for tc Runtimes and templates.

In addition to the above an additional key/value pair must be defined. The value of tanzunet.token must be provided and is the Refresh Token obtained from Tanzu Network.

tanzunet.token=<REFRESH_TOKEN>

Alternatively, an environment variable may be used

TCS_TANZUNET_TOKEN=<REFRESH_TOKEN>

There is only one Tanzu Network Repository and as such there are no separate token properties for runtimes and templates.

Internally Hosted Repository

Note: Please use caution with hosting tc Server artifacts such as tc Runtimes as per the VMware End User License Agreement redistribution of tc Server artifacts is restricted. Self-hosted repositories should not be publicly available for anonymous downloads over the Internet.

Customers who desire not use the VMware Tanzu Network Repository have the option to host their own internally.

Conceptually a repository is a HTTP server which serves content and response to specific GET requests for specific paths. The server does not need to be a tc Runtime Instance. It can be anything which serves the request.

At the root of a repository path there is expected to be a specific file depending on the content of the repository. The following list describes the path and the purpose:

  • /runtimes.json - File containing the directory of tc Runtime archives
  • /templates.json - File containing the directory of template archives.

If the repository path is http://repo.example.com/ then the server is expected to server the JSON content at http://repo.example.com/runtimes.json or http://repo.example.com/templates.json.

File Formats

runtimes.json

At the root of the repository is a file called runtimes.json. This file is accessed by the tcserver command to determine what artifacts are available and how to find them.

The runtimes.json file structure:

{
  "runtimes": [
    {
      "version": "<tc Runtime Version>",
      "path": "<relative path to .zip archive>",
      "compatableWith": "<tc Server major.minor version this archive is compatible>"
    }
  ]
}

Note: Duplicate versions are ignored only the first entry matching a version number is processed by tc Server.

Example runtimes.json file:

{
  "runtimes": [
    {
      "version": "8.5.76.A",
      "path": "pivotal-tc-runtime-8.5.76.A.RELEASE.zip",
      "compatableWith": "4.0"
    },
    {
      "version": "7.0.109.C",
      "path": "pivotal-tc-runtime-7.0.109.C.RELEASE.zip",
      "compatableWith": "4.0"
    },
    {
      "version": "9.0.59.A",
      "path": "pivotal-tc-runtime-9.0.59.A.RELEASE.zip",
      "compatableWith": "4.0"
    },
    {
      "version": "9.0.58.A",
      "path": "pivotal-tc-runtime-9.0.58.A.RELEASE.zip",
      "compatableWith": "4.0"
    }
  ]
}

The relative path is to the runtimes.json location.

templates.json

{
  "templates": [
    {
      "name": "<template name>",
      "version": "<template version>",
      "description": "<template description>",
      "path": "<relative path to .zip archive>"
    }
  ]
}

Note: Duplicate versions are ignored only the first entry matching a version number is processed by tc Server.

No validation is performed on the name, version, and description of template. When a reference is made to the name and version the path is accessed. Path must be relative to the location of the runtimes.json file.

Unlike get-runtime the get-template command does not maintain the templates.json file. This feature will be available in a future release of tc Server.

Example templates.json

{
  "templates": [
    {
      "name": "production-config",
      "version": "1.0.0",
      "description": "Applies production configuration to server.xml",
      "path": "production-config-template.zio"
    },
    {
      "name": "development-config",
      "version": "4.4.0",
      "description": "Applies development configuration to server.xml",
      "path": "development-config-template.zio"
    }
  ]
}

Using the static-content template to create an tc Runtime Instance to host a repository

As of tc Server Version 4.1.16 and 4.0.28 tc Server includes a static-content template which applies the configuration needed to host static content.

This template accepts the following properties:

  • static-content.docBase - Value to use for the docBase property. Defaults to docBase which is also created by this template.
  • static-content.path - Value to use for the path property. Defaults to an empty string which translates to "/".

It is recommended to create your base repository directory at the same level as the runtimes directory. For example if tc Server is installed in /opt/pivotal/tcserver/standard-4.1.16.RELEASE then create the repository should be at /opt/pivotal/tcserver/repository. The recommended layout is as follows:

  • /opt/pivotal/tcserver/repository/runtimes
  • /opt/pivotal/tcserver/repository/templates

These directories will need to be manually created prior to running the tc Runtime Instance

Creating a new tc Runtime Instance

The following command example may be used to create a new tc Runtime Instance for hosting static the tc Server repository

tcserver create tcserver-repository -t static-content -p static-content.docBase=/opt/pivotal/tcserver/repository

Consider customizing the nio.http.port property if this instance is running on the same host as others.

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