Creating tc Runtime Instances

Best Practices: Creating tc Runtime Instances

Using the best practices for creating tc Runtime instances will allow users such as System Administrators and Developer Operators to gain the most value from using tc Server.

When designing the tc Server environment and management of tc Runtime Instances consider the information in this document. The advice given in this document is intended to create reproducible tc Runtime Instances. This gives the user the ability to easily recreate the tc Runtime Instance, identical tc Runtime Instances in new environments, or with slightly modified properties for testing or even for tc Runtime version upgrade testing. This practice also simplifies upgrading to new tc Runtime major versions for example upgrading from 8.5.x to 9.0.x.

Only use tc Server to manipulate the configuration of a tc Runtime Instance

Never manually modify the configuration files of a tc Runtime Instance. Use the features provided by tc Server to manipulate the configuration of a tc Runtime Instance. These features include creating the tc Runtime Instance with an Instance Descriptor File, using property files for variables, and using apply-template to change configuration of tc Runtime Instances.

Use Instance Descriptor Files

A tc Runtime Instance Descriptor File contains all the options and property values to create a tc Runtime Instance. Using this file provides for a trackable configuration.

The tc Runtime Instance Descriptor File can be modified over time for new tc Runtime versions, updated templates, and new property values.

These files can be in the form of a java properties file or YAML. It is recommended to use YAML file format as it is easier to read. An example tc Runtime Instance Descriptor File is below.

instance:
  name: tomcat-sample
 version: 9.0.50.B.RELEASE
templates:
  - nio
  - nio-ssl
 applications:
  - https://tomcat.apache.org/tomcat-9.0-doc/appdev/sample/sample.war=ROOT.war
properties:
  - nio-ssl.https.port=8081

In the above example when a new tc Runtime version is released the value of version can be changed and a new instance created. The application deployed can be pulled from a repository and also be versioned.

Additional suggestions:

tc Runtime Instance names could include the port numbers, instance numbers, etc. tc Runtime Instance names could be suffixed with -dev or -prod to denote the environment type.

Using a consistent naming convention can help identify an instance and its purpose.

Use Templates For All Customizations

Create templates for all custom configuration options. Templates can modify conf/server.xml and other configuration files.

Using templates allows tracking of all changes and makes it easier to recreate an instance configuration locally for testing purposes. In addition it’s simpler to make needed changes as tc Runtime versions change.

Use Property Files

When properties need to be shared between Instance Descriptor files use properties files to store the key/value pairs of those properties.

Use A Revision Control System such as Git

Create a repository to store all tc Runtime Instance Descriptor Files, property files, notes, and custom templates. Use a naming scheme and folder hierarchy to organize the files.

The hierarchy should be based on your organization’s needs. Some suggestions are as follows:

Use subfolders for production vs development Use consistent naming conventions Use commit message conventions and include details on changes Use tags for marking significant changes or releases