Skip to main contentCúram on Kubernetes

Deploying Helm Charts

In the following helm install command, we are using releasename as the value for the helm release name. A release name is an arbitrary name that you choose for your deployment. It must be all lowercase. All kubernetes objects in your deployment will be prefixed with whatever value you provide.

For now you could just use releasename and for more information see the helm documentation.

Note: Helm v3 (releasename is mandatory for Helm v3)

helm install releasename local-development/spm

The helm install command installs the Helm Charts in the order in which they were loaded in the repository, with all the values defined in the files. However, as described in Setting up the Docker® context, you can override the configuration value by running the following shell script:

helm install releasename local-development/Curam -f override-values.yaml

Sample override-values.yaml files

The following three override files for Minikube, AKS, and CRC are intended to be used with the config options listed in the Configuration Reference topic. The minimum details that need to be filled out for a successful deployment are the registry, database, and ingress details.

Note on overrides:

  • The full image name is based on the registry, imageLibrary, imagePrefix, and imageTag keys nested under global.images as follows:
    • {registry}/{imageLibrary}/{imagePrefix}curam:{imageTag}
    • With the given values, the resulting image name will look like this: example.azurecr.io/foo-library/test_curam:latest

Note: If storage has been initialized using a version of the runbook older than 20.9.0, you will need to update your override values to include a supplementary group:

global:
  mq:
    security:
      context:
        supplementalGroups: [888]

This is due to a update in IBM MQ, the details of which can be found in IBM MQ charts.

The license agreements for the IBM® WebSphere® Liberty and IBM WebSphere MQ images must be accepted in order to proceed with the deployment of these elements. This can be done by setting the global.license property to accept.

The respective license agreements can be reviewed by running the following commands:

docker run --rm -e LICENSE=view ibmcom/websphere-liberty:25.0.0.3-full-java21-openj9-ubi-minimal
# IBM WebSphere MQ
docker run --rm -e LICENSE=view ibmcom/mq:9.3.5.1

Status of the system

The helm install command shows all the Kubernetes objects and also runs the Cúram containers. You can track the status of the Cúram containers on real time by running the following command:

kubectl get pods -w


NAME                                              READY  STATUS    RESTARTS  AGE
releasename-apps-curam-consumer-595c8bf95f-zn2l5  0/1    Init 3/4  0         5m
releasename-apps-curam-producer-6b5569c4ff-nvxtd  1/1    Running   0         5m
releasename-apps-rest-consumer-85b4865b9d-wr6hj   0/1    Init 3/4  0         5m
releasename-apps-rest-producer-cd8fdbbbf-j2mjj    0/1    Init 3/4  0         5m
releasename-uawebapp-7cdd64987-qx8l8              1/1    Running   0         5m
releasename-web-67697ffb8b-fdsk2                  1/1    Running   0         5m

The command lists the pods and their status, where each status change is on a new line.

Some of the pods have initialization steps, so they are not shown until the steps are completed.

The output of the kubectl get pods command provides the names of the pods that you can use to substitute for podname in the following example commands. For example, the Liberty pod that contains Cúram code is a name that uses a pattern of: releasename-apps-curam-.

You can also describe a pod by running the following command:

kubectl describe pod/pod name

You can also read the log when the status is running, by running the following command:

kubectl logs -f pod/podname

Accessing the application

Once Cúram is deployed, access to the application depends on the target environment:

  • Local environments (Minikube or CodeReady Containers):
    You can typically access the application via a localhost-based URL or a route generated automatically by the environment.

  • OpenShift:
    OpenShift provides a Route resource, which exposes a public URL for the application.

  • Cloud environments (EKS or AKS):
    Access requires additional configuration, such as exposing a LoadBalancer service, setting up an Ingress controller with DNS, or using port forwarding for temporary local access.

Previous
Deploying with Helm Charts: Handling Secrets
Next
Operations: Updating tools