Skip to content

Deployment Overview

While Orthanc application focuses on the core features in medical imaging, to operationalize it on Kubernetes platform, we need numerous auxiliary services for automation, traffic management, observability and security. Luckily, the cloud native ecosystem brings a plethora of open-source choices.

Source Code Repository

The repository for Korthweb is hosted on GitHub at:

https://github.com/digihunch/korthweb

Please clone the repository to your local command terminal. 

git clone git@github.com:digihunch/korthweb.git

For GitOps approach, you will need to fork the korthweb repo to your own GitHub account.

Deployment Approaches

There are three deployment approaches. Each approach differs in complexity and level of automation but all lead to a functional Orthanc deployment. The approaches are summarized as below:

Approach Components Installed Key Features and Considerations
GitOps - Istio CRD as Ingress
- Other Service Mesh features supported by Istio
- PostgreSQL
- Cert-Manager
- Observability
- Multi-tenancy		 - Includes artifacts for GitOps-based automated deployment using FluxCD.
- Take this approach for continuous deployment and end-to-end automation.
- Two tenants are deployed, for two fictitious healthcare facilities acronymed BHC and MHR.
Helm - Traefik CRD as Ingress
- PostgreSQL		 - Includes the Helm chart to configure Orthanc and its dependencies with a single command.
- Take this approach to quickly install Orthanc on Kubernetes.
Manual - Istio CRD as Ingress
- Other Service Mesh features supported by Istio
- PostgreSQL
- Cert-Manager
- Observability (Lite)		 - Includes artifacts for users to manually apply.
- Consider this option ONLY for troubleshooting or learning deployment

The artifacts of each approach are stored in eponymous sub-directories. Korthweb recommends the GitOps approach.

CLI tools

During the deployment process, we need a variety of CLI tools to interact with the cluster, such as:

  • kubectl: connect to API server to manage the Kubernetes cluster. With multiple clusters, you need to switch context. We need it in all three approaches.
  • helm: helm is package manager for Kubernetes. The name of Helm's CLI tool is helm. We use it in manual and Helm approaches.
  • istioctl: in the manual approach we use istioctl to install Istio.
  • flux: FluxCD is a GitOps tool to keep target Kubernetes cluster in sync with the source of configuration in the GitOps directory. The name of FluxCD's CLI tool is flux, and we use it in the GitOps approach.

Have them installed on your local environment. Ensure that kubectl connects to the cluster correctly. Other CLI tools helm, istioctl and flux all use kubectl's connection profile.

Orthanc Configuration File

When running as an Operating System process (non-containerized runtime), the Orthanc process expects a JSON file as configuration input. When we host Orthanc application in containers on Kubernetes, we run multiple Orthanc Pods. We have to make sure all the Orthanc Pods share a single instance of the configuration file.

Kubernetes ConfigMaps object fulfills our target here. We store the content of the JSON file as a ConfigMap. The name of the ConfigMap is orthanc-app. When we launch an Orthanc Pod, we tell the Pod to mount the ConfigMap entry as a file within the Pod for the Orthanc process in the Pod to consume.