Containerization Requirements and Limitations - HCL WebSphere Portal 9.5

Consult the HCL WebSphere Portal 9.5 Support Statements on the HCL DX Support pages for the latest updates on supported platforms, components, and release levels.

• HCL DX 9.5 is supported on...
  • Docker
  • Red Hat OpenShift
  • Amazon Elastic Kubernetes Service (EKS)
  • Microsoft Azure Kubernetes Service (AKS)
  • Google Kubernetes Engine (GKE)

  Other Kubernetes platforms are not fully supported. The HCL Operator is not likely to work, however, support for additional Kubernetes as a Service (KaaS) is ongoing and additions will be reflected in the HCL DX 9.5 Support Statements.

  • Additional features and functions may be tied to the use of the HCL Operators for deployment.
  • HCL highly recommends following the deployment strategies outlined within this documentation. HCL DX 9.5 containerization is focused on deployment and it uses an operator-based deployment. The goals are:
    • (a) to introduce a supported containerized deployment that HCL can continually extend,
    • (b) to provide customers with the best possible experience; and
    • (c) to provide a high level of customization in the deployment and continue to expand on that, along with increased automation.
    • (d) maintain sepration of product and custom code.

    Customers need to follow the recommended deployment model to ensure the availability of future functions and prevent potential conflicts.

    • HCL DX is a database-intensive application, it is not recommended to use Apache Derby for production use. For specific versions of databases supported for production, see the HCL DX 9.5 Support Statements on the HCL DX Support pages.
    • Creation of Virtual Portals will take longer when implemented in Red Hat OpenShift. Plan for adequate time to allow processing, and re-verify the results are completed by refreshing the web browser administrative panel.
    • Customers should not modify the HCL DX 9.5 Docker images provided by HCL for deployment. This restriction includes use of these images as a base to create a new image, which would result in a new image ID and an unsupported configuration. Instead, customers deploying the images should follow best practices guidance and maintain customizations in the wp_profile and the deployment database. Scripts and custom files should be stored in wp_profile (/opt/HCL/wp_profile/). See the Deployment Help Center topics for more information

    • Set alternate context roots is not supported for HCL DX 9.5 deployments on supported Kubernetes and Red Hat Open Shift platforms.

• Supported file system requirements :
  • Requires an AccessMode of ReadWriteMany .
  • Requires a minimum of 40 GB , with the default request set to 100 GB .

  Note: HCL DX is input-output (I/O) intensive and requires a high performing file system for optimization.

• ConfigEngine and ConfigWizard should only be used when there is a single instance

  When more than one instance is running, the ConfigEngine is disabled and the ConfigWizard route is removed. As an example, the Site Builder is calling the ConfigEngine in the background. But because multiple instances are running, an Error 500 occurs because the ConfigEngine is disabled. All ConfigEngine.sh tasks should be run in configure mode with only one instance running.

• JavaServer Faces (JSF) portlet bridge

  With DX 9.5 Container Update CF_171 and higher, WebSphere Application Server 9.0.5.15.2 is included and that IBM fix pack removed the IBM JSF portlet bridge. If we are using JSF portlets and leverage the JSF portlet bridge, proceed to the HCL DX 9.5 Container Update CF18 for the required JavaServer Faces Bridge support before moving to a container-based deployment.

  The HCL JavaServer Faces Bridge is added to HCL DX offerings with Container Update CF18 and CF18 on-premises platform CF update. For more information please see What's New in Container Update CF18.

Parent topic: Containerization