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
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.
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.
tc Runtime Instance names could include the port numbers, instance numbers, etc.
tc Runtime Instance names could be suffixed with
-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