+

Search Tips   |   Advanced Search

Automate server administration using the scripting library



Overview

The scripting library provides Jython script procedures to assist in automating the environment. Use the server management scripts to configure servers, the server runtime environment, Web containers, performance monitoring, and logs. We can also use the scripts to administer the servers.

There are three ways to use Jython script library...

The AdminServerManagement procedures in scripting library are located in...

WAS_HOME/scriptLibraries/servers/V70

Each script from the directory automatically loads when you launch wsadmin.sh. To automatically load the own Jython scripts (*.py) when wsadmin.sh starts, create a new subdirectory and save existing automation scripts under the WAS_HOME/scriptLibraries directory.

Best practice: To create custom scripts using the scripting library procedures, save the modified scripts to a new subdirectory to avoid overwriting the library. Do not edit the script procedures in the scripting library

Use the AdminServerManagement.py scripts to perform multiple combinations of administration functions. This page provides one sample combination of procedures. Use the following steps to create an appserver, connect the appserver to the AdminService interface, configure Java ™ virtual machine (JVM) settings, add the application server to a cluster, and propagate the changes to the node.

 

  1. Launch wsadmin.sh. Use this step to launch wsadmin.sh and connect to a server, job manager, or administrative agent profile, or run the tool in local mode. If we launch wsadmin.sh, use the interactive mode examples in this topic to run scripts.

    • Enter the following command from the bin directory to launch wsadmin.sh and connect to a server:

        cd $WP_PROFILE/bin
        ./wsadmin.sh -lang jython

    • To launch wsadmin.sh in local mode and using Jython:

        cd $WP_PROFILE/bin
        ./wsadmin.sh -conntype none -lang jython

    When wsadmin.sh launches, the system loads all scripts from the scripting library.

  2. Create an appserver. Run the createApplicationServer script procedure from the AdminServerManagement script library...

      ./wsadmin.sh -lang jython -c "AdminServerManagement.createApplicationServer("myNode", "myServer", "default")"

    We can also use interactive mode to run the script procedure...

      cd $WP_PROFILE
      ./wsadmin.sh -lang jython
      wsadmin.sh>AdminServerManagement.createApplicationServer("myNode", "myServer", "default")

  3. Connect the appserver of interest to the AdminService interface. The AdminService interface is the server interface to the appserver administration functions. To connect the application server to the AdminService interface, run the configureAdminService script procedure from the AdminServerManagement script library, specifying the node name, server name, and connector type arguments, as the following example demonstrates:

      wsadmin.sh -lang jython -c "AdminServerManagement.configureAdminService("myNode", "myServer", "IPC", "JSR160RMI")

    We can also use interactive mode to run the script procedure...

      wsadmin.sh>AdminServerManagement.configureAdminService("myNode", "myServer", "IPC", "JSR160RMI")

  4. Set the JVM.

    As part of configuring an appserver, we might define settings that enhance the way the operating system uses of the JVM. The JVM is an interpretive computing engine responsible for running the byte codes in a compiled Java program. The JVM translates the Java byte codes into the native instructions of the host machine. The appserver, being a Java process, requires a JVM in order to run, and to support the Java applications running on it. Run the configureJava VirtualMachine script procedure from the AdminServerManagement script library, specifying the node name, server name, whether to run the JVM in debug mode, and any debug arguments to pass to the JVM process. You can optionally specify additional configuration attributes with an attribute list. Use the following example to configure the JVM: 

    wsadmin.sh -lang jython \
           -c "AdminServerManagement.configureJavaVirtualMachine("myNode", \
           "myServer", \
           "true", \
           "mydebug", \
           [["internalClassAccessMode", \
           "RESTRICT"],      \
           ["disableJIT", \
           "false"], \
           ["verboseModeJNI", \
           "false"]])"

    You can also use interactive mode to run the script procedure, as the following example demonstrates: 

    AdminServerManagement.configureJavaVirtualMachine("myNode", \
    "myServer", \
    "true", \
    "mydebug", \
    [["internalClassAccessMode", \
    "RESTRICT"],      \
    ["disableJIT", \
    "false"], \
    ["verboseModeJNI", \
    "false"]])

  5. Create a cluster, and add the appserver as a cluster member.

    Run the createClusterWithFirstMember script procedure from the AdminClusterManagement script library... 

    bin>wsadmin.sh -lang jython 
                  -c "AdminClusterManagement.createClusterWithFirstMember("myCluster", 
                  "APPLICATION_SERVER", 
                  "myNode", 
                  "myServer")"


    wsadmin.sh>AdminClusterManagement.createClusterWithFirstMember("myCluster", 
   "APPLICATION_SERVER", 
   "myNode", 
   "myServer")

  6. Synchronize the node.

    To propagate the configuration changes to the node, run the syncNode script procedure from the AdminNodeManagement script library, and specify the node of interest... 

    bin>wsadmin.sh -lang jython 
                  -c "AdminNodeManagement.syncNode("myNode")"

    You can also use interactive mode to run the script procedure, as the following example displays: 

    wsadmin.sh>AdminNodeManagement.syncNode("myNode")

 

Results

The wsadmin.sh script libraries return the same output as the associated wsadmin commands. For example, the AdminServerManagement.listServers() script returns a list of available servers. The AdminClusterManagement.checkIfClusterExists() script returns a value of true if the cluster exists, or false if the cluster does not exist. If the command does not return the expected output, the script libraries return a 1 value when the script successfully runs. If the script fails, the script libraries return a -1 value and an error message with the exception. By default, the system disables failonerror option. To enable this option, specify true as the last argument for the script procedure, as the following example displays:

 

What to do next

Create custom scripts to automate the environment by combining script procedures from the scripting library. Save custom scripts to a new subdirectory of the WAS_HOME/scriptLibraries directory.


Server settings configuration scripts
Server configuration scripts
Server query scripts
Server administration scripts

 

Related tasks

Use the script library to automate the application serving environment

 

Related

Node administration scripts
Cluster configuration scripts