Prerequisites for Component Pack

Component Pack for HCL Connections uses different technologies from Connections and requires additional software.

Component Pack for HCL Connections consists of Docker images and Helm charts intended to be deployed on Kubernetes. Before you can install Component Pack, you need to meet the following prerequisites. (Note that many of the links provided in this topic are to documentation for prerequistie software products outside of HCL.)

  • One machine with at least 50G of disk space free
  • Fully configured Kubernetes cluster
  • Non root user configured to use kubectl to access your Kubernetes cluster
  • Latest Helm v2 installed and configured for the same non root user who can use kubectl
  • Docker Registry (or any alternative) where you will upload the images from the Component Pack package, using provided scripts, to be able to install it with Helm. You also need to ensure that your Kubernetes nodes can access your Docker Registry without any issues.
  • Use kubectl to create the namespace called "connections":
    kubectl create namespace connections
  • Use kubectl to create ImagePullSecret, called myregkey, so that your Kubernetes cluster can pull the images once you install the Component Pack:
    kubectl create secret docker-registry myregkey -n connections --docker-server=Docker_registry --docker-username=Your_user_name --docker-password=Your_password

How does installation work?

As you will see later, you will download the Component Pack to your prepared machine. Component Pack package can be 10G+ in size once unpacked.

Then you will use the script provided to upload the images that you obtained as a part of Component Pack to your Docker Registry.

You will then use Helm to install different components to your Kubernetes cluster, and Kubernetes itself will pull the images from your Docker Registry on the worker nodes to start them up. To be able to pull the images, Kubernetes needs to be able to authenticate to your Docker Registry first, and that is why you must have ImagePullSecret (called myregkey) properly configured. That is also why it is a good idea to test the access to your Docker Registry from the whole Kubernetes cluster before you begin.

That's it!

Supported Kubernetes platforms

Supported container runtimes
Currently we are supporting only Docker as the container runtime for Kubernetes. Docker versions depend heavily on the version of Kubernetes that you are going to use.
If you are setting up the cluster yourself, see which Docker versions are supported by which version of Kubernetes in the Kubernetes documentation.
Supported Kubernetes versions
As of HCL Connections version 6.5.0.1, deployments to the latest stable Kubernetes platform (version 1.17) are supported, and that is the version where all development and testing is happening at HCL.
However, HCL tested its deployment all the way from Kubernetes 1.11.9 to 1.18.2, and is continuing to test it against any new Kubernetes release.
Supported Kubernetes flavors
Component Pack is designed to work with each and every Kubernetes platform that is using Docker as the container runtime. To ensure compatibility, all development and testing is done internally on the vanilla Kubernetes installations, without preference for any specific provider.
However, HCL is always working on optimizing the Component Pack experience, which includes lowering costs for our customers, and is therefore trying to ensure that some vendor-specific options are supported as well.
Supported Kubernetes network plugins
Component Pack is developed and tested using Calico as the Kubernetes CNI, but you can use another CNI if it better suits your use case. Component Pack is continually being tested with the latest version of Calico. Note that Calico is also supported by OpenShift.
Persistent volumes
Component Pack uses persistent volumes to store Connections data. To set up persistent volumes for Component Pack, see the section on persistent volumes in the HCL Connections documentation. Persistent volumes are a firm requirement for Component Pack.
Cluster layout considerations
Because Component Pack runs on Kubernetes, it can run on one or multiple servers, depending on how your Kubernetes cluster is set up.

Please note that Elasticsearch is a somewhat of a special case. Elasticsearch can be used as a backend for the Orient Me component and as a part of the Elastic Stack installation. Elasticsearch itself can use most of the memory (Component Pack will scale three pods, and each can use up to 8G of RAM). In that case it is best to have a separate Kubernetes worker for only the Elasticsearch-tainted-as-infrastructure node, with scheduling disabled. The same requirement applies when you extend your deployment to include Elastic Stack. In that case Elasticsearch and the rest of Elastic Stack are living on the same dedicated node (or nodes) where scheduling all other types of pods is disabled.

However, if you don't plan to use a full-blown distributed cluster, you can also try to let Elastic Stack services live together with the rest of pods. If there are any performance issues after the cluster is fully provisioned and Component Pack deployed, you can always add new infrastructure workers, and Elastic Stack (and Elasticsearch) pods will be rescheduled there.

Supported Helm Versions

Currently, Component Pack supports Helm v2, with support for Helm v3 on the roadmap.