Set variables for Liberty servers

We must set one or more WebSphere variables before we can use the job manager to remotely install and manage Liberty servers. We can set the variables in an administrative console, a wsadmin script, or the registerHost command. The variables specify the root directories to which to install Liberty resources and specify search paths for finding resources that are not yet registered with the job manager.

Liberty resources include projects, software development kits (Java runtime environments), Liberty runtimes, servers, and applications. See Liberty resources.

If we are using an administrative console, wsadmin, or the registerHost command to set values for Liberty server variables, start the job manager or the deployment manager.

We can specify values for WebSphere variables and built-in variables.

WebSphere variables

Before installing Liberty resources using the job manager, we must set one or more WebSphere variables. The amount of configuration depends on the topology being deployed. We can set values for variables using the job manager console, deployment manager console, wsadmin, or registerHost command.

We can install Liberty resources to a working, non-shared location or to a shared location. Do not share resources installed to the working location.

Resources installed to a shared location can be used by Liberty servers installed to a working location. For example, we can configure working Liberty servers to use one or more of the following types of shared resources:

• Liberty runtime
• Software development kit
• Application

Install resources in shared locations as read-only. We can share resources within a host or across hosts using disk sharing approaches such as Network File System (NFS).

During resource installation, unless there is a name conflict, the resources in the Liberty compressed file are extracted to the working root directory specified by WLP_WORKING_DIR or to the shared directory specified by WLP_SHARED_DIR.

Default variables	Description
WLP_WORKING_DIR	The installation or inventory search path for nonshared working Liberty resources. If a job submission does not specify that the installation or search directory be shared, then the job uses this variable. By default, Liberty resources are installed to the nonshared working directory that this variable defines. Specify an absolute path for this variable. Do not specify a relative path.
WLP_SHARED_DIR	The installation or inventory search path for shared Liberty resources. If a job submission specifies that the installation or search directory be shared, then the job uses this variable. Specify an absolute path for this variable. Do not specify a relative path.
WLP_ADDITIONAL_DIRS	(optional) Specifies additional paths to search for Liberty resources beyond the paths included in the WLP_SHARED_DIR and WLP_WORKING_DIR variables. Configure the additional search paths for Liberty resources to: Search for previously installed software development kits that are managed separately from the job manager. Search for any server resources that are not installed in the default working and shared directories. For example, we might define different installation locations relative to the home directories of several different users. See descriptions of the HOME and USER variables. Specify an absolute path for this variable. Do not specify a relative path.

Built-in variables

When we use the job manager to remotely install and manage Liberty servers, we can set the following built-in variables to customize installation locations and Liberty configuration files based on operating system home directory, operating system user, host name, and project membership:

HOME

Contains the home directory of the operating system user name used to submit an Install Liberty resources job. Use the HOME variable to set up a working directory that is relative to the home directory of the submitting user; for example:

WLP_WORKING_DIR=${HOME}/working

USER

Contains the name of the operating system user used to submit an Install Liberty resources job. Use the USER variable to set up a working directory for each user, relative to a global directory; for example:

WLP_WORKING_DIR=/working/${USER}

When using the HOME variable or the USER variable to customize the installation location, configure the WLP_ADDITIONAL_DIRS variable with the specific directories for each user; for example:

WLP_ADDITIONAL_DIRS=/usr/home/user1;/usr/home/user2

If we do not include the directories in the WLP_ADDITIONAL_DIRS variable, inventory jobs do not locate the associated Liberty resources on the target hosts.

HOSTNAME

Contains the configured host name of the target host where an Install Liberty resources job is run. Use the HOSTNAME variable in the server bootstrap.properties file; for example:

hostname=${HOSTNAME}

We can then use the hostname variable in the server configuration file, server.xml; for example:

<httpEndpoint host="${hostname}" httpPort="9081" httpsPort="9444" id="defaultHttpEndpoint"/>

CURRENT_PROJECT

Contains the name of the project that is included in the Liberty resources compressed file.

Tasks

We can set WebSphere variables for all target hosts at a specified scope or set WebSphere variables at a target host level.

• Set WebSphere variables for all target hosts at a specified scope.

  Use any of the following methods to set WebSphere variables for all target hosts at a specified scope:

  • Set variables using an administrative console.
    1. In a job manager console or a deployment manager console, click Environment > WebSphere variables.

    2. Specify the cell, node, or server scope. In most cases, we can select the cell scope.

    3. Click New.

    4. For Name, specify a Liberty variable name such as WLP_WORKING_DIR.

    5. For Value, specify the installation and inventory search path, such as c:/resources.

    6. Save the changes.

    7. To set additional variables, repeat these steps.

  • Set variables using the wsadmin scripting tool.

    Use the AdminConfig create command to set variables at the cell, node, or server scope.

    1. Open a command prompt at the bin directory of the job manager profile.

    2. Start the wsadmin tool and use the Jython scripting language.

       wsadmin -lang jython
       

    3. Run the AdminConfig create command. Specify the scope, variable name, and variable value. In most cases, we can define the variable at the cell scope.

       For example, set a cell-scoped WLP_WORKING_DIR variable to the c:/working directory:

       AdminConfig.create('VariableSubstitutionEntry', '(cells/cell|variables.xml#VariableMap_1)',
        '[[symbolicName "WLP_WORKING_DIR"] [description ""] [value "c:/working"]]')
       

    4. Save the variable changes.

       AdminConfig.save()
       

    5. To set additional variables, repeat these steps.
    6. End the wsadmin session.

       quit
       

• Set WebSphere variables at the target host level.

  Use the following methods to set WebSphere variables at the target host level, thereby overriding the same variables set at a higher level scope, if they exist:

  • Set variables in the host properties when registering a host with the registerHost command.

    1. Open a command prompt at the bin directory of the job manager profile or the deployment manager profile.

    2. Start the wsadmin tool and use the Jython scripting language.

       wsadmin -lang jython
       

    3. Run an AdminTask registerHost command that specifies the variable name and value.

       For example, set the WLP_WORKING_DIR variable to use the C:/liberty directory:

       AdminTask.registerHost('-host host_name
         -hostProps [[username admin][password password]
           [saveSecurity true][WLP_WORKING_DIR C:/liberty]]')
       

       For more information on registerHost, see Registering host computers with job managers.

    4. Save the changes.

  • To later change a variable, we can use the AdminTask modifyManagedNodeProperties command.

    For example, set the WLP_WORKING_DIR variable to use the C:/liberty2 directory:

    AdminTask.modifyManagedNodeProperties('-managedNodeName host_name
     -managedNodeProps "[WLP_WORKING_DIR C:/liberty2]"')
    

After we save the changes, the changes are viewable in the list of variables on a console WebSphere variables page.

After we have defined the variables, see Packaging Liberty resources for information on how to properly package files for the Install Liberty resources job. If we use Installation Manager to install Liberty, create a subdirectory under the location of WLP_WORKING_DIR. This directory will be used to identify this instance of the Liberty runtime. Use this directory as the installation directory during installation with Installation Manager. If WLP_WORKING_DIR is set to /liberty/working, for example, create a runtime_1 subdirectory; then, use /liberty/working/runtime_1 as the installation directory during installation using Installation Manager.

What to do next

We can now submit a job that installs resources from a Liberty resources compressed file, as well as an inventory job that searches for previously existing Liberty resources.

We can later set variables that override the values of variables for different target hosts or substitute user-defined variables:

• We can choose to override the values of Liberty variables on individual hosts by changing the target properties for each host. First, define the appropriate default WebSphere variables at a higher-level scope, for example:

  WLP_SHARED_DIR=/shared
  WLP_WORKING_DIR=/working
  WLP_ADDITIONAL_DIRS=...
  

  Then, override the values of these variables for each target that differs from the default value. For example, if most of our hosts are on AIX, HP-UX, Linux or Solaris operating systems, with some Windows hosts in the environment, after registering each Windows host, we can add the following host properties:

  WLP_SHARED_DIR=c:/shared
  WLP_WORKING_DIR=c:/working
  

• We can edit target host specific properties to substitute a user-defined variable for individual targets. Substituting a user-defined variable is useful when we have multiple network interfaces on each target, and we want to specify which one to use for each target. We can define this variable in a server bootstrap.properties file; for example:

  hostname=${hostname.interface1}
  

  For each target, define the actual value of the user-defined variable in the target host specific properties of that host. For example, for host1, define the value of the interface as hostname.interface1=host1.xyz.com and define host2 as hostname.interface1=host2.xyz.com.

Related:

Liberty resources

Submitting jobs to deploy and manage Liberty installations

Registering host computers with job managers

Install Liberty resources using the job manager

Restart the job manager

Packaging Liberty resources

Administrative job types