Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -13,4 +13,5 @@ __pycache__
**/.fuse*
dev/.env
.venv
.env
.env
/deployment/dev/data/stroke
6 changes: 3 additions & 3 deletions deployment/dev/.env.example
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
# Versions
EXAFLOW=1.0.0
PLATFORM_BACKEND=9.1.1
PLATFORM_UI=1.0.1
MIP=9.0.2
PLATFORM_BACKEND=9.2.0
PLATFORM_UI=1.1.0
MIP=9.0.3

# Toggle authentication
AUTHENTICATION=0
Expand Down
3 changes: 0 additions & 3 deletions deployment/dev/docker-compose.yml
Original file line number Diff line number Diff line change
Expand Up @@ -180,9 +180,6 @@ services:
PLATFORM_BACKEND_SERVER: platform-backend:8080
PLATFORM_BACKEND_CONTEXT: services
NOTEBOOK_ENABLED: 0
FRONTEND_VERSION: "${PLATFORM_UI}"
BACKEND_VERSION: "${PLATFORM_BACKEND}"
EXAFLOW_VERSION: "${EXAFLOW}"
MIP_VERSION: "${MIP}"
depends_on:
- platform-backend
Expand Down
44 changes: 18 additions & 26 deletions deployment/kubernetes/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ MIP now supports two Kubernetes infrastructure options:
1. **VM-based / microk8s clusters** – the remainder of this document (starting in the Requirements section) walks through preparing Ubuntu virtual machines and installing the stack on top of microk8s.
2. **Managed clusters** – for cloud-managed Kubernetes (AKS/EKS/GKE, etc.) follow the [mip-infra getting started guide](https://github.com/Medical-Informatics-Platform/mip-infra?tab=readme-ov-file#-getting-started) to provision the cluster and its base services. Once the cluster is available, return here for component configuration details as needed.

Choose between these modes via the Helm values: set `managed_cluster: true` (managed) or `false` (microk8s/VM). The templates react to this flag to deploy the components with the right assumptions for networking, storage, and access.
Choose between these modes via the Helm values: set `cluster.managed: true` (managed) or `false` (microk8s/VM). The chart now keeps the same workload shape in both modes and uses the flag only to select the storage class and, for microk8s, bootstrap the local `StorageClass`.

## Requirements
### Hardware
Expand Down Expand Up @@ -53,54 +53,40 @@ Afterward, The dataset CSV files should be placed in their proper pathology fold
## Configuration
Prior to deploying it (on a microk8s K8s cluster of one or more nodes), there are a few adjustments to make in `values.yaml`. Each top-level section controls a part of the stack:

* `cluster`: namespace, storage classes and whether the cluster provisions persistent volumes dynamically (`managed: true`).
* `network`: public hostname, protocols, and whether the UI is exposed directly or through a reverse proxy (`link`).
* `platform-ui`, `platform-backend`, `platformBackendDatabase`: container images and component specific options (including the platform-ui ingress/tls settings).
* `keycloak`: toggles the connection parameters to the external Keycloak instance (`enabled`, `host`, `protocol`, `realm`, `clientId`).
* `cluster`: storage classes and whether the chart should use the managed storage class or the microk8s local storage class.
* `global`: shared public hostname used by the ingress and backend redirects.
* `platform-ui`, `platform-backend`, `platformBackendDatabase`: container images and component specific options (including the shared ingress/tls settings and PVC sizes).
* `keycloak`: toggles the connection parameters to the external Keycloak instance (`enabled`, `host`, `protocol`, `realm`).

Copy `values.yaml` to a new file (for example `my-values.yaml`) and edit it in-place. A few important knobs:

```yaml
network:
link: proxied # use "direct" when exposing the UI publicly
global:
publicHost: mip.example.org
publicProtocol: https

platform-ui:
backend:
host: platform-backend-service
port: 8080
context: services
ingress:
redirectRootTo: /home # optional 302 redirect for the landing page
tlsSecretName: platform-ui-tls

keycloak:
enabled: true
host: iam.example.org
protocol: https
realm: MIP
clientId: mipfed
```

The reachability diagram from the legacy profiles is still valid as a reference for deciding the correct `network.*` settings:
The reachability diagram from the legacy profiles is still valid as a reference for deciding the correct public URL:
![MIP Reachability Scheme](../docs/MIP_Configuration.png)

### MACHINE_MAIN_IP
This is the machine's main IP address. Generally, it's the IP address of the first NIC after the local one.
If the MIP is running on top of a VPN, you may want to put the VPN interface's IP address.
If you reach the machine through a public IP, if this IP is **NOT** directly assigned on the machine, but is using static NAT, you still **MUST** set the **INTERNAL** IP of the machine itself!
`global.publicHost` defaults to `hbpmip.link`. Override it in your custom values file or with `--set-string global.publicHost=<hostname>` whenever a deployment needs a different public hostname.

### MACHINE_PUBLIC_FQDN
This is the public, fully qualified domain name of the MIP, the main URL on which you want to reach the MIP from the Internet. This may point:
* Directly on the public IP of the MIP, for a **direct** use case. It may be assigned on the machine or used in front as a static NAT
* On the public IP of the reverse-proxy server, for a **proxied** use case
`global.publicHost` must be the bare hostname served by the ingress, without `http://` or `https://`.

### MACHINE_PRIVATE_FQDN_OR_IP
This is **ONLY** used in a **proxied** use case situation.
It's actually the internal IP or address from which the reverse-proxy server "sees" (reaches) the MIP machine.
`keycloak.protocol` defaults to `https` and `keycloak.realm` defaults to `MIP`. Override them only when your external Keycloak differs from those defaults.

These three settings map directly to the `network` section in `values.yaml` (`publicHost`, `link`, `publicProtocol`). When running behind a reverse proxy also set `externalProtocol` to describe the protocol used between the proxy and the MIP pods.
If you deploy behind a reverse proxy or load balancer, forward the standard `X-Forwarded-*` headers to the backend so Spring can reconstruct the public request URL correctly.

**WARNING!**: In **ANY** case, when you use an **EXTERNAL** KeyCloak service (i.e. iam.ebrains.eu), make sure that you use the correct *CLIENT_ID* and *CLIENT_SECRET* to match the MIP instance you're deploying!

Expand All @@ -124,7 +110,7 @@ sudo adduser mipadmin microk8s

As *mipadmin* user:
```
microk8s enable dns helm3 ingress
microk8s enable dns helm3 ingress storage
```
```
sudo mkdir -p /data/<MIP_INSTANCE_OR_FEDERATION_NAME>
Expand All @@ -133,6 +119,10 @@ sudo mkdir -p /data/<MIP_INSTANCE_OR_FEDERATION_NAME>
sudo chown -R mipadmin.mipadmin /data
```

The web-app chart uses dynamically provisioned PVCs on microk8s too. The `storage` addon provides the `k8s.io/microk8s-hostpath` provisioner, and the chart bootstraps a local `StorageClass` on top of it for the MIP PVCs. That `StorageClass` uses `WaitForFirstConsumer` binding so PVC placement follows pod scheduling more safely on multi-node microk8s clusters.

On microk8s, the MIP web-app chart schedules both `platform-backend` and `platform-ui` onto nodes labeled `master=true`, so make sure the node intended to host the stack carries that label.

For a "federated" deployment, you may want to add nodes to your cluster. "microk8s add-node" will give you a **one-time usage** token, which you can use on a worker node to actually "join" the cluster. This process must be repeated on all the worker nodes.

### Exaflow Deployment
Expand Down Expand Up @@ -182,9 +172,11 @@ For a more in-depth guide on deploying Exaflow, please refer to the documentatio
```

* Copy `values.yaml` to `/opt/mip-deployment/kubernetes/my-values.yaml` and tailor it to your environment.
* On microk8s, keep `cluster.managed: false` so the chart uses the local storage class it bootstraps.
* Deploy (or upgrade) the Helm release with your customised values
```
microk8s helm3 upgrade --install mip \
--namespace <target-namespace> \
-f /opt/mip-deployment/kubernetes/my-values.yaml \
/opt/mip-deployment/kubernetes
```
Expand Down
48 changes: 0 additions & 48 deletions deployment/kubernetes/templates/_helpers.tpl

This file was deleted.

Original file line number Diff line number Diff line change
Expand Up @@ -7,5 +7,5 @@ metadata:
labels:
app: {{ $localStorageClass }}
provisioner: k8s.io/microk8s-hostpath
volumeBindingMode: Immediate
volumeBindingMode: WaitForFirstConsumer
{{- end }}
42 changes: 0 additions & 42 deletions deployment/kubernetes/templates/mip-config.yaml

This file was deleted.

Loading
Loading