Skip to main content
Skip table of contents

Containerbasierte Installation – Orchestrierte Umgebung

Informationen

  • Die einzelnen Komponenten von PLANTA Project Manager, Worker, Customizing (Datenbank), Web-Client und optional Pulse werden als Container-Images im Docker-Container-Format bereitgestellt und über Helm in einer Kubernetes-Umgebung installiert.

    • Manager ist verantwortlich für die Zugriffe auf die Datenbank sowie für Geschäftslogik, Datenverarbeitung und API-Dienste.

    • Worker stellt Client- bzw. Web-Client-Verbindungen her und führt Hintergrundprozesse aus.

    • Customizing ist ein Initialisierungsjob und enthält Standard-Customizing und kundenspezifische Anpassungen. Er bereitet die Datenbank vor und wird anschließend beendet.

    • Web-Client stellt die Benutzeroberfläche von PLANTA Project im Webbrowser bereit.

    • Pulse (optional) ist die Komponente für Echtzeit‑Zusammenarbeit und Kommunikation.

  • Für Produktions-Workloads empfehlen wir, die Secure-Komponente als Reverse Proxy vorzuschalten (TLS‑Terminierung, Single Sign-On mit OIDC usw.).

  • Die Container-Images können überall dort bereitgestellt werden, wo eine OCI‑kompatible Container Runtime bzw. Plattform vorhanden ist. In einer orchestrierten Umgebung erfolgt der Betrieb auf einem Kubernetes‑Cluster.

  • Die Komponenten werden als Deployments bzw. Jobs mit den notwendigen Services, PersistentVolumeClaims, Ingress‑Ressourcen usw. angelegt. Zusammengenommen stellen sie eine vollständige PLANTA‑Projektmanagement‑Umgebung bereit.

Was ist Helm?

Helm ist ein Paketmanager für Kubernetes, mit dem Anwendungen paketiert, verteilt und mit einem Kommando installiert oder aktualisiert werden können. Anstatt mehrere Kubernetes‑Ressourcendefinitionen manuell zu erstellen, wird die Anwendung als sogenanntes Chart bereitgestellt.

Wichtige Begriffe:

  • Chart: Paket, das alle benötigten Kubernetes‑Ressourcen für eine Anwendung beschreibt.

  • Release: Eine installierte Instanz eines Charts in einem Kubernetes‑Cluster.

  • Values: Konfigurationswerte, mit denen ein Release angepasst wird (z. B. Datenbank‑Zugriffe, Lizenzinformationen, Ressourcenlimits).

Weitere Informationen zu Helm siehe offizielle Dokumentation unter https://helm.sh/docs/.

Voraussetzungen

Vor der Installation in einer orchestrierten Umgebung müssen folgende Voraussetzungen erfüllt sein:

  1. Kubernetes‑Cluster (Version 1.21 oder höher)
    Geeignet sind z. B. AKS, EKS, GKE, OpenShift oder On‑Premises‑Kubernetes.

  2. Helm (Version 3.x oder höher)
    Installationsanleitung Helm

  3. kubectl mit Zugriff auf den Cluster
    Prüfung mit: kubectl cluster-info

  4. Zugriff auf die PLANTA OCI‑Registry

  5. Unterstützte Datenbankinstanz
    Details siehe Systemvoraussetzungen und Plattformen → Abschnitt Database Requirements:

  6. PLANTA‑Lizenz
    Entweder als Lizenznummer oder als Lizenzdatei.

  7. Persistente Speicherung im Cluster

    • Für gemeinsam genutzte Daten: Unterstützung des Modus ReadWriteMany (RWX).

  8. Ingress‑Controller für produktive Umgebungen
    z. B. NGINX, Traefik oder OpenShift Routes.

Helm‑Chart der PLANTA‑Registry herunterladen

Alle Container-Images und das Helm‑Chart sind in der PLANTA‑Registry unter https://registry.planta.services verfügbar. Die Zugangsdaten erhalten Sie von PLANTA. Details zur Anmeldung: https://help.planta.de/en/tec/Container-ab-39.5.24/anmeldung-planta-oci-registry

Option 1: Helm‑Chart direkt installieren

Beispiel:

CODE 
helm install my-planta oci://registry.planta.services/planta/helm \
  --version 1.0.0 \
  --namespace planta \
  --create-namespace \
  --values my-values.yaml

Option 2: Helm‑Chart zuerst lokal ziehen

CODE 
# Chart lokal herunterladen und entpacken
helm pull oci://registry.planta.services/planta/helm \
  --version 1.0.0 --untar
# Installation aus lokalem Chart
helm install my-planta ./helm \
  --namespace planta \
  --create-namespace \
  --values my-values.yaml

Bereitstellung im Kubernetes‑Cluster

  1. Namespace anlegen (falls nicht über Helm erstellt):

    CODE 
    kubectl create namespace planta

  2. Konfigurationsdatei erstellen
    my-values.yaml mit allen benötigten Parametern anlegen bzw. anpassen (Datenbank, Lizenz, Ressourcen, Ingress usw.), siehe den Abschnitt “Konfiguration des helm-Charts”.

  3. Helm‑Chart installieren:

    CODE 
    helm install my-planta oci://registry.planta.services/planta/helm \
  --namespace planta \
  --values my-values.yaml \
  --timeout 10m

  4. Installation überwachen:

    CODE 
    # Pods beobachten
kubectl get pods -n planta -w
# Release-Status prüfen
helm status my-planta -n planta

Konfiguration des Helm‑Charts

Die Konfiguration der Container in der orchestrierten Umgebung erfolgt – analog zur Einzelumgebung mit Docker Compose – über Umgebungsvariablen. In Kubernetes/Helm werden diese entweder direkt über values.yaml oder über Kubernetes‑Secrets gesetzt.

Eine Übersicht über alle verfügbaren Parameter finden Sie im Topic Server- und Client‑Konfiguration.

Minimale erforderliche Konfiguration

Erstellen Sie eine Kopie der Datei values.yaml mit dem Namen my-values.yaml und setzen Sie folgende Parameter:

  • Manager

    • planta__server__hibernate__connection__url

    • planta__server__hibernate__connection__username

    • planta__server__hibernate__connection__password

    • planta__server__ppms_license

  • Pulse (falls verwendet)

    • MONGO_URL

    • MONGO_OPLOG_URL

Diese Parameter entsprechen inhaltlich den Parametern aus den Docker‑Compose‑Templates und werden im Chart als Umgebungsvariablen an die jeweiligen Container übergeben.

Datenbank‑Konfiguration

Konfiguration über Umgebungsvariablen (z. B. Test‑/Entwicklungssysteme)

CODE 
manager:
  env:
    # Beispiel Oracle
    planta__server__hibernate__connection__url: "jdbc:oracle:thin:@hostname:1521/servicename"
    planta__server__hibernate__connection__username: "planta_user"
    planta__server__hibernate__connection__password: "ihr-passwort"

Konfiguration über Kubernetes‑Secrets (empfohlen für produktive Systeme)

Für Datenbank‑Zugangsdaten und andere sensible Konfigurationen sollten Kubernetes‑Secrets verwendet werden. Ein vollständiges Beispiel finden Sie unter: Secret example

Beispielreferenz in den Values:

CODE 
manager:
  secrets:
    userSecretName: "planta-db-secret"

Weitere Details zu verfügbaren Parametern siehe Server- und Client‑Konfiguration.

Lizenz‑Konfiguration

Die Lizenz kann – analog zur Einzelumgebung – entweder als Lizenznummer oder als Datei bereitgestellt werden.

Option 1: Lizenznummer als Umgebungsvariable

CODE 
manager:
  env:
    planta__server__ppms_license: "ihre-lizenznummer"

Option 2: Lizenzdatei über Secret

Variante mit eigenem Secret:

CODE 
manager:
  license:
    enabled: true
    configMapName: ""
    secretName: "ihr-license-secret"
    path: ""

Variante, bei der das Chart das Secret automatisch aus einer lokalen Lizenzdatei erzeugt:

CODE 
manager:
  license:
    enabled: true
    configMapName: ""
    secretName: ""
    path: "license.conf"

Image‑Konfiguration und Registry‑Zugriff

Standardmäßig werden die Images aus der PLANTA‑Registry gezogen. Dafür wird ein ImagePullSecret verwendet:

CODE 
imagePullSecrets:
  - name: registry-credentials

Secret anlegen:

CODE 
kubectl create secret docker-registry registry-credentials \
  --docker-server=registry.planta.services \
  --docker-username=IHR-BENUTZERNAME \
  --docker-password=IHR-PASSWORT \
  --namespace planta

Detaillierte Anleitung zur Authentifizierung siehe Registry‑Dokumentation Anmeldung PLANTA OCI Registry .

Bereitstellung im Kubernetes‑Cluster

Vorgehensweise:

  1. Namespace anlegen (falls nicht über Helm erstellt):

    CODE 
    kubectl create namespace planta

  2. Konfigurationsdatei erstellen
    my-values.yaml mit allen benötigten Parametern anlegen bzw. anpassen (Datenbank, Lizenz, Ressourcen, Ingress usw.).

  3. Helm‑Chart installieren:

    CODE 
    helm install my-planta oci://registry.planta.services/planta/helm \
  --namespace planta \
  --values my-values.yaml \
  --timeout 10m

  4. Installation überwachen:

    CODE 
    # Pods beobachten
kubectl get pods -n planta -w
# Release-Status prüfen
helm status my-planta -n planta

Zugriff auf PLANTA

Nach erfolgreicher Installation den Status der Pods überprüfen:

CODE 
kubectl get pods -n planta

Alle relevanten Pods sollten im Status Running sein. Der Zugriff auf den Web‑Client erfolgt in produktiven Umgebungen über den konfigurierten Ingress bzw. die Route.

Für Testzwecke ohne Ingress kann Port‑Forwarding verwendet werden:

CODE 
# Zugriff auf den Web-Client
kubectl port-forward svc/my-planta-webclient 5000:5000 -n planta
# Aufruf im Browser:
# http://localhost:5000

Aktualisierung (Upgrade) einer bestehenden Installation

Vorgehensweise:

  1. Konfigurationsdatei my-values.yaml an neue Anforderungen oder Chart‑Version anpassen.

  2. Release aktualisieren:

    CODE 
    helm upgrade my-planta oci://registry.planta.services/planta/helm \
  --namespace planta \
  --values my-values.yaml \
  --version 1.1.0

  3. Upgrade überwachen:

    CODE 
    kubectl rollout status deployment/my-planta-manager -n planta
kubectl get pods -n planta

Deinstallation

Um eine PLANTA‑Installation aus dem Cluster zu entfernen:

CODE 
# Uninstall the Helm release
helm uninstall my-planta -n planta

# Optionally, delete the namespace and all resources
kubectl delete namespace planta

Erweiterte Konfiguration

Ressourcenlimits (CPU/RAM)

Beispielkonfiguration:

CODE 
manager:
  resources:
    requests:
      memory: "2Gi"
      cpu: "1000m"
    limits:
      memory: "4Gi"
      cpu: "2000m"

webclient:
  resources:
    requests:
      memory: "512Mi"
      cpu: "250m"
    limits:
      memory: "1Gi"
      cpu: "500m"

Empfehlungen zur Dimensionierung siehe Systemvoraussetzungen und Plattformen.

Speicherklassen und Persistenz

Speicherklassen für für persistente Volumes definieren:

CODE 
storageClassName: "fast-ssd"  # Global storage class

# Per-component storage configuration
transfer:
  persistence:
    size: 1Gi
    accessMode: ReadWriteMany
    # Optionally override storage class for shared volume
    storageClassName: ""

webclient:
  persistence:
    size: 5Gi
    accessMode: ReadWriteOnce

pulse:
  persistence:
    size: 10Gi
    accessMode: ReadWriteOnce

Selbstverwaltete PVCs

Standardmäßig erstellt das Chart automatisch PersistentVolumeClaims und bindet diese in jede Bereitstellung/jeden Job für jede Komponente ein, die persistenten Speicher benötigt. Wenn Sie die volle Kontrolle wünschen – beispielsweise um benutzerdefinierte Labels, Anmerkungen oder Volume-Bindungsmodi festzulegen oder vorab bereitgestellte Volumes wiederzuverwenden –, können Sie die automatische PVC-Erstellung pro Komponente deaktivieren.

Wenn persistence.create: false:

  • Die PVC-Ressource wird nicht vom Diagramm erstellt.

  • Sie stellen das Volume selbst über additionalVolumes / additionalVolumeMounts bereit, die auf das von Ihnen erstellte PVC verweisen.

Eigene PVCs verwenden

Falls PVCs nicht automatisch durch das Chart erzeugt werden sollen:

CODE 
transfer:
  persistence:
    create: false
manager:
  additionalVolumes:
    - name: my-transfer
      persistentVolumeClaim:
        claimName: my-company-transfer-pvc
  additionalVolumeMounts:
    - name: my-transfer
      mountPath: /mnt/transfer
      readOnly: true
worker:
  additionalVolumes:
    - name: my-transfer
      persistentVolumeClaim:
        claimName: my-company-transfer-pvc
  additionalVolumeMounts:
    - name: my-transfer
      mountPath: /mnt/transfer
      readOnly: true
customizing:
  additionalVolumes:
    - name: my-transfer
      persistentVolumeClaim:
        claimName: my-company-transfer-pvc
  additionalVolumeMounts:
    - name: my-transfer
      mountPath: /mnt/transfer
      readOnly: false

Analog für Web‑Client und Pulse:

CODE 
webclient:
  persistence:
    create: false
  additionalVolumes:
    - name: my-webclient-data
      persistentVolumeClaim:
        claimName: my-company-webclient-pvc
  additionalVolumeMounts:
    - name: my-webclient-data
      mountPath: /var/planta
pulse:
  persistence:
    create: false
  additionalVolumes:
    - name: my-pulse-data
      persistentVolumeClaim:
        claimName: my-company-pulse-pvc
  additionalVolumeMounts:
    - name: my-pulse-data
      mountPath: /app/data

Hinweis: Wenn create: false gesetzt ist, werden PVCs bei der Deinstallation nicht automatisch gelöscht.

Platzierung der Pods (Node Affinity, Tolerations)

CODE 
manager:
  nodeSelector:
    disktype: ssd
  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "planta"
      effect: "NoSchedule"
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/zone
            operator: In
            values:
            - zone-1
            - zone-2

Zusätzliche Volumes

CODE 
manager:
  additionalVolumes:
    - name: custom-config
      configMap:
        name: my-custom-config
  additionalVolumeMounts:
    - name: custom-config
      mountPath: /etc/custom
      readOnly: true

Sitzungsaffinität (Sticky Sessions)

Für skalierte Web‑Client‑Deployments kann Sitzungsaffinität konfiguriert werden.

Service‑seitige ClientIP‑Affinität

CODE 
webclient:
  service:
    sessionAffinity:
      enabled: true
      timeoutSeconds: 3600

Ingress‑seitige Cookie‑basierte Affinität (z. B. NGINX)

Für den Browser-Verkehr sind Cookie-basierte Sticky-Sessions zuverlässiger. Diese werden über globale ingress.annotations konfiguriert und gelten für alle Ingress-Ressourcen.

CODE 
ingress:
  enabled: true
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/affinity-mode: "balanced"
    nginx.ingress.kubernetes.io/session-cookie-name: "PLANTASESSIONID"
    nginx.ingress.kubernetes.io/session-cookie-expires: "3600"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "3600"
    nginx.ingress.kubernetes.io/session-cookie-path: "/"
    nginx.ingress.kubernetes.io/session-cookie-samesite: "Lax"
    nginx.ingress.kubernetes.io/session-cookie-secure: "true"
    nginx.ingress.kubernetes.io/session-cookie-change-on-failure: "true"

Für andere Ingress-Controller (Traefik, HAProxy usw.) passen Sie die Anmerkungen entsprechend an. Die richtigen Anmerkungsschlüssel finden Sie in der Dokumentation Ihres Ingress-Controllers.

Hinweis: Die Cookie-basierte Affinität wird vom Ingress-Controller verarbeitet und hat Vorrang vor der ClientIP-Affinität für externen Datenverkehr. Beide Mechanismen können sicher nebeneinander existieren – die Cookie-Affinität verarbeitet den externen/Browser-Datenverkehr, während ClientIP den internen oder direkten Servicezugriff abdeckt.

Sticky Sessions auf Ingress-Ebene wirken sich nur auf das Routing von Browser → Webclient aus, nicht auf die interne Verbindung von Webclient → Worker (die ClientIP-Affinität auf dem Worker-Service verwendet).

Eigene Ingress-/Route‑Definitionen

Falls Ingress‑Ressourcen extern verwaltet werden sollen (z. B. über GitOps), kann die im Chart eingebaute Ingress‑Erzeugung deaktiviert und eigene Ingress‑Definitionen erstellt werden. Die vom Chart angelegten Services dienen dann als Ziele für diese Ingress‑ oder Route‑Ressourcen.

Komponenten deaktivieren

CODE 
pulse:
  enabled: false

webclient:
  enabled: false

Customizing‑Deployments (Export/Import)

PLANTA unterstützt das Customizing‑Deployments (Änderungen, die zwischen Umgebungen durch den Export und Import übertragen werden können (z. B. von einem Entwicklungssystem in die Produktion) über einen separaten Kubernetes‑Job auf Basis des Manager‑Images. Ein Beispiel für eine Jobdefinition finden Sie in der cu-deployment-example.yaml. Kopieren Sie diese Datei als Ausgangspunkt und passen Sie sie an Ihre Umgebung an.

Ausführliche Beschreibung zu Kundecustomizing-Deployment finden Sie hier.

Voraussetzungen

  • Laufende PLANTA‑Installation mit erreichbarer Datenbank

  • PLANTA-Registry‑Zugriff für das Manager‑Image

  • Gemeinsames Volume für .par‑ und .zip‑Dateien

  • Datenbank‑Zugangsdaten (möglichst über Secret; siehe secret-example.yaml)

Wichtig: Der Customizing Deployment Job stellt eine direkte Verbindung zur Datenbank her. Stellen Sie sicher, dass während des Exports oder Imports keine konkurrierenden Vorgänge auf derselben Datenbank ausgeführt werden.

So funktioniert es

Vorgehensweise:

  1. Der Job führt den PLANTA Manager-Container mit einem speziellen Export- oder Importargument aus. Der Container:

  2. Stellt mithilfe der bereitgestellten Anmeldedaten eine Verbindung zur Datenbank her.

  3. Liest die .par-Datei, in der festgelegt ist, welche Anpassungsobjekte exportiert oder importiert werden sollen.
    Schreibt eine exportierte .zip-Datei auf das gemountete Volume (Exportmodus) oder liest eine .zip-Datei und wendet sie auf die Datenbank an (Importmodus).

  4. Beendet den Vorgang nach Abschluss – Kubernetes markiert den Job als erfolgreich oder fehlgeschlagen.

Job anwenden:

CODE 
kubectl apply -f cu-deployment.yaml -n IHR_NAMESPACE

Job überwachen:

CODE 
# Check job status
kubectl get jobs -n YOUR_NAMESPACE

# Follow the job logs
kubectl logs job/cu-deployment -n YOUR_NAMESPACE -f

Der Job ist wie folgt konfiguriert:

  • 30-minütige Zeitüberschreitung (activeDeadlineSeconds: 1800) – der Job wird beendet, wenn diese Dauer überschritten wird

  • Keine Wiederholungsversuche (backoffLimit: 0) – ein fehlgeschlagener Lauf wird nicht automatisch wiederholt

  • Automatische Bereinigung nach 1 Stunde (ttlSecondsAfterFinished: 3600) – die abgeschlossene/fehlgeschlagene Job-Ressource wird automatisch entfernt


Um den Job erneut auszuführen, löschen Sie zunächst den vorherigen Job:

CODE 
kubectl delete job cu-deployment -n YOUR_NAMESPACE
kubectl apply -f cu-deployment.yaml -n YOUR_NAMESPACE

  • Verwenden Sie Secrets für Anmeldedaten in der Produktion. Vermeiden Sie es, Datenbankpasswörter direkt in die Job-YAML einzufügen. Erstellen Sie stattdessen ein Secret (siehe secret-example.yaml) und verweisen Sie darauf über envFrom.secretRef.

  • Sichern Sie Ihre Datenbank vor dem Ausführen eines Imports, insbesondere in Produktionsumgebungen.

  • Die .par-Datei muss innerhalb des Containers unter dem in args angegebenen Pfad zugänglich sein. Sie muss in dem Verzeichnis abgelegt werden, das unter /var/planta/export/ gemountet ist.

  • Volume-Typ: Das Beispiel verwendet hostPath, das für Single-Node-Cluster und lokale Entwicklung geeignet ist. Verwenden Sie für Produktions- oder Multi-Node-Cluster einen geeigneten Volume-Typ (z. B. NFS, PersistentVolumeClaim oder cloudspezifischer Speicher).

  • Image-Tag: Aktualisieren Sie das Image-Feld entsprechend der PLANTA-Version Ihrer Installation.

Fehlerbehebung

Pods starten nicht

CODE 
kubectl get pods -n planta
kubectl describe pod <pod-name> -n planta
kubectl logs <pod-name> -n planta

Typische Ursachen:

  • ImagePullBackOff: ImagePullSecret oder Registry‑Zugang prüfen.

  • CrashLoopBackOff: Anwendungslogs auf Fehler prüfen.

  • Pending: Ressourcenmangel oder Probleme bei PVC‑Binding prüfen.

Datenbankverbindung schlägt fehl

Überprüfen Sie die Datenbankverbindung:

CODE 
kubectl logs -n planta deployment/my-planta-manager
kubectl run -it --rm debug --image=busybox \
  --restart=Never -n planta -- sh
# innerh. Container:
# telnet datenbank-host 1521

Probleme mit Persistent Volumes

PVC-Status überprüfen:

CODE 
kubectl get pvc -n planta
kubectl describe pvc <pvc-name> -n planta
kubectl get storageclass

Wenn PVCs ausstehen, stellen Sie Folgendes sicher:

  • Speicherklasse existiert: kubectl get storageclass

  • Ausreichend Speicherplatz verfügbar

  • Zugriffsmodus wird unterstützt (insbesondere ReadWriteMany)

Ingress funktioniert nicht

CODE 
kubectl get ingress -n planta
kubectl describe ingress <ingress-name> -n planta

Prüfen Sie, ob

  • ein Ingress‑Controller läuft

  • DNS korrekt gesetzt ist und

  • ggf. TLS‑Zertifikate gültig sind

Aktuelle Helm‑Werte anzeigen

CODE 
helm get values my-planta -n planta

oder

CODE 
helm get values my-planta -n planta --all

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close