Deploy resources with Admin Center

We can use the Deploy tool to install Liberty profile server package (archive) files on hosts within a collective. Then, use the Explore tool to manage the servers.

• The Admin Center feature must be installed and configured on a Liberty profile server that also includes the collective controller feature and all required security configuration.

  To create a Liberty profile collective that includes the hosts to which we plan to deploy the Liberty profile installation, see the following topics:

  • Configure a Liberty collective -- To enable Admin Center on the collective controller, server.xml of the collective controller must include <feature>adminCenter-1.0</feature> in the feature manager configuration. Also, server.xml must set a host value in the httpEndpoint element; for example, add host="*" so all hosts can access the collective controller.

  • Register host computers with a Liberty collective -- The registerHost command must include a hostWritePath parameter that sets the path to which to deploy a server package. We specify this same path for Target Directory when using the Deploy tool. If a host is already registered, we can use the updateHost command to reset the hostWritePath information.

  Each host must include Java support for the jar utility, and optionally an unzip utility, in the environment (path) of the Remote Procedure Call (RPC) user specified during registration of the host.

• The Liberty profile environment to deploy must be compressed into a server package in the ZIP, JAR, or PAX format. The server package must meet the following requirements:

  • The server package includes, at minimum, a Liberty profile run time and a server. The server package can include other resources, such as a web application that runs on the server.

  • The top-level directory in the server package must be wlp, and it must contain the standard Liberty profile directories (bin, clients, dev, lafiles, lib, templates, usr). The usr directory must reside in the default location, and all servers must use the default output directory.

  • Included servers must not contain any collective membership configuration settings or keystorefiles.

  Available tools for packaging archives include:

  • The Liberty profile server package command. Sample command syntax is:
    wlp/bin/server package myServer --include=all | minify --archive=myServer.zip | jar | pax

  • The package action in the WebSphere Developer Tools for Eclipse product.

  We might need to customize the installation, for example, by changing port numbers, database connections, or messaging system connections.

After you define the Liberty profile collective and create the server package, use the Deploy tool to install the server package on hosts within the collective.

See Example: Configure a collective controller, registering a host, creating a server package, and deploying the server package for an example of deploying a server package to a localhost Windows computer.

1. Go to the Deploy tool.

   • From the Toolbox, select

     .

   • From details on hosts in the Explore tool, select

     > one_or_more_host_names > Deploy Server Package.

   To directly launch the Deploy tool in the future, we can use the URL that is shown in the browser when viewing the Deploy tool.

2. For Target Hosts, select the host computers on which to install the server package. Move target hosts from Available hosts to Selected hosts.

   Each target host must be registered with the collective managed by Admin Center. See Register host computers with a Liberty collective.

3. For Server Package, select whether to upload a server package file or use a server package file on a collective controller. Then, specify the file path.

4. For Target Directory, specify a target directory for the Liberty profile installation. If the directory exists, it must be empty. If the directory does not exist, the product creates it as file system permissions permit.

   For server package ZIP or JAR formats, specify the installation directory. For example, specify /home/user1/liberty for the product to upload the server package to /home/user1 and unzip to the liberty directory.

   For server package PAX formats, specify the installation directory and PAX file name. For example, specify /home/user1/liberty/package_name.pax for the product to expand the archive to the /home/user1/liberty/package_name.pax directory.

   The RPC user of each target host must have read and write access to the parent of the installation directory.

5. For KeyStore Password, specify a password to protect newly generated keystorefiles containing server authentication credentials. The same password is used for all deployed servers.

   The product generates keystorefiles in the resources directory of each deployed server.

6. For Remote Management Credentials, specify how the collective controller will connect to each target host to remotely manage the deployed servers.

   • If all target hosts are registered with the collective controller, we can choose the default option, Use the connection method and credentials configured for each target host.

     Restriction: We cannot use the Use the connection method and credentials configured for each target host option to deploy an 8.5.5.3 or earlier server package. The server package must support Liberty profile 8.5.5.4 or later.

   • If all target hosts support SSH, we can choose Use automatically-generated SSH keys for each server.

   • If any target host runs on a Windows operating system or otherwise does not support SSH, or if we do not want to use SSH keys, choose Use the following operating system user name and password on each target host and specify the operating system login user name and password. The operating system user must possess file system privileges for operating Liberty profile servers in the installation. All files in a deployed installation are owned by the operating system user who registered the respective target host with the collective. Specifying a different operating system user for Remote Management Credentials does not change ownership of the files.

7. For Password, specify the password that we used to log in to Admin Center. The operation to join the deployed servers to the collective is run with the Liberty administrative user name and password.

8. Select Deploy.

Results

The Deploy action runs. Select

on a desktop or tablet, or

on a smartphone, for status on the deployment.

Example: Configure a collective controller, registering a host, creating a server package, and deploying the server package

This example describes how to install a Liberty profile server package on a Windows host within a collective using the Deploy tool.

• Create a collective controller that uses Admin Center and start the collective controller.

• Run the registerHost command to register a host computer with the collective controller.

• Create a server package to install using the Deploy tool.

• Install the server package using the Deploy tool.

Configure a collective controller, register a host with the collective controller, and package a server before using the Deploy tool.

• Create a collective controller that uses Admin Center and start the collective controller.

  1. Create a server. This example names the server myController.
     wlp/bin/server create myController

  2. Create a collective controller.
     wlp/bin/collective create myController --keystorePassword=myControllerPwd

  3. Open an editor on the myController server.xml file and make the following changes:

     • Add the generated collective controller configuration to the myController server.xml file. For example, copy output from the collective command and paste it after the httpEndpoint element and before </server>, the last tag of server.xml.

     • Add the adminCenter-1.0 feature to the feature manager.

       <featureManager>
               <feature>jsp-2.2</feature>
               <feature>adminCenter-1.0</feature>
       </featureManager>

     • Add a host value to the httpEndpoint element of the myController server.xml file. For example, add host="*" so all hosts can access the controller.

       <!-- To access this server from a remote client add a host
        attribute to the following element, e.g. host="*" -->
       <httpEndpoint id="defaultHttpEndpoint"
                     host="*"
                     httpPort="9080"
                     httpsPort="9443" />

     • Specify values for userName and userPassword.
       <quickStartSecurity userName="admin" userPassword="adminpwd" />

       If user names or passwords include non-English characters, create the jvm.options file for the server and define the default client encoding as UTF-8:

       -Ddefault.client.encoding=UTF-8

       If the user registry is in quickStartSecurity or basicRegistry elements, which store user names and passwords in server.xml, then save server.xml in UTF-8 encoding. For information about the jvm.options file, see Customize the Liberty profile environment.

  4. Start the controller.
     wlp/bin/server start myController

• Run the registerHost command to register a host computer with the collective controller.

  For this example, the collective controller is running on the localhost computer, which has a hostname of winHost. The computer uses a Windows operating system, which does not support SSH, so the command must specify an RPC user and password.

  wlp/bin/collective registerHost winHost --host=localhost --port=9443 --user=admin --password=adminpwd --rpcUser=myWindowsLoginID --rpcUserPassword=myWindowsLoginPwd --hostWritePath=c:\wlp_example

  The command does the following:

  • Registers the localhost computer with the collective controller.

  • For user and password, specifies the userName and userPassword values set in the myController server.xml file.

  • Operating system login user for rpcUser and the operating system user password for rpcUserPassword.

  • Sets hostWritePath to the path of the directory to which the Deploy tool installs the server package.

  When prompted, type y to accept the certificate chain.

  If you later want to change these settings, we can use the collective updateHost command.

• Create a server package to install using the Deploy tool.

  1. If we do not have an existing server to package, run the create command to create a new server.
     wlp/bin/server create server1

  2. If we have an existing server to package, ensure the server to package is stopped.

  3. Run the package command to create the server package.
     wlp/bin/server package server1

     The command creates a server package named, for example, C:\wlp\usr\servers\server1\server1.zip.

• Install the server package using the Deploy tool.

  1. Launch the Deploy tool from the Toolbox or from the Explore tool host page. See Logging in to Admin Center.

  2. For Target Hosts, move the target host, winHost, from Available hosts to Selected hosts.

  3. For Server Package, select to use a server package file on a collective controller. Then, specify the file path, C:\wlp\usr\servers\server1\server1.zip.

  4. For Target Directory, specify the directory set for hostWritePath in the registerHost command, c:\wlp_example\member.

  5. For KeyStore Password, specify a password to protect newly generated keystorefiles containing server authentication credentials. The same password is used for all deployed servers. For example, specify serverpwd.

  6. For Remote Management Credentials, specify how the collective controller will get the host operating system login credentials to remotely manage the deployed servers. For this example that uses a Windows host computer, we have two choices. We can choose Use the connection method and credentials configured for each target host because the target host is registered with the collective controller. Or, we can choose Use the following operating system user name and password on each target host and then specify the operating system login user and login user password.

  7. For Password, specify the password that we used to log in to Admin Center.

  8. Select Deploy.

What to do next

For details about the status of the deployment on a desktop or tablet, select

on the title bar.

To view the status on a smartphone, select

.

On the Background Tasks page, we can view a summary of all running background tasks and access a detailed history of running, stopped, and completed background tasks. See Monitoring background tasks.