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 Digital Experience 9.5 Core Kubernetes or Red Hat OpenShift Container Deployment to a later Container Update release.
New HCL Digital Experience 9.5 CFxxx container images are released on a regular cadence, through the HCL DX 9.5 Container Update deliveries.
Consult the Digital Experience 9.5 Container Deployment topic for the latest list of DX 9.5 Container images that are available.
HCL DX administrators should not extend the HCL Digital Experience 9.5 container images. They are not intended to be used in the FROM instruction as a parent image.
It is recommended you create a backup of your DX 9.5 deployment before managing the update processes using the following steps:
- Create a backup of the
wp_profile
.To backup thewp_profile
, it is recommended that the number of instances is 1 instance, and your Digital Experience 9.5 Container deployment is stopped using the following command:/opt/HCL/wp_profile/stopServer.sh
Next, 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 file system has ~50% free capacity. Once complete, it is recommended 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
. - 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, you need to execute into the POD.
Once you have completed the command, it is recommended that a copy of the resulting file is created and placed to an alternate long-term storage.
Update the HCL Digital Experience 9.5 core deployment files:Note: Beginning with HCL DX 9.5 Container Update CF192, the dxctl process is used to manage updates to later update releases. See the following deployment topics below for the update instructions details.- Documentation resource: Deploy HCL Digital Experience 9.5 Container to Red Hat OpenShift
- Documentation resource: Deploy HCL Digital Experience 9.5 Container to Amazon EKS
- Documentation resource: Deploy HCL Digital Experience 9.5 Container to Microsoft Azure AKS
- Documentation resource: Deploy HCL Digital Experience 9.5 Container to Google Kubernetes Engine (GKE)
- Video: Using dxctl to update HCL DX 9.5 on Red Hat OpenShift to Container Update CF192
- Video: Updating the HCL DX 9.5 Portal & IBM WebSphere Application Server Administrator Secrets in OpenShift and Kubernetes
-
Download the later version of the HCL DX 9.5 Container Update packages to update from the HCL Software License Portal.
Consult the Digital Experience 9.5 Container Deployment topic for the latest list.
- 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).
Use the following guidance and steps if managing an update to Container Update versions prior to CF192:
- 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.Note: If you performed a database transfer, please ensure the<database>.DbUser
and<database>.DbPassword
for all Portal databases reflect the current user and password in opt/HCL/wp_profile/ConfigEngine/properties/wkplc_dbdomain.properties prior to updating the Portal Core image. - 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.
- 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
- OpenShift command:
- Release claim on the
wp_profile
persistent volume to make it available:- OpenShift command:
oc edit pv VOLUME
- Kubernetes command:
kubectl edit pv VOLUME
- OpenShift command:
- 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'
- 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
- OpenShift command:
- Delete the DxDeployment CRD. This terminates all deployments.
- To update the HCL Digital Experience 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 theupdateDx.sh
script has completed, DX administrators are encouraged to check the following log files to ensure the CF update completed successfully.-
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
- 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.
- Kubernetes
command:
- 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 are automatically redeployed at version 1 and version 2, provided you have an active deployment. If not, they are redeployed once the HCL DX 9.5 DX is deployed. The previous ambassador version, prior to CF183 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 must updated so you can scale the instances higher. Additionally, once the database is transferred, the number of replicas can be increased.
-
During the Update process, the deployment automatically restarts a few times and make appropriate configuration changes during these restarts. Once complete the deployment is upgraded.
For instructions to update the Content Composer, Digital Asset Management, and Experience API container deployment images, see the following topics.- Documentation resource: Install the Experience API, Content Composer, and DAM Components
- Documentation resource: Update the Experience API, Content Composer, and DAM Components
Instructions to Delete a DX 9.5 Container Deployment
- To remove the deployment in a specific namespace, run the following:
./scripts/removeDx.sh NAMESPACE
- NAMESPACE - the project or the namespace created or used for deployment.
- OpenShift
commands:
'oc delete project <project_name>' 'oc delete -f dxNameSpace_NAMESPACE.yaml' where NAMESPACE is the namespace to be removed
- Kubernetes command:
'kubectl delete -f dxNameSpace_NAMESPACE.yaml' where NAMESPACE is the namespace to be removed
- Open the persistent volume in a visual editor (vi) using the:
- OpenShift command:
oc edit pv your_namespace
- Kubernetes command:
kubectl edit pv your_namespace
- OpenShift command:
- Remove
the
claimRef
section:claimRef: apiVersion: v1 kind: PersistentVolumeClaim name: dx-deploy-pvc namespace: your_namespace resourceVersion: "488931120" uid: ebd58361-0e2a-11ea-b02e-02f8fe687954
- Ensure you get the
'persistentvolume/your_namespace edited'
message. - You may need to manually remove any data remaining from the previous deployment.