Command Central 10.5 | Using Composite Templates | Composite Templates for 9.x Installations | Using the is-layer Sample Template | Understanding the is-layer Template Definition
 
Understanding the is-layer Template Definition
Environments
In this section you specify what type of environments you want to create on the target hosts. The is-layer template defines the following types of environments:
*dev - a local development environment
*server - an environment with a single Integration Server instance
*layer - an environment with multiple Integration Server instances, not configured in a cluster
*cluster - an environment with Integration Server instances configured in a cluster, with a Terracotta Server
When you define environment properties that apply for all types of environments, you include them under the environments/default section. If an environment property applies only for a particular type of environment, you include it under the respective environment section. For example, the spm.alias property applies only for the dev environment, because it is in the environments/dev section. Conversely, the environments/server section does not have any parameters and the server environment uses the environment properties defined in the environments/default section.
In general, when the is-layer template is used to install a new environment, Command Central determines which values to use for the environment properties in the following order. The composite template applies the apply composite template command arguments first, the environment properties file second, the environment.type sections of the template definition third, and the environments/default section fourth.
apply composite template environment properties priority order
For example, the dev environment uses the value of spm.port from the environments/dev section, instead of the environments/default section.
Some of the properties in the environments section have a default value, which you can specify in one place and then refer to that property/value pair from other parameters defined in the template. For example:
repo.spm: ${repo.product}
indicates that repo.spm refers to the repo.product property, which in the sample.properties file has the default value: repo.product=webMethods-${version}_GA. The version property, included in webMethods-${version}_GA also has a default value: version=9.12. When you apply the template without command arguments, Command Central will use the default value of repo.product from the properties file to determine from which product repository to install products.
Note that if the value of a parameter is specified as follows:
is.host: ${}
you must provide a value for this parameter in the template definition, a properties file, or a command argument. Otherwise, the template fails to apply successfully.
The environments/default section groups the environment properties, based on which information for the new environment they define:
*The product and fix repositories from which to install Platform Manager and the products, and apply the required fixes.
*The system configuration settings of the remote machine, required to bootstrap Platform Manager.
*The configuration settings required to create an Integration Server instance.
*The database configuration details, required to create the database schema and storage for Integration Server, and to enable Integration Server to connect to the database server.
Layers
In the layers/default section, the productRepo and fixRepo refer to the repository parameters, defined in the environments/default section and identify the product and fix repositories from which to install product and fixes for all layers, defined in the section. Each layer has the following purpose and properties:
*the spm layer is the first layer that Command Central applies, because this layer ensures that Platform Manager is updated to the required fix level and the spm-tuneup inline template is applied to install the product plug-ins. The templates parameter refers to the spm.configure parameter defined in the remote system configuration section of environments/default, which in turn points to the spm-tuneup inline template. The spm.fixes parameter identifies the repository from which to install the Platform Manager fixes.
*The dbc layer is used to create database storage and schemas for Integration Server on the target node. The templates parameter refers to the dbc.configure parameter defined in the environments/default section, which in turn points to the dbc inline template.
In the databases section you must define the details required for creating the database storage and schemas. The properties in the dbc-components and dbc-products sections point by reference to parameters defined in the environments/default section. Some of the parameters have default values to ensure that the database storage and schema are created and updated correctly, for example:
environments:
default:
db.components: [STR]
db.products: [IS]
db.component.version: latest
db.product.version: latest
Other parameters do not have defaults and you must specify user-defined values:
environments:
default:
db.type: ${} # REQUIRED: Database type: oracle,sqlserver,db2
db.host: ${} # REQUIRED: Database server hostname
db.port: ${} # REQUIRED: Database server port
db.admin.username: ${} # REQUIRED: for db storage only
db.admin.password: ${} # REQUIRED: for db storage only
db.tablespace.dir: ${} # for Oracle/DB2
When applying the dbc layer on a target node of release 9.9 or lower, the dbc.alias parameter to which you map the dbc layer in the provisioning section must point to the local node. Beginning with release 9.10, the dbc.alias can point to a local or remote Platform Manager node, for example:
environments:
default:
dbc.alias: remotehost
Important:
The host of the node on which the dbc layer is applied must have access to the database server host to be able to execute the database operations.
*The is layer is used to install Integration Server, and then create and configure the Integration Server instances. The templates parameter refers to the is.configure parameter defined in the Integration Server instance configuration section of environments/default, which in turn points to the is-server inline template.
Templates
This section includes the following inline templates:
spm-tuneup
The products section lists the IDs of Update Manager, Platform Manager, and the Integration Server plug-in for Platform Manager to ensure that they are installed on the Platform Manager node. After installing those components, Command Central applies the Platform Manager fixes, defined in the fixes property. The fix installation operation restarts Platform Manager, which enables the Integration Server plug-in.
dbc
The products section lists the ID of the Database Component Configurator (DBC) to ensure that this component is installed on the Platform Manager node. The DBC component is required for the execution of the database actions on the target nodes.
is-server
Command Central applies the is-server inline template in the following order:
1. Retrieves the Integration Server license file that matches the Integration Server key alias, defined in the licenses section, and copies the file to the "IntegrationServer/config/licenseKey.xml" location on the target node. Command Central performs the same action for the Terracotta Server: retrieves the Terracotta license file that matches the license key alias for Terracotta and copies it to the "common/conf/terracotta-license.key" target location.
2. Identifies the Integration Server product ID from the products section and installs Integration Server.
3. Applies the Integration Server fixes, defined in the fixes section. This section refers to the is.fixes parameter, defined in the remote system configuration part of the environments/default section.
4. Creates an Integration Server instance with the "default" alias specified in the ${is.instance.name} parameter. The Integration Server instance is created with the ports and database connection details, specified in the properties under the ${is.instance.name} section.
5. Applies the configuration properties defined for the Integration Server instance in the configuration section. The configuration properties for the Integration Server OSGi profile and for the Integration Server instance are in separate sections, and the properties for each configuration type have their own subsection. List the properties for each configuration type as parameters in YAML format or as items of a list. To introduce a list of items, prefix the line with a dash, for example:
configuration:
integrationServer-${instance.name}:
COMMON-LOCAL-USERS:
COMMON-LOCAL-USERS-Administrator:
"@id": Administrator
Enabled: true
Password: ${is.password}
ExtendedProperties:
Property:
-
"@name": "AllowDigestAuthentication"
$: false
Provision
Command Central uses the map in this section to determine which layers to apply on which target nodes for each environment type. The layers are mapped to the node aliases. When creating the new environment, Command Central applies one layer on all target nodes to which the layer maps before it starts applying the next layer. For example:
dev:
spm: ["${spm.alias}"]
dbc: ["${dbc.alias}"]
is: ["${spm.alias}"]
In the example, when creating a dev environment, Command Central applies the spm layer on the host of the Platform Manager installation with alias "spm.alias". After applying the spm layer, Command Central applies the dbc layer on the host specified for "dbc.alias", and after the dbc layer is done, the "is" layer gets applied on the host of "spm.alias".
You also have the option to define a list of hosts on which to apply a layer as a parameter and refer to that list, for example:
layer:
spm: ${is.hosts}
dbc: ["${dbc.alias}"]
is: ${is.hosts}
In the example, when installing a layer environment, the spm and is layers are applied on the list of hosts defined for the is.hosts parameter in the properties file.
The nodes in the list are applied in parallel, based on the thread pool size. For example, if the thread pool size is set to 10 and you have 100 nodes in the list, the nodes are processed 10 at a time in parallel, in the order in which they are listed.
Nodes
Command Central uses the information from this section to determine how to install Platform Manager on the remote machine. This section includes two sections:
*default - properties used to install Platform Manager for all environment types
*dev - properties used for the dev environment type. When bootstrapping Platform Manager for the dev environment, Command Central will use the spm.alias as the alias and is.host as the host of the new Platform Manager installation. The remaining bootstrap details are taken from the nodes/default/default/bootstrapInfo section.
When Platform Manager is installed and running on the remote machine, Command Central skips the bootstrapInfo section, which means that you must only configure the port, host, and secure properties in the nodes/default/default section. Note that by default, spm.secure is set to false. To enable HTTPS, set spm.secure: true.
When Platform Manager is not installed on the remote machine, Command Central uses the properties in the nodes/default/default/bootstrapInfo section to determine how to install Platform Manager. The installDir property specifies the installation directory of Platform Manager on the target machine and repoName identifies from which product repository to install Platform Manager. The platform and port properties refer to the os.platform and os.port parameters, which identify the operating system and the SSH port of the remote machine.
The distribution property specifies how to install Platform Manager. Software AG recommends that you use:
*DEF for environments of release 9.10 and higher. Installs Platform Manager, Update Manager, and CLI.
*ALL for environments of release 9.8 and 9.9. Installs Platform Manager, Update Manager, CLI, and all product plug-ins.
The credentials section includes details about the SSH user account on the remote machine that owns the Software AG installation directory files and can execute Command Central processes and commands. All properties under credentials refer to configuration parameters of the remote operating system, defined in the environments/defaults section. The default value of the os.auth.method parameter is the PASSWORD authentication method for the SSH connection to the remote machine. If you set os.auth.method: CERTIFICATE, you must also specify the location of the RSA private key file as the value of the os.auth.key parameter. For example: os.auth.key: ${user.home}/.ssh/id_rsa
Important:
The remote host must have Java 8 installed and available for the SSH user. You can specify the location of Java on the remote host by adding a javaPath property in the bootstrapInfo section as follows: javaPath: /path/to/java
Inside the Sample Properties File
The sample.properties file, included with the is-layer template, contains sample properties that you can configure and use to install Integration Server with an Oracle database. By default, the sample properties are defined for a local development environment. When you want to install a different type of Integration Server environment, you comment out all lines with properties for the environment.type sections that you do not want to use, and uncomment the lines of the environemnt.type section that you want to use. For example, if you want to install an Integration Server cluster, change the environment type sections as follow:
#######################################
# dev/server/layer/cluster
# environment.type=dev

#######################################
# environment.type=server
# is.host=ccdemowin2012
# os.platform=w64
os.username=vmtest
os.password=vmtest

#######################################
# environment.type=layer
is.hosts=[bgcctbp12,bgcctbp13]
os.platform=lnxamd64

#######################################
environment.type=cluster
is.cluster.enabled=true
is.tsa.url=bgcctbp12:${port.range}10
tc.license.key.alias=Terracotta