HCL Workload Automation Agent

What is the HCL Workload Automation Agent?

HCL Workload Automation Agent is a fully-featured version of the Dynamic Agent component of HCL Workload Automation Agent with the following restriction:

Supported tags

This sample readme file contains the following sections:

Getting Started

Docker compose

Download and install Docker compose. We recommend version 2.3 in order to take advantage of named volumes.

OpenShift

Install Red Hat OpenShift v3.10 or later.

Accessing the container images

You can access the agent container image from the Entitled Registry:

  1. Contact your HCL sales representative for the login details required to access the Entitled Registry.
  2. Run the following command to log into the Entitled Registry:
    docker login -u <your_username> -p <your_entitlement_key> hclcr.io 

Starting the HCL Workload Automation Agent container

If you want to start the container via Docker Compose, use the following command to clone the current repository:

git clone https://github.com/WorkloadAutomation/hcl-workload-automation-docker-compose

If you do not have GitHub installed in your environment, download the ZIP file from the main page of the repository:

Click on "Code" and then select "Download ZIP"

In the directory where the docker-compose.yml file has been located, you can start the container by running the following command:

docker-compose up -d wa-agent

Once the command has been launched, be sure that the container is started by checking the docker logs; the container configuration is completed when the “wa agent started” message is shown.

Note: To use custom certificates, you need to modify the volume <path_on_host_containing_certs>:/opt/wautils/certs writing the path of the directory that contains your certificates at the place of <path_on_host_containing_certs>. In the defined folder you need to add the following certificates:

  - TWSClientKeyStore.kdb
  - TWSClientKeyStore.sth
  - TWSClientKeyStoreJKS.jks
  - TWSClientKeyStoreJKS.sth 

Example of variable: - LICENSE=ACCEPT

You can find the other available variables in the following table:

Variable Description Mandatory Example
LICENSE Use ACCEPT to agree to the license agreement yes notaccept
SERVERHOSTNAME The hostname of the master domain manager yes wamdm.demo.com
SERVERPORT The HTTPS port that the dynamic agent must use to connect to the master domain manager. The default value is 31116 yes 31116
AGT_NAME The workstation name of the dynamic agent to be run. The default value is WA_AGT no WA_AGT
LANG The language of the container internal system. The supported language are: en (English), de (German), es (Spanish), fr (French), it (Italian), ja (Japanese), ko (Korean), pt_BR (Portuguese (BR)), ru (Russian), zh_CN (Simplified Chinese) and zh_TW (Traditional Chinese) yes en
POOLS The static pools of which the Agent should be a member no Pool1, Pool2
BKMSERVERHOSTNAME The hostname of the backup master domain manager no wabkm.demo.com
MAXWAITONEXIT The number of seconds the Agent waits for the completion of all processes before stopping the container. The Default value is 60 sec, the maximum value is 3600 sec no 60 sec
TZ If used, it sets the TZ operating system environment variable no Europe/Rome

Note: The Dynamic Agent component (also the one included in the Workload Automation Server container) is deployed and configured with gateway.

Deploying and starting the HCL Workload Automation Agent container on OpenShift

Note: Pay attention to indentation when uncommenting the object and parameter sections.

Variable Description Mandatory Example
IMAGE The name of the HCL Workload Automation Agent Agent Docker image yes hcl-workload-automation-agent-dynamic:9.5.0.01
PULL_POLICY The Docker image pull policy (Always/ IfNotPresent/Never) yes Always
INSTANCE_NAME The application instance name yes
REPLICA_COUNT The number of replicas to deploy yes 1
STORAGE_CLASS The name of the StorageClass to be used. Leave empty to not use a storage class no
WA_DEBUG The container is executed in debug mode to keep container running in case of errors yes false
PV_LABEL_NAME (*) The Persistent Volume label name to bind (only limited to single label) yes
PV_LABEL_VALUE (*) The Persistent Volume label value to bind (only limited to single value) yes
CUSTOM_CERT_SECRET (**) The name of the secret to store customized SSL certificates yes waagent-cert-secret

(*) The parameters are available only if the “BEGIN SECTION - PV Selector” sections have been uncommented in the openshift-template.yml file. If commented, they are ignored.

(**) The parameters are available only if the “BEGIN SECTION - Certificates’ Secret” sections have been uncommented in the openshift-template.yml file. If commented, the default certificates are used.

Certificates’ Secret

If you want to use custom Agent certificates, uncomment the "BEGIN SECTION - Certificates' Secret" sections in the **openshift-template.yml** file, and create the secret in the same namespace where you want to deploy the objects:   
 
  oc create secret generic release_name-secret --from-file=TWSClientKeyStoreJKS.jks --from-file=TWSClientKeyStoreJKS.sth --from-file=TWSClientKeyStore.kdb --from-file=TWSClientKeyStore.sth


where TWSClientKeyStoreJKS.jks  TWSClientKeyStoreJKS.sth  TWSClientKeyStore.kdb  TWSClientKeyStore.sth are the container keystore and stash file containing your customized certificates.
For details about custom certificates, see the [online](https://workloadautomation.hcldoc.com/help/topic/com.hcl.wa.doc_9.5/distr/src_ad/awsadsslddmda.htm) documentation.

See an example where `release_name` = myname and `namespace` = default: 

  oc create secret generic myname-secret --from-file=TWSClientKeyStore.kdb --from-file=TWSClientKeyStore.sth
  
> **Note**: Customized certificates must have the same name of the ones listed above.

Storage

To make persistent all configuration and runtime data, the Persistent Volume you specify is mounted in the following container folder:

/home/wauser

The Pod is based on a StatefulSet. This to guarantee that each Persistent Volume is mounted in the same Pod when it is scaled up or down.

You can pre-create Persistent Volumes to be bound to the StatefulSet using Label or StorageClass. Anyway, it is highly suggested to use persistence with dynamic provisioning. In this case you must have defined your own Dynamic Persistence Provider.

Supported Docker versions

This image is officially supported on Docker version 1.11.0 and later.

Support for versions earlier than 1.11.0, is provided on a best-effort basis.

Please see the Docker installation documentation for details on how to upgrade your Docker daemon.

Limitations

The owner of all product files is the wauser user, thus the product does not run as root, but as wauser only. Do not perform the login as root to start processes or execute other commands, otherwise it might create some issues.

Limited to amd64 platforms.

Additional Information

For additional information on using the HCL Workload Automation Agent, see the online documentation. For technical issues, search for Workload Scheduler or Workload Automation on StackOverflow.

License

The Dockerfile and associated scripts are licensed under the Apache License 2.0. HCL Workload Automation Agent is licensed under the HCL International Program License Agreement. This license for HCL Workload Automation Agent can be found online. Note that this license does not permit further distribution.