Helm chart configuration
In order to support the deployment of multiple DCT instances in the same namespace or project, Helm charts must be made configurable to make resources (i.e. services, deployments, and pods) unique to that deployment. A suffix (nameSuffix
) is provided during deployment to avoid resource name collision.
An example scenario where this might be necessary is if DCT version 15.0.0 were deployed in the dct-services
namespace and you want to deploy another DCT instance of the same version or higher in the same namespace. The version 15.0.0 instance could have a nameSuffix
like v15, while the 16.0.0 instance could have a suffix of v16, thus preventing a name collision.
This feature works for internal and external database deployment models. If you are using an external database, then before deploying DCT with a suffix, the databases for all DCT services must be created with the same suffix:
appv15
bookmarksv15
data-libraryv15
jobsv15
virtualizationv15
maskingv15
Feature limitations
Deployments with a nameSuffix
are only applicable for fresh deployments or upgrades to futures version releases of deployments with the same suffix.
Helm chart configuration
Deploying DCT with resource names appended with a suffix, resources must be made specific to that deployment. Use the option provided in the vaules.yaml to pass the nameSuffix
to resources as follows:
nameSuffix:v15
If there is a need to deploy multiple instances of DCT in the same namespace or project, set nameSuffix
to a string that will not conflict with the resources from each deployment.
If you are enabling multiple instance deployment in the same namespace, first you must create namespace or project before the deployment of DCT and set useExistingNamespace
to true in the values.yaml for both deployments.
For multiple instance deployments in the same namespace, create a namespace or project separately to avoid the uninstallation of other DCT instances.
If the namespace was not created manually, the helm installation will create the Namespace during the deployment of Instance-1. In this scenario, whenever Instance-1 will be uninstalled, the namespace will be deleted and all other resources (like Instance-2) will also be removed.
Use this command to create a namespace manually:
$ kubectl create namespace dct-services
Once nameSuffix
is configured in values.yaml, it gets appended to the resources of that deployment.
To deploy another instance of DCT in the same namespace, provide another nameSuffix
string (i.e. v16) so the resources for the this deployment are associated with it. In the additional deployment(s), you must set the useExistingNamespace
value to true:
useExistingNamespace:true
Accessing deployed DCT instances
To access deployed instances of DCT, you must create ingress routes for requests to the appropriate deployment. The ingress configuration depends on user deployment, but the following example could be used as reference.
Example
Two DCT instances are deployed with their respective nameSuffix
configured to v15 and v16. To access them, two ingress route configurations similar to the following would be needed.
Ingress route one
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: https-ingressv15
namespace: dct-services
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
rules:
- host: v15.dct.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: proxyv15
port:
number: 443
Ingress route two
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: https-ingressv16
namespace: dct-services
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
rules:
- host: v16.dct.com
http:
paths:
- path: /
pathType: Prefix
After creating the ingress configurations, v15.dct.com and v16.dct.com would then be added in the host file so the deployed DCT instance can be accessed by corresponding URLs.