Use server templates to easily manage configuration for a group of server instances in one centralized location. Learn how to create, configure, and use server templates in WebLogic Server.
This chapter includes the following sections:
A server template contains common, non-default settings and attributes that you can apply to a set of server instances, which then inherit the template configuration. You can define server-specific values for server instances that require unique attributes by overriding the server template in the server instance definition.
At runtime, the domain merges the attributes configured in the server template with any server-specific overrides so that all attributes are defined for all server instances.
Example 5-1 shows an example config.xml file that uses a server template. In this example, common configuration is defined in the <server-template> element. The individual server definitions set server-specific attributes (name, listen-port) and specify the server template upon which to base additional configuration (my-cluster-server-template).
Example 5-1 Example config.xml File Using a Server Template
<server>
<name>my-server-1</name>
<listen-port>7010</listen-port>
<server-template>my-cluster-server-template</server-template>
</server>
<server>
<name>my-server-2</name>
<listen-port>7020</listen-port>
<server-template>my-cluster-server-template</server-template>
</server>
<server-template>
<name>my-cluster-server-template</name>
<accept-backlog>2000</accept-backlog>
<cluster>my-cluster</cluster>
<restart-max>10</restart-max>
<reverse-dns-allowed>true</reverse-dns-allowed>
<startup-timeout>600</startup-timeout>
</server-template>Server templates enable you to easily manage configuration for a group of server instances in one centralized location. You can define common configuration attributes in a server template and then apply the template to other server instances without having to manually configure each one.
As the basis for any configured managed server
As the basis for dynamic servers in a dynamic cluster
Use Server Templates as the Basis for Any Configured Managed Server
A server template serves as a way to simplify server configuration. The managed server inherits the configuration attributes from the server template it references except for attributes that are manually configured in the server configuration. You can override any configuration attribute in this case.
If you need to define any server-specific attributes, you can easily override the server template at the individual server level.
If you need to update an attribute across all server instances, you can simply change the value in the server template and the new value takes effect in all the server instances that use that server template. You do not need to write a WLST script to update all the servers in the domain.
Server templates also help with performance and startup time. Defining common attributes once in the server template, instead of setting the same attribute in each server instance definition, reduces the size of the config.xml file.
Use Server Templates as the Basis for Dynamic Servers in a Dynamic Cluster
You also use server templates to create dynamic clusters. You can define a specific server template to use as the basis for all dynamic servers in a dynamic cluster.
A dynamic cluster contains multiple dynamic servers that are based on a single-server template. This server template is the basis for all the servers in the cluster so that you do not need to manually configure each server when expanding the cluster. When you use a server template to create a dynamic cluster and specify the number of server instances you want, WebLogic Server inherits and calculates necessary values from the server template and then uses these calculated values for the attributes. You cannot change individual server configuration for dynamic servers except for system properties that you would specify when starting the server. To know more about how to create, configure, and use dynamic clusters in WebLogic Server, see Dynamic Clusters in Administering Clusters for Oracle WebLogic Server.
You create server templates using WebLogic Scripting Tool (WLST), Fusion Middleware Control (FMWC), or the WebLogic Server Administration Console.
To create server templates using WLST, see Example 5-2. To create server templates using the WebLogic Server Administration Console, see Create server templates in the Oracle WebLogic Server Administration Console Online Help.
To configure server templates, you can use any of the administration tools listed in Summary of System Administration Tools and APIs in Understanding Oracle WebLogic Server.
If required, you can define server-specific attributes or override any server template value directly in the individual server definition. For example, some server-specific attributes, such as Notes, ConsensusProcessIdentifier, InterfaceAddress, and so on, are more useful when defined at the individual server level.
A server template contains different types of attributes, including primitive datatypes, singleton elements, and arrays of configuration elements. To override a server template value, you define the attribute in the individual server definition.
WebLogic Server determines which attribute value to use based on the following override hierarchy:
If you do not define an attribute in the individual server configuration or in the server template, then the default value is used.
If you define an attribute in the server template, then the server template overrides the default value. The server template value is used.
If you define an attribute in the individual server configuration, then the server configuration overrides the server template value and the default value. The individual server configuration value is used.
Note:
Once you override a value in the individual server configuration, this value always takes precedence over the value in the server template. To remove the overridden value and use the value in the server template, use the unSet attribute command.
At runtime, the domain merges the attributes defined in the server template and individual server definitions to return the desired configuration.
A server instance can override attributes from a server template, but the overrides for each type of attribute differ. For primitive datatypes, the server configuration value overrides the value in the server template. For example, if the server template defines the listen port to be 7101, but you set an explicit listen port value in the server configuration, the server instance value overrides the server template listen port value.
A server instance also overrides values for attributes contained within a child singleton element. For example, if the server template defines a common root directory value in the <server-start> child element, but you set an explicit root directory value in the <server-start> element in the server configuration, the server instance overrides the server template root directory value.
For child array configuration elements, the server instance cannot override individual child elements or attributes within a child element within an array. The server configuration can only override the entire array of configuration elements. For example, if a server template defines an array of NetworkAccessPoint elements, and the server instance configuration defines an array of NetworkAccessPoints, the server instance NetworkAccessPoints override the values in the server template.
The following example demonstrates overriding NetworkAccessPoints in a server instance by using WLST, and includes inline comments.
#
#A server template named Cluster Template defines a NetworkAccessPoint named
#AccessPoint-1. The server instance s1 references Cluster Template as its
#template. A ls() command on s1 shows the following:
#
wls:/mydomain/edit/Servers/s1/NetworkAccessPoints !> ls
drw- AccessPoint-1
#
#Server instance s1 then defines a NetworkAccessPoint at the server instance
#level.
#
wls:/mydomain/edit/Servers/s1 !>
cmo.createNetworkAccessPoint("AccessPoint-2")
#
#This results in an override of the NetworkAccessPoints from the Cluster Template.
#AccessPoint-1 is no longer present in s1 and only AccessPoint-2 is defined in s1.
#
wls:/mydomain/edit/Servers/s1/NetworkAccessPoints !> ls
drw- AccessPoint-2Server templates contain common attributes and provide the same values for each server instance that inherits configuration from the template. In some cases, you may want to define a standard value for an attribute, but the value must be slightly different for each server instance. You can define the server-specific attribute value in each server instance, but if the attribute follows a pattern, you may be able to use a macro.
You can define a macro for any string attribute in a server template. Macros are case sensitive and cannot be used for integers or references to other configuration elements. The valid macros available for use in server templates are:
${id}: Instance ID of the dynamically created server; this ID starts at 1.
${serverName}: The name of the server to which this element belongs.
${clusterName}: The name of the cluster to which this element belongs. If this element does not belong to a cluster, then an empty string is substituted.
${domainName}: The name of the domain to which this element belongs.
${system-property-name}: If this is not one of the predefined macro names listed previously, then it is evaluated as a system property, and the value is returned. If the system property does not exist, then an empty string is substituted.
Examine an example that demonstrates using WLST to create two server instances that use the same server template.
Example 5-2 includes inline comments and describes how to:
Create a server template and name it my-cluster-server-template.
Set all of the common attributes in my-cluster-server-template.
Create server instances my-server1 and my-server2, and assign the my-cluster-server-template to each one.
Set server-specific attributes.
Example 5-2 Using Server Templates with WLST
#
# This example demonstrates the WLST commands needed to create a server template
# (my-cluster-server-template) and server instances (my-server-1, my-server-2)
# that use the server template. The creation of the cluster (my-cluster) and
# machines (PrimaryMachine, SecondaryMachine) are not included in this example;
# they must be created before running this script. To keep this example
# simple, error handling was omitted.
#
connect()
edit()
startEdit()
#
# Create the server template and set the common attributes that are used in all
# servers. Attributes such as Accept Backlog, Auto Restart, etc. are the same
# across all cluster members.
#
serverTemplate=cmo.createServerTemplate("my-cluster-server-template")
serverTemplate.setAcceptBacklog(2000)
serverTemplate.setAutoRestart(true)
serverTemplate.setRestartMax(10)
serverTemplate.setReverseDNSAllowed(true)
serverTemplate.setStagingMode("external_stage")
serverTemplate.setStartupTimeout(600)
myCluster=cmo.lookupCluster("my-cluster")
serverTemplate.setCluster(myCluster)
#
# Create the individual server instances, set the server specific attributes, and
# set the template so the server uses the common attributes from the template.
# Attributes such as cluster weight, listen port, and machine are server-specific
# so they are not included in the server template.
#
server1=cmo.createServer("my-server-1")
server1.setClusterWeight(70)
server1.setListenPort(7010)
primary=cmo.lookupMachine("PrimaryMachine")
server1.setMachine(primary)
server1.setServerTemplate(serverTemplate)
#
server2=cmo.createServer("my-server-2")
server2.setClusterWeight(90)
server2.setListenPort(7020)
secondary=cmo.lookupMachine("SecondaryMachine")
server2.setMachine(secondary)
server2.setServerTemplate(serverTemplate)
#
# activate the changes
#
activate()
The resulting config.xml file is:
<server>
<name>my-server-1</name>
<cluster-weight>70</cluster-weight>
<listen-port>7010</listen-port>
<machine>PrimaryMachine</machine>
<server-template>my-cluster-server-template</server-template>
</server>
<server>
<name>my-server-2</name>
<cluster-weight>90</cluster-weight>
<listen-port>7020</listen-port>
<machine>SecondaryMachine</machine>
<server-template>my-cluster-server-template</server-template>
</server>
<server-template>
<name>my-cluster-server-template</name>
<accept-backlog>2000</accept-backlog>
<auto-restart>true</auto-restart>
<cluster>my-cluster</cluster>
<restart-max>10</restart-max>
<reverse-dns-allowed>true</reverse-dns-allowed>
<staging-mode>external_stage</staging-mode>
<startup-timeout>600</startup-timeout>
</server-template>