# procurex Helm-Chart

Kubernetes/Helm-Deploymentkonzept für PROCUREX — **PRX-22**. Deployt `procurex-app` (Backend) und
`procurex-frontend` in einen eigenen Namespace.

## Reproduzierbare Chart-Prüfung

Die lokale Syntax- und Renderprüfung läuft über:

```powershell
..\..\tools\validate-helm.ps1
```

`helm lint` und `helm template` waren am 10.08.2026 erfolgreich; Helm meldet lediglich, dass
ein optionales Chart-Icon fehlt. Auf dem lokalen Rechner war kein Kubernetes-Kontext
konfiguriert, daher wurde kein Live-Cluster-Deployment behauptet.

Für ein echtes Lerncluster sind zusätzlich erforderlich:

```powershell
kind create cluster --config helm/procurex/kind-cluster-config.yaml
helm upgrade --install procurex helm/procurex --namespace procurex --create-namespace
kubectl rollout status deployment/procurex-backend -n procurex
kubectl rollout status deployment/procurex-frontend -n procurex
```

Vor dem Installieren müssen die Images in einem für das Cluster erreichbaren Registry- oder
`kind load docker-image`-Setup vorhanden sein. PostgreSQL, Kafka und Keycloak werden weiterhin
als externe Plattformdienste vorausgesetzt. Die Verbindungswerte sind in `values.yaml` explizit
konfiguriert und müssen für die jeweilige Clusterumgebung per Values-Override angepasst werden.
Das Backend benötigt DNS sowie die Zielports 5432 (PostgreSQL), 8080 (Keycloak/JWK) und 9092
(Kafka); diese Ports werden von der aktivierten NetworkPolicy freigegeben.

## Wichtige Einschränkung

`enterprise-infrastructure` (Postgres, Traefik, ...) läuft als **Docker-Compose-Plattform**, nicht in
Kubernetes (siehe Confluence Seite 12 / `PROCUREX-PLANUNGSENTSCHEIDUNGEN.md`). Ein Kubernetes-
Deployment von PROCUREX ist damit ein **separates Zielbild**, das nicht automatisch an das lokale
`enterprise-infrastructure` andockt — die Plattformdienst-Adressen in `backend.env` in `values.yaml` sind
entsprechend Platzhalter und müssen für eine echte Umgebung auf tatsächlich erreichbare
PostgreSQL-, Kafka- und Keycloak-Instanzen angepasst werden.

**Live-Deployment-Versuch (09.08.2026, zwei Anlaeufe):** `helm lint`/`helm template` sind gruen.
Ein echter Deploy gegen einen lokalen `kind`-Cluster (Config: `kind-cluster-config.yaml`) ist
beide Male am Cluster-Aufbau selbst gescheitert, nicht am Chart:

1. Erster Versuch: kind-Node-Container mit Exit-Code 137 (SIGKILL) waehrend `kubeadm init`
   beendet, vermutlich Speicherdruck durch parallel laufende `enterprise-infrastructure`/PROCUREX-Container.
2. Zweiter Versuch: `shared-kafka`/`shared-kafka-ui`/`shared-keycloak` vorher gestoppt, um
   Speicher freizugeben — Node-Container blieb diesmal am Leben, aber `kubeadm init` scheiterte
   an `context deadline exceeded` beim Anlegen der ersten ClusterRoleBinding (API-Server
   antwortete, aber zu langsam/instabil innerhalb des 10s-Timeouts).

Deutet auf eine grundsaetzliche Leistungs-/Virtualisierungseinschraenkung dieser konkreten
Sandbox-Umgebung hin (nicht auf einen Konfigurationsfehler) — vermutlich nicht durch weitere
Retries mit demselben Ansatz loesbar. `kind-cluster-config.yaml` bleibt im Repo, um den Deploy
auf einer Maschine mit mehr verfuegbaren Ressourcen/ohne diese Virtualisierungseinschraenkung
direkt nachvollziehen zu koennen: `kind create cluster --config helm/procurex/kind-cluster-config.yaml`,
danach `helm install procurex helm/procurex -n procurex --create-namespace`.

## Namespace

Alle Ressourcen laufen im Namespace `procurex` (`values.yaml: namespace`), wird vom Chart selbst
angelegt (`templates/namespace.yaml`).

## Values

Siehe `values.yaml` — pro Komponente (`backend`/`frontend`): Image/Tag, Replicas, Container-Port,
Resources, Probe-Pfade/-Timings. `ingress.*` steuert die beiden Hostnamen, `networkPolicy.enabled`
schaltet die NetworkPolicies ein/aus.

## Secrets

**Keine produktiven Secrets werden versioniert** (gleiches Prinzip wie bei PRX-21/`.env`). Das
Chart referenziert nur einen vorhandenen Secret-Namen (`backend.existingSecretName`, Default
`procurex-db-credentials`) über `envFrom.secretRef` — er muss vor dem Deployment separat angelegt
werden:

```
kubectl create secret generic procurex-db-credentials -n procurex \
  --from-literal=PROCUREX_DB_PASSWORD=<wert>
```

## Probes

Backend: `/actuator/health/liveness` und `/actuator/health/readiness` (Spring-Boot-Health-Groups,
aktiviert in `procurex-app/application.yml` über `management.endpoint.health.probes.enabled`).
Frontend: `/` (nginx antwortet nur, wenn der statische Build erfolgreich ausgeliefert wird).

## Limits

`resources.requests`/`resources.limits` pro Komponente in `values.yaml` — Lernprojekt-Defaults
(Backend 100m/384Mi Request, 500m/512Mi Limit; Frontend 50m/64Mi Request, 250m/128Mi Limit), vor
echtem Betrieb mit Lasttest-Ergebnissen (Confluence Seite 13) abzugleichen.

## NetworkPolicies

`templates/networkpolicy.yaml`: Das Backend akzeptiert Ingress nur vom Frontend (gleicher
Namespace) und vom Ingress-Controller; das Frontend nur vom Ingress-Controller. Egress vom Backend
ist auf DNS sowie die Ports 5432 (PostgreSQL), 8080 (Keycloak/JWK) und 9092 (Kafka) beschränkt.

## Rollback

Standard-Helm-Mechanismus, kein Zusatzscript nötig:

```
helm history procurex -n procurex
helm rollback procurex <revision> -n procurex
```

## Backup — Annahme

Datenbank-Backups sind **nicht** Teil dieses Charts, da PostgreSQL außerhalb von Kubernetes läuft
(`enterprise-infrastructure`, siehe oben). Backup/Restore der Datenbank wird in
`../../docs/runbooks/backup-restore.md` beschrieben. Anwendungsseitig sind die Pods zustandslos
(kein PersistentVolume nötig) — ein Rollback auf eine ältere Revision ersetzt lediglich die Pods,
ohne Datenverlust.

## Validieren

```
helm lint helm/procurex
helm template procurex helm/procurex
```