HCL Workload Automation Agent is a fully-featured version of the Dynamic Agent component of HCL Workload Automation Agent with the following restriction:
This sample readme file contains the following sections:
Download and install Docker compose. We recommend version 2.3 in order to take advantage of named volumes.
Install Red Hat OpenShift v3.10 or later.
You can access the agent container image from the Entitled Registry:
docker login -u <your_username> -p <your_entitlement_key> hclcr.io
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.
If you want to modify default values that are not shown as parameters, modify your existing openshift-template.yml file.
If you want to use customized certificates or bind a persistent volume using labels, modify your existing openshift-template.yml file by uncommenting the related sections. For further details, see the table below.
Note: Pay attention to indentation when uncommenting the object and parameter sections.
Import the template objects contained in the openshift-template.yml file in the OpenShift console; if you are using the OpenShift command line, create them by launching the following command:
oc create -f <file_name>
where <file_name> is **openshift-template.yml**.
Configure the parameters listed in the table above, and the following additional ones specific to OpenShift:
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.
Deploy the objects defined in the openshift-template.yml; if you are using the OpenShift command line, deploy them by launching the oc process command. For example:
oc process <template_name> -p LICENSE=ACCEPT -p INSTANCE_NAME=<instance_name> -p SERVERHOSTNAME=<serverhostname> -p IMAGE=<image_name> | oc create -f -
where <template_name> is the template name defined in the **openshift-template.yml** file
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.
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.
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.
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.
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.
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.