+

Search Tips   |   Advanced Search


Update the Digital Experience 9.5 Core Kubernetes or Red Hat OpenShift Container Deployment

Update the Digital Experience 9.5 Core Kubernetes Container Deployment.

Follow the processes below to create a backup, then update the DX 9.5 Core Kubernetes or Red Hat OpenShift Container Deployment to a later Container Update release.

New HCL DX 9.5 CF_xxx container images are released on a regular cadence, through the HCL DX 9.5 Container Update deliveries .

Consult the DX 9.5 Container Deployment topic for the latest list of DX 9.5 Container images available. HCL DX administrators should not apply maintenance to an HCL DX 9.5 container image. Instead, they should run the update process as described below.

Note: HCL DX 9.5 CF_191 images are available and may be installed. HCL DX 9.5 CF_191 is supported for new deployments only . DX administrators should not upgrade DX 9.5 container deployments to this release.

HCL DX administrators should not extend the HCL DX 9.5 container images. They are not intended to be used in the FROM instruction as a parent image.

HCL recommends you create a backup of your DX 9.5 deployment before managing the update processes using the following steps:

  1. Create a backup of the wp_profile.

    To backup the wp_profile, HCL recommends that the number of instances is 1 instance, and your DX 9.5 Container deployment is stopped using the /opt/HCL/wp_profile/stopServer.sh WebSphere_Portal command.

    ext, ensure the entire /opt/HCL/wp_profile directory is backed up. A method to generate this backup is shown using the following commands:

      cd /opt/HCL/wp_profile

      tar -cvpzf backup.tar.gz --exclude=/backup.tar.gz --one-file-system /opt/HCL/wp_profile

    Note: Before starting the tar ensure that your filesystem has ~50% free capacity. Once complete, HCL recommends that you copy the backup.tar.gz file that is generated to alternate long term storage.

    In addition, as outlined in the Backup and Recovery topic, the Digital Experience 9.5 database should be backed up at the same time as the wp_profile.

  2. Create a backup of the Persistence layer using the following example commands:

      pg_dump name_of_database > name_of_backup_file.

    We recommend backing up the system on a remote system:

      pg_dump -U user_name -h remote_host -p remote_port name_of_database > name_of_backup_file.  

    If it is done locally, we need to execute into the POD.

    Once we have completed the command, HCL recommends that a copy of the resulting file is created and placed to an alternate long-term storage.

    Update the HCL DX 9.5 core deployment files.

  3. Download the later version of the HCL DX 9.5 Container Update packages to update from the HCL Software License Portal. Consult the DX 9.5 Container Deployment topic for the latest list.

  4. Load, tag, and push the later version DX 9.5 Container images to your supported Kubernetes or OpenShift platform (similar to steps followed with your original HCL DX 9.5 image detailed in the HCL DX 9.5 Help Center Deployment topics).

  5. To upgrade the deployment to a new version, update the IMAGETAG value that was used in the original deployDx.sh execution to the new IMAGETAG .

  6. Update the tag in the operator.yaml file to the later HCL DX 9.5 Container Update versions tag.

    Note: If updating your DX 9.5 container deployment to CF19, complete the following steps before proceeding to step 7.

    1. Delete the DxDeployment CRD. This terminates all deployments.

      • OpenShift command:

          oc delete crd dxdeployments.git.cwp.pnp-hcl.com

      • Kubernetes command:

          kubectl delete crd dxdeployments.git.cwp.pnp-hcl.com

    2. Release claim on the wp_profile persistent volume to make it available:

      • OpenShift command:

          oc edit pv VOLUME

      • Kubernetes command:

          kubectl edit pv VOLUME

    3. Delete the claimRef section:

        Example:
        claimRef:
        kind: PersistentVolumeClaim
        namespace: dx-ns
        name: dx-deployment-pvc
        uid: 633c67f9-89fe-4ac8-8db1-929ccbb8a657
        apiVersion: v1
        resourceVersion: '658831'

    4. Create the CF19 DxDeployment CRD:

      • OpenShift command:

          oc create -f deploy/crd/git.cwp.pnp-hcl.com_dxdeployments_crd.yaml
      • Kubernetes command:

          kubectl create -f deploy/crd/git.cwp.pnp-hcl.com_dxdeployments_crd.yaml

  7. To update the HCL DX 9.5 core deployment files to the later Container Update version, run the updateDx.sh script with updated values, as shown in the following examples:

    • Kubernetes command:

        ./scripts/updateDx.sh NAMESPACE REPLICAS REPOSITORY IMAGENAME IMAGETAG VOLUMENAME STORAGECLASS DBTYPE INGRESSIMAGE INGRESSTAG

    • OpenShift command:

        ./scripts/updateDx.sh NAMESPACE REPLICAS REPOSITORY IMAGENAME IMAGETAG VOLUMENAME STORAGECLASS DBTYPE

      • NAMESPACE - the project or the namespace to create or use for deployment.
      • REPLICAS - the number of initial instances for the deployment.
      • REPOSITORY - your local repository, the repository used by OpenShift/ or supported Kubernetes platforms, Amazon EKS or MS Azure AKs
      • IMAGENAME - the name of the dxCore image, as added to the repository above.
      • IMAGETAG - the tag for the target image as added to the above repository.
      • VOLUMENAME - the volume to be used by the deployment for persistence, this must use AccessMode ReadWriteMany .
      • STORAGECLASS - the storage class name used to create the persistent volume.
      • DBTYPE - the database type. By default, and initially, this is Derby.

        • INGRESSIMAGE - The image name to use for ambassador.
        • INGRESSTAG - The image tag to use for ambassador.

        After the updateDx.sh script has completed, DX administrators are encouraged to check the following log files to ensure the CF update completed successfully.

        1. Check the ConfigTrace.log located under the /opt/HCL/wp_profile/ConfigEngine/log/ directory to ensure the update task was successful, as shown in this example:

            [2020-08-26 19:53:28.658] Target finished: action-apply-cf

            BUILD SUCCESSFUL
        2. Review for any exceptions in the SystemOut.log located under the /opt/HCL/wp_profile/logs/WebSphere_Portal directory.

    Additional steps required for HCL DX 9.5 deployments to supported Kubernetes platforms: Amazon EKS or Microsoft Azure AKS.

  8. Administrators must perform delete/deploy or redeploy the ambassador definitions. This can be done by performing these commands, operating on an MS Azure AKS environment in these examples:

    • kubectl delete crd tracingservices.getambassador.io -n az-demo
    • kubectl delete crd tlscontexts.getambassador.io -n az-demo
    • kubectl delete crd tcpmappings.getambassador.io -n az-demo
    • kubectl delete crd ratelimitservices.getambassador.io -n az-demo
    • kubectl delete crd ratelimits.getambassador.io -n az-demo
    • kubectl delete crd projectversions.getambassador.io -n az-demo
    • kubectl delete crd projects.getambassador.io -n az-demo
    • kubectl delete crd projectsrevisions.getambassador.io -n az-demo
    • kubectl delete crd modules.getambassador.io -n az-demo
    • kubectl delete crd mappings.getambassador.io -n az-demo
    • kubectl delete crd logservices.getambassador.io -n az-demo
    • kubectl delete crd authservices.getambassador.io -n az-demo
    • kubectl delete crd consulresolvers.getambassador.io -n az-demo
    • kubectl delete crd hosts.getambassador.io -n az-demo
    • kubectl delete crd kubernetesserviceresolvers.getambassador.io -n az-demo
    • kubectl delete crd kubernetesendpointresolvers.getambassador.io -n az-demo

    Upon completion, these will automatically be redeployed at version 1 and version 2, provided we have an active deployment. If not, they will be redeployed once the HCL DX 9.5 DX is deployed. The previous ambassador version, prior to CF_183 at level 0.85.0, is deployed and uses the ambassador version 1 APIs.

    There are additional options to  customize the deployment. For example, once the database is transferred to a non-Derby database, the  DBTYPE  will need to be updated so we can scale the instances higher. Additionally, once the database is transferred, the number of replicas could be increased.


Instructions to Delete a DX 9.5 Container Deployment

Removing the entire deployment requires several steps, this is by design.

To remove a namespace, use any of the following commands:

The persistent volume associated to the deployment needs to be cleaned up by your Administrator. To reuse a persistent volume, see the following steps:

Parent topic: Container Administration