Nodes
The nodes section defines the managed installations, also called nodes, to which the layers in the composite template are mapped.
The nodes included in this section are identified by their global node alias. 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.
Examples
If
Platform Manager is already bootstrapped on the target node and you use a custom password for the administrator user account, you must include the custom password in the
nodes section of the composite template. In the following template snippet, the
password property under
credentials refers to the
spm.password parameter, which you can define in the environments/default section, a separate properties file, or as argument of the apply composite template command. Specify your user-defined password as the value of the
spm.password parameter.
nodes:
default:
default:
port: ${spm.port}
secure: ${spm.secure}
credentials:
userName: Administrator
password: ${spm.password}
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 “node3” installation is not defined with specific properties and it maps to the parameters specified in the
nodes/default/default section, using “host3” as a host name.
The definition for “node1” and “node2” does not specify user credentials. The two nodes use the “Administrator/mysecret” user credentials, defined in the nodes/default/default section.
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.
nodes:
default:
default:
port: 8093
secure: false
credentials:
userName: Administrator
password: mysecret
bootstrapInfo:
repoName: webMethods-US
installDir: /opt/softwareag
platform: lnxamd64
credentials:
userName: sagadmin
password: secret123
entType1:
node1:
host:localhost
port: 8192
bootstrapInfo:
installDir: /opt/softwareag/n1
repoName: webMethods-EUR
node2:
host: localhost
port: 8292
bootstrapInfo:
installDir: /opt/softwareag/n2
repoName: webMethods-EUR
nodes/default/default/bootstrapInfo
In the
nodes/default/default section, you can add an optional subsection with bootstrap information that enables you to bootstrap
Platform Manager to a local or remote installation. For more information about bootstrapping
Platform Manager, see
sagcc exec provisioning bootstrap
nodes.
Usage Notes
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 responsive, Command Central uses the node. If the 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: 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
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 “repo.spm” parameter is the product repository from which to install Platform Manager. The “install.dir” parameter is the path to the Platform Manager target installation directory. The “repo.spm”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 the Platform Manager repository, installation directory, and distribution 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:
repo.spm: ${}
repo.fix.spm: ${}
spm.fixes: ALL
install.dir: ${}
spm.port: 8192
spm.alias: dev${spm.port}
spm.distribution: DEF
nodes:
default:
default:
port:${spm.port}
secure: false
bootstrapInfo:
installDir: ${install.dir}
repoName: ${repo.spm}
distribution: ${spm.distribution}
${spm.alias}:
host: localhost
layers:
management:
description: management layer of SPM
templates: spm-tuneup
productRepo: ${repo.spm}
fixRepo: ${repo.fix.spm}
templates:
spm-tuneup:
fixes: ${spm.fixes}
products:
SPM:
provision:
default:
management: ${spm.alias}