Deploying on Azure AKS

You can deploy and manage HCL Workload Automation containers on Azure Kubernetes Service (AKS).

Deploy and manage HCL Workload Automation containerized product components on the Azure AKS, a container orchestration service available on the Microsoft Azure public cloud. You can use Azure AKS to deploy, scale up, scale down and manage containers in the cluster environment. You can also deploy and run an Azure SQL database.

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 now be deployed on Azure AKS. Within just a few minutes, you can easily launch an instance to deploy an HCL Workload Automation server, console, and agents with full on-premises capabilities on the Microsoft Azure public cloud.

HCL Workload Automation deployed in a cluster environment improves flexibility and scalability of your automation environment. It helps in lowering costs and eliminating complexity, while reducing the operational overhead and the burden involved in managing your own infrastructure, so you can invest your time and resources in growing your business.

Running the product containers within Azure AKS gives you access to services such as a highly scalable cloud database service. You can deploy and run any of the following Azure SQL Server database models in the Azure cloud, depending on your needs:
  • SQL database
  • SQL managed instance
  • SQL virtual machine

Full details and deployment instructions are available in the HCL Workload Automation Chart readme file.

Importing missing intermediate certificates into TWSClientTrustStores

When deploying HCL Workload Automation on Azure AKS with custom SSL certificates, the intermediate certificates are missing in TWSClientTrustStore.p12 and TWSClientTrustStore.pem. Below you can find the procedure to manually import the missing certificates.
  1. In the values.yaml file, enable the following attributes for each service:
    certSecretName: waserver-cert-secret or waconsole-cert-secret or waagent-cert-secret
useCustomizedCert: true
  2. Create a secret for the SSL password:
    vi my-ssl-secret.yaml
    Sample output:
    apiVersion: v1
kind: Secret
metadata:
 name: iwav1022-ssl-secret
 namespace: iwa
 labels:
  app.kubernetes.io/managed-by: Helm
 annotations:
  meta.helm.sh/release-name: iwav1022
  meta.helm.sh/release-namespace: iwa
type: Opaque
data:
  SSL_PASSWORD: <encrypted password here>

    Run the following command:

    kubectl apply -f my-ssl-secret.yaml -n iwa
  3. Rename the below certificates as follows:
    • Root CA Certificate as ca.crt
    • 1st Intermediate certificate as int1.crt
    • 2nd Intermediate certificate as int2.crt
  4. Create a secret for the waconsole certificates:
    kubectl create secret generic waconsole-cert-secret --from-file=tls.key --from-file=tls.crt --from-file=ca.crt -n iwa
  5. Create a secret for the waserver certificates:
    kubectl create secret generic waserver-cert-secret --from-file=tls.key --from-file=tls.crt --from-file=ca.crt -n iwa
  6. Create secrets for the intermediate certificates:
    kubectl create secret generic inter1-cert-secret --from-file=tls.crt=inter1.crt -n iwa
kubectl create secret generic inter2-cert-secret --from-file=tls.crt=inter2.crt -n iwa
    Note: The from-file value in the secret should always be tls.crt.
  7. Add the label wa-import=true to each of the secrets for the intermediate certificates:
    kubectl label secret int1-cert-secret "wa-import=true" -n iwa
kubectl label secret int2-cert-secret "wa-import=true" -n iwa
    Then, run the following command to verify the secrets:
    kubectl get secrets --show-labels -n iwa
  8. Create a secret to populate the depot, so that the agents can download the certificates: 
    kubectl create secret generic waagent-cert-secret-ext --from-file=tls.key --from-file=tls.crt --from-file=ca.crt=cachain.crt -n iwa
    Where cachain.crt contains the CA chain with int1, int2, and the root CA ceritifcates.
  9. Deploy helm charts.
  10. Add the following tls block under spec in the ingress manifestation:
        spec:
     tls:
      - hosts:
       - <dwc_fqdn_registered_with_dns>
       secretName: waconsole-ssl-secret
  11. Log into the waserver pod and import the intermediate certificates into TWSClientTrustStore.p12:
    /opt/wa/TWS/JavaExt/jre/jre/bin/keytool -importcert -file additionalCAs/int1-cert-secret.crt -alias Intermediate1 -keystore TWSClientTrustStore.p12 -storepass default -trustcacerts -noprompt
/opt/wa/TWS/JavaExt/jre/jre/bin/keytool -importcert -file additionalCAs/int2-cert-secret.crt -alias Intermediate2 -keystore TWSClientTrustStore.p12 -storepass default -trustcacerts -noprompt
  12. Append the intermediate certificates into TWSClientTrustStore.pem:
    cat additionalCAs/int1-cert-secret.crt >> TWSClientTrustStore.pem
cat additionalCAs/int2-cert-secret.crt >> TWSClientTrustStore.pem