You can translate the document:

Introduction

Deploying Denodo on OpenShift leverages OpenShift's powerful container orchestration and management capabilities. OpenShift, a Kubernetes-based platform from Red Hat, provides a comprehensive solution for automating, deploying, and managing containerized applications at scale. With OpenShift, Denodo deployments benefit from robust DevOps practices, simplified management, and increased operational agility.

This document explains how to create and deploy Denodo images for OpenShift.

Pre-requisites

The Denodo Container Registry Quick Start Guide explains how to get access to the Denodo harbor registry and how to create a pullsecret and how to helm can login to the registry.

Note: the documentation uses ‘kubectl’. These can be substituted by Openshift’s ‘oc’. ‘kubectl get pods’ equals ‘oc get pods’.

Denodo Helm charts

Helm is a package manager for Kubernetes that simplifies the deployment and management of applications by using Helm charts. These charts are pre-configured templates that streamline the installation, upgrading, and maintenance of Kubernetes applications, ensuring consistency and efficiency across deployments.

The Denodo container registry stores Helm charts as OCI artifacts. To access these charts, please use the command 'helm registry login' and enter your credentials.

$ helm registry login harbor.open.denodo.com

 

Username: <denodo_account_username>

Password: <registry_profile_secret>

 Create a secret with the Solution Manager license.

$ oc create secret generic <secret name> --from-file=denodo.lic=<path-to-denodo-license-file> --namespace <namespace into which the secret has to be created>

 Eg.

$ oc create secret generic solution-manager-license --from-file=denodo.lic=/home/denodo/denodo.lic --namespace denodo

 Note: Refer to the Denodo Helm Charts Quick Start Guide for detailed instructions on deploying Denodo using Helm.

Create local references to Denodo images

An ImageStream is an abstraction to manage and track Docker container images. It simplifies the process of deploying, and managing containerized applications by providing a mechanism to reference images from various sources (e.g., Docker Hub, internal registries, or in our case a harbor registry). ImageStreams can also track versions of images and trigger deployments when a new image is available.

The imagestreams point to Solution Manager and VDP Server. It assumes a ‘harbor-registry-secret’ pullsecret is present in the project/namespace.

 Save the following as imagestream.yaml or apply it directly in the Openshift console.

 

apiVersion: image.openshift.io/v1

kind: ImageStream

metadata:

  name: denodo-sm9-imagestream

spec:

  lookupPolicy:

        local: true

  tags:

        - name: '9.0-latest'

          annotations: null

          from:

            kind: DockerImage

            name: 'harbor.open.denodo.com/denodo-9/images/solution-manager-openshift:latest'

---

apiVersion: image.openshift.io/v1

kind: ImageStream

metadata:

  name: denodo-platform9-imagestream

spec:

  lookupPolicy:

        local: true

  tags:

        - name: 'latest'

          annotations: null

          from:

            kind: DockerImage

            name: 'harbor.open.denodo.com/denodo-9/images/denodo-platform-openshift:latest'

 Login to the cluster and apply the yaml.

$ oc apply -f imagestream.yaml

We can now use local image references. E.g:

 image-registry.openshift-image-registry.svc:5000/denodo/denodo-sm9-imagestream.

Create a service account

Service accounts are used to identify and authenticate non-human actors (such as pods) within OpenShift. This identity allows the system to control which resources (e.g., secrets, image streams, or other Kubernetes/OpenShift resources) the pod can access by associating roles and policies.

Create the service account  (sa-denodo), grant it pull privileges and access to the harbor secret.

$ oc create sa sa-denodo

$ oc policy add-role-to-user system:image-puller system:serviceaccount:denodo:sa-denodo --namespace=denodo

$ oc secrets link serviceaccount/sa-denodo harbor-registry-secret --for=pull

 

Deploy Solution Manager

Fill out a values file similar to the provided example, solution-manager-values.yaml. Ensure that the values point to the Solution Manager image. For configuration options, please refer to the Deploying Denodo in Kubernetes documentation.

Eg.

$ helm install sm9 oci://harbor.open.denodo.com/denodo-9/charts/solution-manager-openshift --version 2.0.5 --values solution-manager-values.yaml --namespace denodo

Alternatively, generate the YAML files for deployment by instantiating the Helm templates and adding the values. This approach allows you to verify the deployment before applying it.

$ helm template oci://harbor.open.denodo.com/denodo-9/charts/solution-manager-openshift --version 2.0.5 -n denodo --values solution-manager-values.yaml --name-template solman9 > solman9.yaml

$ oc apply -f solman9.yaml

OpenShift Route

OpenShift Route is a feature that exposes services within an OpenShift cluster to the external network, allowing users outside the cluster to access applications. It acts as a bridge, routing external traffic to the appropriate services inside the cluster.

Add a route to Solution Manager. E.g. solman-route.yaml

 

apiVersion: route.openshift.io/v1

kind: Route

metadata:

  name: solution-manager9

  namespace: denodo

spec:

  host: solution-manager9-denodo.apps-crc.testing

  port:

        targetPort: svc-web

  to:

        kind: Service

        name: sm9-solution-manager-openshift-service

$ oc apply -f solman-route.yaml

Denodo Solution Manager is now accessible at: 

http://solution-manager9-denodo.apps-crc.testing/solution-manager-web-tool/Login

Harmonizing the Denodo encryption key

Denodo uses an encrypting key to protect metadata like passwords. An encryption key will automatically be generated during deployment. It is good practice to share the encryption key between the Solution Manager and Denodo Platform pods. This facilitates tasks such as registering and retrieving platform licenses more efficiently.

Copy the encryption key and create a secret

$ oc cp sm9-solution-manager-openshift-0:/opt/denodo/conf/denodo-key.keystore denodo-key.keystore

$ oc create secret generic denodo-keystore --from-file=denodo-key.keystore=denodo-key.keystore

Retrieve the keystore password to update the solution manager values.

$ oc exec sm9-solution-manager-openshift-0 -c solution-manager-openshift -- jq ".keyStore.password.value" /opt/denodo/conf/denodo-keystore.json

Update solution manager values file with keystore enabled is true and set the keystore password.

keystore:

  enabled: true

  secret: "denodo-keystore"

  loaderType: "FILE"

  loaderLocation: "/opt/denodo/work/keystore/denodo-key.keystore"

  type: "PKCS12"

  password: "<your_keystore_pwd>"

  keyAlias: "denodo_key"

 

 

Apply changes to the Solution Manager Configuration.

$ helm upgrade sm9 oci://harbor.open.denodo.com/denodo-9/charts/solution-manager-openshift --version 2.0.5 --values solution-manager-values.yaml --namespace denodo

 

Deploy Denodo Platform

Fill out a values file similar to the provided example, denodo-platform-values.yaml.

$ helm install vdp9 oci://harbor.open.denodo.com/denodo-9/charts/denodo-platform-openshift --version 2.0.5 --values denodo-platform-values.yaml --namespace denodo

Alternatively, generate the YAML files for deployment.

$ helm template oci://harbor.open.denodo.com/denodo-9/charts/denodo-platform-openshift --version 2.0.5 -n denodo --values denodo-platform-values.yaml --name-template vdp9 > vdp9.yaml

$ oc apply -f vdp9.yaml

Add a route e.g. vdp-route.yaml

 

apiVersion: route.openshift.io/v1

kind: Route

metadata:

  name: denodo-platform9

  namespace: denodo

spec:

  host: denodo-platform9-denodo.apps-crc.testing

  port:

        targetPort: svc-web

  to:

        kind: Service

        name: vdp9-denodo-platform-openshift-service

 

$ oc apply -f vdp-route.yaml

 

 

Disclaimer

The information provided in the Denodo Knowledge Base is intended to assist our users in advanced uses of Denodo. Please note that the results from the application of processes and configurations detailed in these documents may vary depending on your specific environment. Use them at your own discretion.

For an official guide of supported features, please refer to the User Manuals. For questions on critical systems or complex environments we recommend you to contact your Denodo Customer Success Manager.
Recommendation

Recommended resources Recommendations generated by AI

Deploying the Denodo Solution Manager in Kubernetes

Denodo Docker container configuration

Deploying Denodo in Google Kubernetes Engine (GKE)

Data Persistence in Containers

Deploying Denodo in the Azure Kubernetes Service (AKS)

Questions

Ask a question

You must sign in to ask a question. If you do not have an account, you can register here