You can use Amazon Elastic Kubernetes Service (EKS) to run HCL Workload Automation containers on Amazon Web Services (AWS).

HCL Workload Automation is a complete, modern solution for batch and real-time workload management. It enables organizations to gain complete visibility and control over attended or unattended workloads. From a single point of control, it supports multiple platforms and provides advanced integration with enterprise applications including ERP, Business Analytics, File Transfer, Big Data, and Cloud applications.

As more and more organizations move their critical workloads to the cloud, there is an increasing demand for solutions and services that help them easily migrate and manage their cloud environment.

To respond to the growing request to make automation opportunities more accessible, HCL Workload Automation can be deployed on the Amazon Web Services cloud.

The information in this README contains the steps for deploying the following HCL Workload Automation components using a chart and container images:

HCL Workload Automation, which comprises master domain manager and its backup, Dynamic Workload Console, and Dynamic Agent

For more information about HCL Workload Automation, see the product documentation library in HCL Workload Automation Infocenter.

By default, a single server (master domain manager), Dynamic Workload Console (console) and dynamic agent is installed.

To achieve high availability in an HCL Workload Automation environment, the minimum base configuration is composed of 2 Dynamic Workload Consoles and 2 servers (master domain managers). For more details about HCL Workload Automation and high availability, see:

An active-active high availability scenario.

HCL Workload Automation can be deployed across a single cluster, but you can add multiple instances of the product components by using a different namespace in the cluster. The product components can run in multiple failure zones in a single cluster.

In addition to the product components, the following objects are installed:

Data encryption:

• Data in transit encrypted using TLS 1.2
• Data at rest encrypted using passive disk encryption.
• Secrets are stored in an approved Kubernetes Secrets.
• Logs are clear of all sensitive information.

• Amazon Elastic Kubernetes Service (EKS) on amd64: 64-bit Intel/AMD x86

You can access the HCL Workload Automation chart and container images from the Entitled Registry. See Create the secret for more information about accessing the registry. The images are as follows:

• hclcr.io/wa/hcl-workload-automation-agent-dynamic:9.5.0.03.20201228
• hclcr.io/wa/hcl-workload-automation-server:9.5.0.03.20201228
• hclcr.io/wa/hcl-workload-automation-console:9.5.0.03.20201228

Before you begin the deployment process, ensure your environment meets the following prerequisites:

• Amazon Kubernetes Service (EKS) installed and running
• aws (command line)
• Helm 3.0
• OpenSSL
• Grafana and Prometheus for monitoring dashboard
• Jetstack cert-manager
• Ingress controller: to manage the ingress service, ensure an ingress controller is corrected configured. For example, to configure an NGINX ingress controller, refer to NGINX Ingress Controller.
• Kubernetes version: >=1.15 (no specific APIs need to be enabled)
• kubectl command-line tool to control Kubernetes clusters
• API key for accessing HCL Entitled Registry: hcl.cr.io

For more details about the storage requirements for your persistent volume claims, see the Storage section of this README file. For additional details about AWS storage settings, see Storage classes.

The following resources correspond to the default values required to manage a production environment. These numbers might vary depending on the environment.

Installing and configuring HCL Workload Automation, involves the following high-level steps:

1. Create the Namespace.
2. Creating a Kubernetes Secret by accessing the entitled registry to store an entitlement key for the HCL Workload Automation offering on your cluster.
3. Securing communication using either Jetstack cert-manager or using your custom certificates.
4. Creating a secrets file to store passwords for the console and server components, or if you use custom certificates, to add your custom certificates to the Certificates Secret.
5. Deploying the product components.
6. Verifying the installation.

To create the namespace, run the following command:

    kubectl create namespace <workload_automation_namespace>

If you already have a license then you can proceed to obtain your entitlment key. To learn more about acquiring an HCL Workload Automation license, contact [email protected].

Obtain your entitlement key and store it on your cluster by creating a Kubernetes Secret. Using a Kubernetes secret allows you to securely store the key on your cluster and access the registry to download the chart and product images.

1. Access the entitled registry.

Contact your HCL sales representative for the login details required to access the HCL Entitled Registry.

3. To create a pull secret for your entitlement key that enables access to the entitled registry, run the following command:

     kubectl create secret docker-registry -n <workload_automation_namespace> sa-<workload_automation_namespace> --docker-server=<registry_server> --docker-username=<user_name> --docker-password=<password>
   

   where,

   • <workload_automation_namespace> represents the namespace where the product components are installed
   • <registry_server> is hclcr.io
   • <user_name> is the user name provided by your HCL representative
   • <password> is the entitled key copied from the entitled registry <api_key>

You secure communication using certificates. You can manage certificates using either the Jetstack cert-manager or using your own custom certificates. For information about using your own certificates, see the section Configuring. For more information about Jetstack cert-manager, see the cert-manager documentation.

Cert-manager is a Kubernetes addon that automates the management and issuance of TLS certificates. It verifies periodically that certificates are valid and up-to-date, and takes care of renewing them before they expire.

1. Create the namespace for cert-manager.

    kubectl create namespace cert-manager
   

2. Install cert-manager using a Helm chart by running the following commands:

   a. helm repo add jetstack https://charts.jetstack.io

   b. helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v0.15.1 --set installCRDs=true

3. Create the Certificate Authority (CA) by running the following commands:

   a. .\openssl.exe genrsa -out ca.key 2048

   b. .\openssl.exe req -x509 -new -nodes -key ca.key -subj "/CN=WA_ROOT_CA" -days 3650 -out ca.crt

4. Create the CA key pair secret by running the following command:

   kubectl create secret tls ca-key-pair --cert=ca.crt --key=ca.key -n <workload_automation_namespace>
   

5. Create the Issuer under the namespace. Edit the issuer.yaml file with the namespace and CA key pair.

   a. Create the issuer.yaml as follows, specifying the namespace and CA key pair:

    apiVersion: cert-manager.io/v1alpha2
    kind: Issuer
    metadata:
      labels:
        app.kubernetes.io/name: cert-manager
      name: wa-ca-issuer
      namespace: <workload_automation_namespace>
    spec:
      ca:
        secretName: ca-key-pair
   

   b. Run the following command to create the issuer under the namespace:

    kubectl apply -f issuer.yaml -n <workload_automation_namespace>
   

Create a secrets file to store passwords for the server, console and database, or if you use custom certificates, to add your custom certificates to the Certificates Secret.

1. Manually create a mysecret.yaml file to store passwords. The mysecret.yaml file must contain the following parameters:

    apiVersion: v1
    kind: Secret
    metadata:
      name: wa-pwd-secret
      namespace: <workload_automation_namespace>
    type: Opaque
    data:
       WA_PASSWORD: <hidden_password>
       DB_ADMIN_PASSWORD: <hidden_password>
       DB_PASSWORD: <hidden_password>	
   

where:

• wa-pwd-secret is the value of the pwdSecretName parameter defined in the Configuration Parameters section;
• <workload_automation_namespace> is the namespace where you are going to deploy the HCL Workload Automation product components.
• <hidden_password> must be entered; to enter an encrypted password, run the following command in a UNIX shell and copy the output into the yaml file: echo -n 'mypassword' | base64

Note: The echo command must be launched separately for each password that you want to enter as an encrypted password in the mysecret.yaml:

• WA_PASSWORD: <hidden password>
• DB_ADMIN_PASSWORD: <hidden password>
• DB_PASSWORD: <hidden password>

2. Once the file has been created and filled in, it must be imported.

   a. From the command line, log in to the AWS EKS cluster.

   b. Apply the WA-Secret (wa-pwd-secret). Create a secrets file to store passwords for both the server and console components. Launch the following command:

    kubectl apply -f <my_path>/mysecret.yaml -n <workload_automation_namespace>
   

where <my_path> is the location path of the mysecret.yaml file.

To deploy the HCL Workload Automation components, ensure you have first downloaded the chart from the HCL Entitled Registry: hclcr.io and have unpacked it to a local directory. If you already have the chart then update it.

1. Download the chart from the repository and unpack it to a local directory or, if you already have the chart, update it.

   First time installation and configuration of the chart:

   a. Add the repository:

    helm repo add <image_repository> https://hclcr.io/chartrepo/wa --username <username> --password <api_key> , where <image_repository> represents a folder of your choice
   

   b. Update the Helm chart:

   helm repo update 
   

   c. Pull the Helm chart:

    `helm pull workload/hcl-workload-automation-prod`
   

   where, workload/hcl-workload-automation-prod, represents the chosen image repository

Update your chart:

    helm repo update 	 

2. Customize the deployment. Configure each product component by adjusting the values in the values.yaml file. See these parameters and their default values in Configuration Parameters. By default a single server, console, and agent is installed.

Note: If you specify the waconsole.engineHostName and waconsole.enginePort parameters in the values.yaml file, only a single engine connection related to an engine external to the cluster is automatically defined in the Dynamic Workload Console using the values assigned to these parameters. By default, the values for these parameters are blank, and the server is deployed within the cluster and the engine connection is related to the server in the cluster. If, instead, you deploy both a server within the cluster and one external to the cluster, a single engine connection is automatically created in the console using the values of the parameters related to the external engine (server). If you require an engine connection to the server deployed within the cluster, you must define the connection manually.

3. Deploy the instance by running the following command:

    helm install -f values.yaml <workload_automation_release_name> workload/hcl-workload-automation-prod -n <workload_automation_namespace>
   

where, <workload_automation_release_name> is the deployment name of the instance. TIP: Because this name is used in the server component name and the pod names, use a short name or acronym when specifying this value to ensure it is readable.

The following are some useful Helm commands:

• To list all of the Repo releases:

    helm list -A
  

• To update the Helm release:

    helm upgrade <workload_automation_release_name> workload/hcl-workload-automation-prod -f values.yaml -n <workload_automation_namespace>
  

• To delete the Helm release:

    helm uninstall <workload_automation_release_name> -n <workload_automation_namespace>
  

After the deployment procedure is complete, you can validate the deployment to ensure that everything is working.

To manually verify that the installation was successfully installed, you can perform the following checks:

1. Run the following command to verify the pods installed in the <workload_automation_namespace>:

       kubectl get pods -n <workload_automation_namespace>
   

2. Locate the master pod name that is in the format <workload_automation_release_name>-wauser-0.

3. To access the master pod, open a bash shell and run the following command:

    kubectl exec -ti <workload_automation_release_name>-waserver-0 -n <workload_automation_namespace> -- /bin/bash
   

4. Access the HCL Workload Automation pod and run the following commands:

   a. Composer list workstation: lists the workstation definitions in the database

    composer li cpu=/@/@
   

   An example of the output for this command is as follows:

b. Conman Showpus: lists all workstations in the plan

    conman sc /@/@

An example of the output for this command is as follows:

c. Global option command optman ls:

    optman ls

This command lists the current values of all HCL Workload Automation global options. For more information about the global options see Global Options - detailed description.

• Verify that the default engine connection is created from the Dynamic Workload Console

Verifying the default engine connection depends on the network enablement configuration you implement. To determine the URL to be used to connect to the console, follow the procedure for the appropriate network enablement configuration.

For load balancer:

1. Run the following command to obtain the token to be inserted in https://<loadbalancer>:9443/console to connect to the console:

    kubectl get svc <workload_automation_release_name>-waconsole-lb  -o 'jsonpath={..status.loadBalancer.ingress..hostname}' -n <workload_automation_namespace>
   

2. With the output obtained, replace <loadbalancer> in the URL https://<loadbalancer>:9443/console.

For ingress:

1. Run the following command to obtain the token to be inserted in https://<ingress>/console to connect to the console:

    kubectl get ingress/<workload_automation_release_name>-waconsole -o 'jsonpath={..host}'-n <workload_automation_namespace>
   

2. With the output obtained, replace <ingress> in the URL https://<ingress>/console.

Logging into the console:

1. Log in to the console by using the URLs obtained in the previous step.

2. For the credentials, specify the user name (wauser) and password (wa-pwd-secret, the passwrod specified when you created the secrets file to store passwords for the server, console and database).

3. From the navigation toolbar, select Administration -> Manage Engines.

4. Verify that the default engine, engine_wa-waserver is dsplayed in the Manage Engines list:

Before you upgrade a chart, verify if there are jobs currently running and manually stop the related processes or wait until the jobs complete. To upgrade the release <workload_automation_release_name> to a new version of the chart, run the following command from the directory where the values.yaml file is located:

helm upgrade release_name workload/hcl-workload-automation-prod -f values.yaml -n <workload_automation_namespace>

Before you roll back a chart, verify if there are jobs currently running and manually stop the related processes or wait until the jobs complete. To roll back the <workload_automation_release_name> release to a previous version of the chart, run the following commands:

1. Identify the revision number to which you want to roll back by running the command:

   helm history <workload_automation_release_name> -n <workload_automation_namespace>
   

2. Roll back to the specified revision number:

   helm rollback <workload_automation_release_name>  <revision-number> -n <workload_automation_namespace>
   

To uninstall the deployed components associated with the chart and clean up the orphaned Persistent Volumes, run:

1. Uninstall the hcl-workload-automation-prod deployment, run:

   helm uninstall release_name -n <workload_automation_namespace> 
   

   The command removes all of the Kubernetes components associated with the chart and uninstalls the <workload_automation_release_name> release.

2. Clean up orphaned Persistent Volumes by running the following command:

   kubectl delete pvc -l <workload_automation_release_name> -n <workload_automation_namespace> 
   

The following tables list the configurable parameters of the chart, values.yaml, an example of the values and the default values. The tables are organized as follows:

• Global parameters (all product components)
• Agent parameters
• Dynamic Workload Console parameters
• Server parameters (master domain manager)

• Global parameters

The following table lists the global configurable parameters of the chart relative to all product components and an example of their values:

• Agent parameters

The following table lists the configurable parameters of the chart relative to the agent and an example of their values:

(*) Note: for details about static agent workstation pools, see: Workstation.

• Dynamic Workload Console parameters

The following table lists the configurable parameters of the chart relative to the console and an example of their values:

• Server parameters

The following table lists the configurable parameters of the chart and an example of their values:

The following procedures are ways in which you can configure the default deployment of the product components. They include the following configuration topics:

• Network enablement
• Enabling communication between product components in an on-premises offering with components in the Cloud
• Scaling the product
• Managing your custom certificates
• Installing Automation Hub Plug-ins

The HCL Workload Automation server and console can use two different ways to route external traffic into the Amazon Web Services Elastic Kubernetes Service cluster:

• A load balancer service that redirects traffic
• An ingress service that manages external access to the services in the cluster

You can freely switch between these two types of configuration.

You can optionally specify an egress policy for the server, Dynamic Workload Console and agent. See the following example, which allows egress to another destination:

   networkpolicyEgress:
- name: to-mdm
  egress:
  - to:
    - podSelector:
        matchLabels:
	  app.kubernetes.io/name: waserver
    - port: 31116
        protocol: TCP
    - name: dns
      egress:
      - to:
          - namespaceSelector:
              matchLabels:
                name: kube-system
     - ports:
         - port: 53
           protocol: UDP
         - port: 53
           protocol: TCP

For more information, see Network Policies.

• Server:

  To configure a load balancer for the server, follow these steps:

1. Locate the following parameters in the values.yaml file:

    exposeServiceType
    exposeServiceAnnotation
   

For more information about these configurable parameters, see the Server parameters table.

2. Set the value of the exposeServiceType parameter to LoadBalancer.

3. In the exposeServiceAnnotation section, uncomment the lines in this section as follows:

    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
   

4. Specify the load balancer type and set the load balancer to internal by specifying "true".

• Console:

  Because of a limitation in AWS EKS with stick sessions, you can only use the load balancer on the console component for a single console instance. Configure the load balancer for the console as follows:

1. Locate the following parameters in the values.yaml file:

    exposeServiceType
    exposeServiceAnnotation
   

   For more information about these configurable parameters, see the Console parameters table.

2. Set the value of the exposeServiceTypeparameter to LoadBalancer.

3. In the exposeServiceAnnotation section, uncomment the lines in this section as follows:

    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: https
    service.beta.kubernetes.io/aws-load-balancer-type: "clb"
    #service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
   

4. Specify the load balancer protocol and type.

5. Set the load balancer to internal by specifying "true".

• Server:

  To configure an ingress for the server, follow these steps:

1. Locate the following parameters in the values.yaml file:

    exposeServiceType
    exposeServiceAnnotation
   

   For more information about these configurable parameters, see the Server parameters table.

2. Set the value of the exposeServiceTypeparameter to Ingress.

3. In the exposeServiceAnnotation section, leave the following lines as comments:

    #service.beta.kubernetes.io/aws-load-balancer-type:nlb
    #service.beta.kubernetes.io/aws-load-balancer-internal: "true"
   

• Console:

  To configure an ingress for the console, follow these steps:

1. Locate the following parameters in the values.yaml file:

    exposeServiceType
    exposeServiceAnnotation
   

For more information about these configurable parameters, see the Console parameters table.

2. Set the value of the exposeServiceTypeparameter to Ingress.

3. In the exposeServiceAnnotation section, uncomment only the line related to the cert-manager issuer and set the value. Leave the other lines as comments:

     cert-manager.io/issuer: wa-ca-issuer
    #service.beta.kubernetes.io/aws-load-balancer-backend-protocol: https
    #service.beta.kubernetes.io/aws-load-balancer-type: "clb"
    #service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    #service.beta.kubernetes.io/aws-load-balancer-internal: "true"
   

Follow these steps to manage certificates with on-premises components.

On-premises agents: To correctly trigger actions specified in the event rules defined on the agent, install an on-premises agent passing the -gateway local parameter.

To configure an on-premises agent to communicate with components in the cloud:

1. Install the agent using the twinst script on a local computer passing the -gateway local parameter. If there are already other agents installed, the EIF port might already be in use by another instance. Specify a different port by passing the following parameter to the twsinst script: -gweifport <free-port>.

2. Make a copy of the following AWS cloud server certificates located in the following path <DATA_DIR>/ITA/cpa/ita/cert:

• TWSClientKeyStoreJKS.sth
• TWSClientKeyStoreJKS.jks
• TWSClientKeyStore.sth
• TWSClientKeyStore.kdb

3. Replace the files on the on-premises agent in the same path.

On-premises console engine connection (connection between an on-premises console with a server in the cloud):

1. Copy the public CA root certificate from the. Refer to the HCL Workload Automation product documentation for details about creating custom certificates for communication between the server and the console: Customizing certificates.

2. To enable the changes, restart the Console workstation.

On-premises engine connection (connection between a console in the AWS cloud and an on-premises engine or another engine in a different namespace):

Access the master (server or pod) and extract the CA root certificate and, to add it to the console trustkeystore, create a secret in the console namespace with the extracted key encoded in base64 as follows:

	kind: Secret
	apiVersion: v1
	metadata:
	  name: <yourcert-server-crt>
	  namespace: <worklaod_automation_namespace>
	  labels:
	    wa-import: 'true'
	  annotations:
	data:
	  tls.crt: <base64_encoded_certificate>
	type: Opaque

By default a single server, console, and agent is installed. If you want to change the topology for HCL Workload Automation, then increase or decrease the values of the replicaCount parameter in the values.yaml file for each component and save the changes.

To scale one or more HCL Workload Automation components up or down:

Modify the values of the replicaCount parameter in the values.yaml file for each component accordingly, and save the changes.

Note: When you scale up a server, the additional server instances are installed with the Backup Master role, and the workstation definitions are automatically saved to the HCL Workload Automation relational database. To complete the scaling up of a server component, run JnextPlan -for 0000 -noremove from the server that has the role of master domain manager to add new backup master workstations to the current plan. The agent workstations installed on the new server instances are automatically saved in the database and linked to the Broker workstation with no further manual actions.

Note:

• When you scale down each type of component, the persistent volume (PV) that the storage class created for the pod instance is not deleted to avoid losing data should the scale down not be desired. When you need to perform a subsequent scaling up, new component instances are installed by using the old PVs.
• When you scale down server or agent component, the workstation definitions are not removed from the database, so you can manually delete them or set them to ignore to avoid having a non-working workstation in the plan. If you need an immediate change to the plan, run the following command from the master workstation:

    JnextPlan -for 0000 -remove

The HCL Workload Automation Helm chart does not support automatic scaling to zero. If you want to manually scale the Dynamic Workload Console component to zero, set the value of the replicaCount parameter to zero. To maintain the current HCL Workload Automation scheduling and topology, do not set the replicaCount value for the server and agent components to zero.

The HCL Workload Automation Helm chart does not support proportional scaling.

If you use customized certificates, useCustomizedCert:true, you must create a secret containing the customized files that will replace the Server default ones in the <workload_automation_namespace>. Customized files must have the same name as the default ones.

• TWSClientKeyStoreJKS.sth
• TWSClientKeyStore.kdb
• TWSClientKeyStore.sth
• TWSClientKeyStoreJKS.jks
• TWSServerTrustFile.jks
• TWSServerTrustFile.jks.pwd
• TWSServerKeyFile.jks
• TWSServerKeyFile.jks.pwd
• ltpa.keys (The ltpa.keys certificate is required only if you use Single Sign-On with LTPA)

If you want to use custom certificates, set useCustomizedCert:true and use kubectl to apply the secret in the <workload_automation_namespace>. For the master domain manager, type the following command:

kubectl create secret generic waconsole-cert-secret --from-file=TWSServerKeyFile.jks --from-file=TWSServerKeyFile.jks.pwd --from-file=TWSServerTrustFile.jks --from-file=TWSServerTrustFile.jks.pwd --from-file=ltpa.keys -n <workload_automation_namespace>   

For the Dynamic Workload Console, type the following command:

 kubectl create secret generic waconsole-cert-secret --from-file=TWSServerKeyFile.jks --from-file=TWSServerKeyFile.jks.pwd --from-file=TWSServerTrustFile.jks --from-file=TWSServerTrustFile.jks.pwd --from-file=ltpa.keys -n <workload_automation_namespace>   
   

For the dynamic agent, type the following command:

kubectl create secret generic waagent-cert-secret --from-file=TWSClientKeyStore.kdb --from-file=TWSClientKeyStore.sth --from-file=TWSClientKeyStoreJKS.jks --from-file=TWSClientKeyStoreJKS.sth -n <workload_automation_namespace>    

where, TWSClientKeyStoreJKS.sth, TWSClientKeyStore.kdb, TWSClientKeyStore.sth, TWSClientKeyStoreJKS.jks, TWSServerTrustFile.jks and TWSServerKeyFile.jks are the Container keystore and stash file containing your customized certificates.

For details about custom certificates, see Connection security overview.

Note: Passwords for "TWSServerTrustFile.jks" and "TWSServerKeyFile.jks" files must be entered in the respective "TWSServerTrustFile.jks.pwd" and "TWSServerKeyFile.jks.pwd" files.

(**) Note: if you set db.sslConnection:true, you must also set the useCustomizeCert setting to true (on both server and console charts) and, in addition, you must add the following certificates in the customized SSL certificates secret on both the server and console charts:

• TWSServerTrustFile.jks
• TWSServerKeyFile.jks
• TWSServerTrustFile.jks.pwd
• TWSServerKeyFile.jks.pwd

Customized files must have the same name as the ones listed above.

If you want to use SSL connection to DB, set db.sslConnection:true and useCustomizedCert:true, then use kubectl to create the secret in the same namespace where you want to deploy the chart:

  bash
  $ kubectl create secret generic release_name-secret --from-file=TWSServerTrustFile.jks --from-file=TWSServerKeyFile.jks --from-file=TWSServerTrustFile.jks.pwd --from-file=TWSServerKeyFile.jks.pwd --namespace=<workload_automation_namespace>

If you define custom certificates, you are in charge of keeping them up to date, therefore, ensure you check their duration and plan to rotate them as necessary. To rotate custom certificates, delete the previous secret and upload a new secret, containing new certificates. The pod restarts automatically and the new certificates are applied.

You can extend HCL Workload Automation with a number of out-of-the-box integrations available on Automation Hub.

To download the plug-ins:

1. Download the plug-ins from Automation Hub and extract the contents to a folder on the local computer.

2. From your local computer, go to the <plug-ins_folder> folder and run the following command:

     kubectl cp <plugin_name.jar> <namespace>/<master-pod>:/home/wauser/wadata/wa_plugins/<plugin_name.jar>
   

where, <master_pod> is the workstation with the master role. The default is <release-name>-waserver-0.

3. Access the <master_pod> pod terminal and run the following command:

cp /home/wauser/wadata/wa_plugins/<plugin_name.jar> /opt/wa/TWS/applicationJobPlugIn/<plugin_name.jar>

4. To grant execution permissions for the .jar file, run:

chmod 755 /opt/wa/TWS/applicationJobPlugIn/<plugin_name.jar>

5. From the <master_pod> pod, to restart application server, run:

• /opt/wa/appservertools/appserverstart.sh stop
• /opt/wa/appservertools/appserverstart.sh start

NOTE: Each time you restart the master pod, the plug-in you downloaded is removed. After a restart, rerun the procedure from step 5. to step 7.

NOTE:

A Kubernetes job plug-in is available on Automation Hub. It enables you to automate the execution of Kubernetes jobs. https://www.yourautomationhub.io/detail/kubernetes_9_5_0_02. Follow the steps in the previous procedure to download and install the plug-in.

HCL Workload Automation requires persistent storage for each component (server, console and agent) that you deploy to maintain the scheduling workload and topology.

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

/home/wauser

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

For test purposes only, you can configure the chart so that persistence is not used.

HCL Workload Automation can use either dynamic provisioning or static provisioning using a pre-created persistent volume
to allocate storage for each component that you deploy. You can pre-create Persistent Volumes to be bound to the StatefulSet using Label or StorageClass. It is highly recommended to use persistence with dynamic provisioning. In this case, you must have defined your own Dynamic Persistence Provider. HCL Workload Automation supports the following provisioning use cases:

• Kubernetes dynamic volume provisioning to create both a persistent volume and a persistent volume claim. This type of storage uses the default storageClass defined by the Kubernetes admin or by using a custom storageClass which overrides the default. Set the values as follows:

  • persistence.enabled:true (default)
  • persistence.useDynamicProvisioning:true(default)

Specify a custom storageClassName per volume or leave the value blank to use the default storageClass.

• Persistent storage using a predefined PersistentVolume set up prior to the deployment of this chart. Pre-create a persistent volume. If you configure the label=value pair described in the following Note, then the persistent volume claim is automatically generated by the Helm chart and bound to the persistent volume you pre-created. Set the global values as follows:

  • persistence.enabled:true
  • persistence.useDynamicProvisioning:false

Note: By configuring the following two parameters, the persistent volum claim is automatically generated. Ensure that this label=value pair is inserted in the persistent volume you created:

• <wa-component>.persistence.dataPVC.selector.label
• <wa-component>.persistence.dataPVC.selector.value

Let the Kubernetes binding process select a pre-existing volume based on the accessMode and size. Use selector labels to refine the binding process.

Before you deploy all of the components, you have the opportunity to choose your persistent storage from the available persistent storage options in AWS Elastic Kubernetes Service that are supported by HCL Workload Automation or, you can leave the default storageClass.
For more information about all of the supported storage classes, see the table in Storage classes static PV and dynamic provisioning.

If you create a storageClass object or use the default one, ensure that you have a sufficient amount of backing storage for your HCL Workload Automation components.
For more information about the required amount of storage you need for each component, see the Resources Required section.

Custom storage class:
Modify the the persistence.dataPVC.storageClassName parameter in the YAML file by specifying the custom storage class name, when you deploy the HCL Workload Automation product components.

Default storage class:
Leave the values for the persistence.dataPVC.storageClassName parameter blank in the YAML file when you deploy the HCL Workload Automation product components.
For more information about the storage parameter values to set in the YAML file, see the tables, Agent parameters, Dynamic Workload Console parameters, and Server parameters (master domain manager).

File system security permissions need to be well known to ensure uid, gid, and supplemental gid requirements can be satisfied. On Kubernetes native, UID 999 is used.

HCL Workload Automation supports only ReadWriteOnce (RWO) access mode. The volume can be mounted as read-write by a single node.

HCL Workload Automation uses Grafana to display performance data related to the product and metrics related to the server and console application servers (WebSphere Application Server Liberty Base). Grafana is an open source tool for visualizing application metrics. Metrics provide insight into the state, health, and performance of your deployments and infrastructure. HCL Workload Automation cloud metric monitoring uses an opensource Cloud Native Computing Foundation (CNCF) project called Prometheus.

The following metrics are collected and available to be visualized in the preconfigured Grafana dashboard. The dashboard is named <workload_automation_namespace> <workload_automation_release_name>:

The following is an example of the various metrics available with focus on the workload job status:

The following is an exammple of how persistent volume capacity for the server, console and agent are visualized:

Before you set the Grafana service on the EKS cluster, ensure that you have already installed Grafana and Prometheus on the EKS cluster. For information about deploying Grafana see Install Grafana. For information about deploying the open-source Prometheus project see Download Promotheus.

1. Log in to the EKS cluster. To identify where Grafana is deployed, retrieve the value for the <grafana-namespace> by running:

      helm list -A
   

2. Download the grafana_values.yaml file by running:

    helm get values grafana -o yaml -n <grafana-namespace> grafana_values.yaml
   

3. Modify the grafana_values.yaml file by setting the following parameter values:

    dashboards:
         SCProvider: true
         enabled: true
         folder: /tmp/dashboards
         label: grafana_dashboard
         provider:
    	 allowUiUpdates: false
    	 disableDelete: false
    	 folder: ""
    	 name: sidecarProvider
    	 orgid: 1
    	 type: file
         searchNamespace: ALL
   

4. Update the grafana_values.yaml file in the Grafana pod by running the following command:

   helm upgrade grafana stable/grafana -f grafana_values.yaml -n <grafana-namespace>

5. To access the Grafana console:

   a. Get the EXTERNAL-IP address value of the Grafana service by running:

    kubectl get services -n <grafana-namespace>
   

   b. Browse to the EXTERNAL-IP address and log in to the Grafana console.

To get an overview of the cluster health, you can view a selection of metrics on the predefined dashboard:

1. In the left navigation toolbar, click Dashboards.

2. On the Manage page, select the predefined dashboard named <workload_automation_namespace> <workload_automation_release_name>.

For more information about using Grafana dashboards see Dashboards overview.

• Limited to amd64 platforms.
• Anonymous connections are not permitted.
• When sharing Dynamic Workload Console resources, such as tasks, engines, scheduling objects and so on, to groups, ensure the user sharing the resource is a member of the group to which the user is sharing the resourc.
• On AWS, LDAP configuration on the chart is not supported. Manual configuration is required using the traditional LDAP configuration.

To access the complete product documentation library for HCL Workload Automation, see https://workloadautomation.hcldoc.com/help/index.jsp.

In case of problems related to deploying the product with containers, see Troubleshooting.

Problem: The broker server cannot be contacted. The Dynamic Workload Broker command line requires additional configuration steps.

Workaround: Perform the following configuration steps to enable the Dynamic Workload Broker command line:

1. From the machine where you want to use the Dynamic Workload Broker command line, master domain manager (server) or dynamic agent, locate the following file:

   /home/wauser/wadata/TDWB_CLI/config/CLIConfig.properties

2. Modify the values for the fields, keyStore and trustStore, in the CLIConfig.properties file as follows:

   keyStore=/home/wauser/wadata/ITA/cpa/ita/cert/TWSClientKeyStoreJKS.jks

   trustStore=/home/wauser/wadata/ITA/cpa/ita/cert/TWSClientKeyStoreJKS.jks

3. Save the changes to the file.