PROCUREX · Statische HTML-Dokumentation

procurex Helm-Chart

Aus helm\procurex\README.md konvertiert – vollständig lokal lesbar.

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:

..\..\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:

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.

  1. 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
⌂ Cockpit