Command Central 10.11 | Using Composite Templates | Understanding the Composite Template Definition | Nodes
 
Nodes
The nodes section defines the managed installations, also called nodes, to which the layers in the composite template are mapped.
You can define a list of nodes in a nodes/nodeAlias section, for each environment.type included in a composite template. All parameters that you specify for a node are optional. When you do not specify parameters for a node in a nodeAlias section:
*The node uses the properties specified in the nodes/default/default section and the node alias is also used as a host name for that node. This section specifies the properties of the default node definition.
*If the properties are not specified in the nodes/default/default section, the node uses the system default parameters.
Defining the local node in the nodes section is optional. Even when the local node is not defined in the nodes section, you can map the local node to layers in the provision section.
aliasMapping/policy
Important:
This section is supported only with DSL version 1.1.
Based on the policy that you set in nodes:default:aliasMapping:policy: (for all environment types) or nodes:envType:aliasMapping:policy: (for a specific environment.type), each node is referenced by:
*A global node alias, when policy: HOSTNAME|EXISTING
HOSTNAME (default) maps each layer defined in the provision/environment.type sections to a list of node aliases or hostnames.
EXISTING uses the details of a Platform Manager node that already exists in Command Central (such as Platform Manager installed from the web user interface, the CLI, or another template) and ignores any parameters included in the nodes section of the template, except the node alias.
*An indexed node alias when policy: INDEX
INDEX uses a node alias generated from a custom prefix (specified in the prefix: parameter) and an index number, based on the consecutive order of the hosts in provision:envType:infrastructure:hosts.
When policy: INDEX, you must also include the prefix: parameter. The value of the prefix: parameter is used to generate an indexed node alias in provision:envType:layer:aliases. Use the delimiter: parameter if you want to specify a custom delimiter for the generated indexed node alias. For example:
nodes:
default:
aliasMapping:
policy: INDEX
prefix: node
delimiter: "_"
In the nodes section, you can also use reference parameters to refer to the node alias prefix and index. For example:
nodes:
default:
aliasMapping:
policy: INDEX
prefix: ${node.alias.prefix} # The prefix of the node alias.
default:
port: ${spm.port}
bootstrapInfo:
installDir: /opt/sag${node.alias.prefix}${node.index} # The indexed node alias
# (prefix plus index number)
See also the example of mapping layers to indexed node aliases in the Provision section.
credentials: ${spm.credentials.alias}
In the nodes:default:default: section, you must specify the credentials alias for the Platform Manager administrator user credentials. Beginning with Platform Manager release version 10.11, the credentials parameter is required and by default uses the ADMINISTRATOR credentials alias. If Platform Manager is already bootstrapped on the target node and you use a custom password for the administrator user account, you must define a credentials alias for the custom administrator user credentials. For example, in the following template snippet, the credentials parameter refers to the spm.credentials.alias parameter.
nodes:     
    default:     
      default:     
        port: ${spm.port}     
        secure: ${spm.secure}     
        credentials: ${spm.credentials.alias}
You can specify the value of the spm.credentials.alias parameter in the environments/default section, a separate properties file, or as argument of the apply composite template command. The spm.credentials.alias parameter maps to the alias of the common credentials configuration instance you created for your custom administrator user, for example: spm.credentials.alias: SECURE_ADMINISTRATOR
where SECURE_ADMINISTRATOR is the alias of the custom COMMON-CREDENTIALS-SECURE_ADMINISTRATOR configuration instance. For information about creating common credentials configuration instances, see Configuration Types for Command Central and Platform Manager OSGI ENGINE.
When bootstrapping nodes with version:
*10.11 and higher, you should use the ADMINISTRATOR credentials alias or a custom credentials alias with a strong password. Note that the ADMINISTRATOR credentials alias does not have a default password value and you must specifying a strong administrator password before using the ADMINISTRATOR credentials. For more information, see Default and Custom Product Administrator User Passwords.
*10.7 and lower, by default the template uses the DEFAULT_ADMINISTRATOR credentials alias, which includes the default password. Software AG strongly recommends that you replace the default password with a strong administrator password.
Example
In the following example, the installations with aliases “node1” and “node2” are installed only when creating an environment with type “envType1”. The two nodes are installed on the local host with unique port numbers and installation directories.
The definition for “node1” and “node2” does not specify user credentials. The two nodes use the “DEFAULT_ADMINISTRATOR” user credentials specified in the credentials parameter in the nodes/default/default section. For information about the default common credentials configuration instances, see COMMON-CREDENTIALS Usage Notes.
The nodes/default/default section does not provide a value for the HTTPS port and all nodes in the template use the system default value for the HTTPS port.
Platform Manager is installed on both nodes using the Command Central bootstrap installer specified in the cc.installer parameter in the nodes/default/default/bootstrapInfo section.
nodes:     
    default:     
      default:     
        port: 8093     
        secure: false     
        credentials: DEFAULT_ADMINISTRATOR     
        bootstrapInfo:     
          cc.installer: ${}     
          installDir: /opt/softwareag     
          platform: lnxamd64     
     
    entType1:     
      node1:     
        host:localhost     
        port: 8192     
        bootstrapInfo:     
          installer: ${cc.installer}
installDir: /opt/softwareag/n1     
     
      node2:     
        host: localhost     
        port: 8292     
        bootstrapInfo:     
          installer: ${cc.installer}
          installDir: /opt/softwareag/n2
nodes/default/default/bootstrapInfo
In the nodes/default/default section, you can add an optional section with bootstrap information that enables you to bootstrap Platform Manager to a local or remote installation.
You can specify the following parameters in the nodes/default/default/bootstrapInfo section:
bootstrapInfo:
installer: ${bootstrap.installer} # The file name of the Command Central
# bootstrap installer to use
# for bootstrapping Platform Manager.
installDir: ${install.dir} # The installation directory
# of Platform Manager.
substituteUserCredentials: ${subst.credentials.alias} # For remote bootstrap: the
# alias for the substitute user
# credentials to use to install
# and start Platform Manager.
credentials: ${credentials.alias} # For remote bootstrap: The SSH credentials
# to use to connect to the remote hosts.
version: "${release}" # The release version of
# the Platform Manager node.
# For backward compatibity when "cc.installer"
# is not available.
For more information about how to use substituteUserCredentials: and credentials:, see Bootstrapping on a Remote Machine with a Substitute User.
After you download the Command Central bootstrap installer for the release that you want from the Empower Product Support website, save the downloaded Command Central bootstrap installer file into the $CC_HOME/profiles/CCE/data/installers directory. To list the available bootstrap installers, run the following CLI command: sagcc list provisioning bootstrap installers.
Usage Notes
*When you use the Command Central bootstrap installer for the nodes bootstrap, only Platform Manager is installed on the nodes, without the CLI. To install the CLI with the same template, you must include an inline template that installs the CLI as a product.
*Command Central attempts to connect to the Platform Manager host and port of the node, which Command Central wants to use, with the user credentials specified for the node. If Platform Manager is running and responds, Command Central uses the node. If Platform Manager does not respond, Command Central attempts to connect to the remote host using the SSH protocol and the user credentials defined in the bootstrapInfo section. If the connection is successful Command Central bootstraps and starts Platform Manager, and waits until Platform Manager becomes responsive and available to establish an HTTP/S connection.
Important:
By default, the Command Central bootstrapper installs Java on the remote host and the SSH user connects to the Java installation. If required, you can use an existing Java installation on the remote host by adding a javaPath property in the bootstrapInfo section to specify the Java location as follows: javaPath: /path/to/java
*You can define the ${install.dir} parameter as a variable in the environments section that points to ${user.home}, for example:
environments:
default:
cc.installer: cc-def-10.7-milestone-w64.bat
install.dir: ${user.home}\sag102
...
nodes:
default:
default:
port: ${spm.port}
secure: false
bootstrapInfo:
installDir: ${install.dir} # Installation directory
installer: ${cc.installer}
...
To resolve ${user.home} correctly in Windows, you must start the Command Central and Platform Manager Windows services from a local user account with administrator permissions, not from a "Local System" user account.
Example
The following template snippet shows how to define a composite template that you can use to bootstrap Platform Manager to a local node. The alias of the new Platform Manager installation, “dev8192”, is specified in the “spm-alias” parameter in the environments/default subsection. The “cc.installer” parameter is the Command Central bootstrap installer to use to install Platform Manager. The “install.dir” parameter is the path to the Platform Manager target installation directory. The “cc.installer”and “install.dir”parameters are required and their values depend on your operating system. You must provide values for those parameters at the time of applying the template. The “install.dir” value should point to a directory that does not exist on the target node and for which the Command Central user account that you use to bootstrap Platform Manager has write access. The “spm.port” default value is unique and is not used by any other local process, including Command Central and Platform Manager.
The parameters in the nodes/default/default/bootstrapInfo section refer to the values for Command Central bootstrap installer and Platform Manager installation directory specified in the environments/default section. The nodes section also defines an “spm.alias” node with host “localhost”. The layers section defines a single Platform Manager “management” layer that maps to the “spm.alias” node in the provision section.
alias:bootstrap
description: Bootstrapping local nodes
    
environments:
    default:
      cc.installer: ${}
install.dir:  ${}
      spm.port: 8192
      spm.alias: dev${spm.port}
    
nodes:
    default:
      default:
        port:${spm.port}
        secure: false
credentials: DEFAULT_ADMINISTRATOR
        bootstrapInfo:
          installer: ${cc.installer}
installDir: ${install.dir}
    
${spm.alias}:
     host: localhost
    
layers:
    management:
description: management layer of SPM
templates: spm-tuneup

templates:
spm-tuneup:
products:
SPM:
    
provision:
    default:
      management: ${spm.alias}