Helm-Deployment¶

Installiere DATAMIMIC 4.0.0 mit einem öffentlichen Hostnamen und einer gespeicherten values.yaml. Wähle unten HTTPS am Ingress, HTTPS an einem vorgeschalteten Proxy oder HTTP. Verwende die Chart-Version und die passende Anwendungsversion aus Deiner Release-Benachrichtigung.

1. Bevor Du beginnst¶

Du benötigst:

Kubernetes-Zugriff, Helm, einen Ingress-Controller und einen Ziel-Namespace.
Registry-Zugangsdaten und Zugriff auf die Container-Images. In Offline-Clustern müssen die Images in der eigenen Registry oder im Node-Cache verfügbar sein; das Chart-Archiv allein reicht nicht.
Einen DNS-Hostnamen, der auf den Ingress oder den vorgeschalteten Proxy zeigt.
Für HTTPS: ein Zertifikat, dem die Browser vertrauen. Eine interne CA funktioniert auch in Air-Gap-Umgebungen; cert-manager ist optional, wenn Du das Zertifikat selbst bereitstellst.
Das unterstützte Chart-Archiv oder dessen genaue Harbor-OCI-Version.

2. Was das Chart ausrollt¶

Das Chart installiert Backend (einschließlich Web-UI), Celeryworker, Scheduler, Task-Monitor, PostgreSQL, MinIO, Redis und RabbitMQ. Die Release-Pipeline setzt passende Image-Tags für die Anwendung; normalerweise musst Du sie nicht überschreiben.

Jede mitgelieferte Abhängigkeit lässt sich mit <component>.install: false deaktivieren, wenn Du ihre externe Verbindung konfigurierst.

3. Erstelle das Image-Pull-Secret¶

Erstelle Namespace und Registry-Secret einmal vor der Installation:

kubectl create namespace <namespace>
kubectl create secret docker-registry rdd-harbor-registry-secret \
  --docker-server=harbor.rapiddweller.com \
  --docker-username=<username> \
  --docker-password=<password> \
  -n <namespace>

Überspringe die Namespace-Erstellung, falls er bereits existiert. Der Standardname des Secrets gilt für die Anwendungs-Images und die mitgelieferten Abhängigkeiten. Bei einem anderen Namen setze sowohl global.applicationImagePullSecrets als auch global.imagePullSecrets auf [{name: <your-secret-name>}].

helm registry login authentifiziert die Helm-CLI beim Herunterladen des Charts. Es erstellt nicht das Image-Pull-Secret, das Kubernetes verwendet.

4. Stelle die Anwendungs-Secrets bereit¶

Beide Anwendungsschlüssel sind erforderlich. Erzeuge sie einmal und bewahre sie in Deinem Secret-Store auf:

export DM_SECRET_KEY="$(openssl rand -base64 32)"
export DM_PROJECT_TOKEN_SECRET="$(openssl rand -base64 32)"

Erstelle über Deine übliche Secret-Verwaltung ein Kubernetes-Secret namens datamimic-application im Ziel-Namespace mit diesen Schlüsseln:

Secret-Schlüssel	Wert
`DM_SECRET_KEY`	Der gespeicherte Schlüssel für Verschlüsselung und Pseudonymisierung
`DM_PROJECT_TOKEN_SECRET`	Der gespeicherte Signierschlüssel für Projekttokens
`DM_FIRST_ADMIN_PASSWORD`	Dein initiales Administratorpasswort

Für eine manuelle Installation erstelle es einmal mit den gespeicherten Schlüsseln und Deinem Administratorpasswort:

kubectl create secret generic datamimic-application -n <namespace> \
  --from-literal=DM_SECRET_KEY="$DM_SECRET_KEY" \
  --from-literal=DM_PROJECT_TOKEN_SECRET="$DM_PROJECT_TOKEN_SECRET" \
  --from-literal=DM_FIRST_ADMIN_PASSWORD='<your-admin-password>'

Die Beispiele unten referenzieren dieses Secret über global.password_secret. Behalte die Schlüssel bei Upgrades bei: Ein geänderter Verschlüsselungsschlüssel kann gespeicherte Git-Zugangsdaten unlesbar machen; ein geänderter Signierschlüssel macht bestehende Projekttokens ungültig. Browser-Sessions verwenden serverseitige Session-IDs.

5. Wähle den öffentlichen Zugriff¶

Das Schema beschreibt die URL im Browser des Benutzers, unabhängig davon, wo TLS terminiert.

Zugriffsart	`global.api_scheme`	Ingress-TLS
HTTPS am Ingress	`https` (Standard)	Zertifikat-Secret
HTTPS am vorgeschalteten Proxy	`https`	Leer bei HTTP zwischen Proxy und Ingress
HTTP vom Browser zum Ingress	`http`	Leer

HTTPS am Ingress¶

Speichere dies als values.yaml. Ändere den Hostnamen einmal; YAML-Aliase verwenden ihn für Routing und TLS wieder. Setze Deine Administrator-E-Mail-Adresse und Ingress-Klasse.

global:
  api_host: &platform-host datamimic.int.customernet.com
  api_scheme: https
  password_secret: datamimic-application
  first_admin: [email protected]
backend:
  ingress:
    enabled: true
    class: nginx
    hosts:
      - host: *platform-host
        paths: ["/"]
    tls:
      - secretName: datamimic-tls
        hosts: [*platform-host]

Erstelle datamimic-tls im selben Namespace mit Deinem Zertifikat und privaten Schlüssel:

kubectl create secret tls datamimic-tls \
  --cert=<certificate-chain.pem> --key=<private-key.pem> -n <namespace>

Alternativ lässt Du Deinen konfigurierten Zertifikat-Controller dieses Secret ausstellen. Die Prefix-Route / umfasst UI, /api, WebSockets und OAuth-Ermittlung; eine separate /api-Route ist unnötig.

HTTP ohne TLS¶

Verwende stattdessen diese values.yaml:

global:
  api_host: &platform-host datamimic.int.customernet.com
  api_scheme: http
  password_secret: datamimic-application
  first_admin: [email protected]
backend:
  ingress:
    enabled: true
    class: nginx
    annotations:
      nginx.ingress.kubernetes.io/ssl-redirect: "false"
      nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
    hosts:
      - host: *platform-host
        paths: ["/"]
    tls: []

Diese Redirect-Annotationen gelten für ingress-nginx. Bei anderen Controllern deaktivierst Du die HTTP-zu-HTTPS-Umleitung über deren entsprechende Einstellungen.

HTTP überträgt Zugangsdaten und Session-Verkehr ohne Transportverschlüsselung. Verwende es nur in einem Netz, in dem das akzeptabel ist. Zwischenablage-Buttons können unter HTTP fehlen oder nicht funktionieren; markiere und kopiere den Text dann manuell, soweit angeboten. Auch Air-Gap-Installationen können HTTPS mit einer internen CA nutzen.

Browser-Anmeldung, Sessions und REST-API funktionieren über HTTP. MCP mit einem Projektzugriffstoken funktioniert nur mit Clients, die entfernte HTTP-Endpunkte erlauben. DATAMIMIC-IDE-Integrationen benötigen OAuth und damit HTTPS. Kiro lehnt entfernte HTTP-MCP-URLs außerhalb von Localhost unabhängig von der Authentifizierung ab.

HTTPS am vorgeschalteten Proxy¶

Verwende das HTTP-Beispiel, setze aber global.api_scheme: https. Behalte tls: [] nur bei, wenn der Proxy HTTP an den Ingress weiterleitet. Der Proxy stellt das Zertifikat und die öffentliche HTTPS-Umleitung bereit, erhält den öffentlichen Hostnamen und leitet das ursprüngliche Schema weiter. Konfiguriere das Vertrauen in Forwarding-Header wie in Schritt 8 beschrieben.

Verwendet der Proxy auch zum Ingress TLS, nutze die HTTPS-Ingress-Konfiguration mit einem Zertifikat, dem der Proxy vertraut.

api_host und api_scheme bestimmen die öffentliche URL, den CORS-Origin und die Links nach der Installation. Das Backend verwendet die öffentliche URL für die Origin-Prüfung bei der Anmeldung und das Secure-Flag des Session-Cookies. Liefere UI und API über denselben öffentlichen Origin aus, ohne URL-Pfad oder abschließenden Schrägstrich. api_scheme allein konfiguriert weder Zertifikate noch Umleitungen.

6. Chart installieren und aktualisieren¶

Verwende bei Installation und Upgrades dieselben gespeicherten Values und dasselbe Anwendungs-Secret. Ersetze bei einem Upgrade nur das Chart-Archiv oder die festgelegte Version.

Heruntergeladenes Archiv:

helm upgrade --install <release-name> <chart-archive>.tgz \
  -n <namespace> -f values.yaml --wait --timeout 10m

Harbor-OCI-Registry:

helm registry login harbor.rapiddweller.com --username <username>
helm upgrade --install <release-name> \
  oci://harbor.rapiddweller.com/datamimic/helm-datamimic \
  --version <chart-version> -n <namespace> -f values.yaml --wait --timeout 10m

Prüfe das genaue Chart vor dem Deployment mit Deinen Values:

helm show values <chart-archive>.tgz
helm template <release-name> <chart-archive>.tgz -n <namespace> -f values.yaml

Verwende bei OCI dieselbe Referenz und --version wie beim Installationsbefehl. Prüfe, ob die Backend-ConfigMap die gewünschte öffentliche URL und den CORS-Origin enthält und ein Ingress mit dem richtigen Hostnamen und TLS-Modus gerendert wird. Behandle die gerenderte Ausgabe vertraulich, da sie Secret-Ressourcen enthalten kann.

Nach dem Deployment:

kubectl get pods,ingress -n <namespace>

Die Pods müssen bereit sein. Prüfe bei ImagePullBackOff das Pull-Secret und den Registry-Zugriff, bei Pending Storage und Scheduling. Bei wiederholten Abstürzen prüfe Pod-Events und Anwendungslogs. Ein Helm-Timeout löst keinen automatischen Rollback aus; prüfe das Release vor einem erneuten Versuch.

Prüfe die folgenden Ingress-Einstellungen, bevor Du die Installation zugänglich machst. Teste anschließend Anmeldung und Abmeldung in Schritt 10.

7. Halte den Anwendungs-Ingress zustandslos¶

DATAMIMIC speichert gemeinsam genutzten Serverzustand in Redis. Deshalb muss jedes Backend-Replikat die nächste Browser-, WebSocket- oder MCP-Anfrage nach einer Neuverbindung annehmen können. Konfiguriere weder Ingress-Affinität noch Sticky-Session-Cookies.

Das Backend verwaltet sein hostgebundenes HttpOnly-Browser-Session-Cookie und lässt es über seinen Logout-Endpunkt ablaufen. Halte den Haupt-Ingress frei von:

Umschreibungen für Cookie-Domain oder -Pfad;
Lua- oder Konfigurations-Snippets, die Set-Cookie umschreiben;
proxy-hide-header oder Header-Filtern, die Set-Cookie unterdrücken;
Affinitäts- und Session-Cookie-Annotationen.

Diese Ingress-Funktionen schaffen eine zweite Stelle, die Cookies verändert, und machen das Logout-Verhalten vom ausgewählten Replikat abhängig.

Der Proxy muss jeden Upstream-Response-Header einzeln weitergeben, einschließlich mehrerer Set-Cookie-Header. ingress-nginx tut dies standardmäßig; fasse sie nicht zu einem kommagetrennten Header zusammen.

8. Vertraue Forwarding-Headern genau einmal¶

Wenn vor ingress-nginx ein weiterer L7-Proxy oder Load Balancer steht, konfiguriere das Vertrauen in Forwarding-Header genau einmal in der Controller ConfigMap von ingress-nginx:

data:
  use-forwarded-headers: "true"
  proxy-real-ip-cidr: "<trusted-proxy-cidr>[,<trusted-proxy-cidr>]"

Setze proxy-real-ip-cidr auf die tatsächlichen CIDRs der vertrauenswürdigen vorgeschalteten Proxys. Vertraue keinen beliebigen Client-Netzen. Füge keinen der beiden Werte als Annotation eines Anwendungs-Ingress hinzu.

9. Platform-Authentifizierungsendpunkte von externer Ingress-Authentifizierung ausnehmen¶

Wenn optionale externe Authentifizierung für andere Anwendungspfade aktiviert ist, halte diese Platform-eigenen Endpunktgruppen außerhalb der Verarbeitung durch auth-url und auth-signin:

/.well-known/*
/api/v2/session/*
/api/v2/oauth/*

Verwende getrennte Ingress-Ressourcen oder eine gleichwertige Controller-Routenführung, wenn Du pfadspezifische Regeln benötigst. Diese Endpunkte führen die DATAMIMIC-Session- oder OAuth-Authentifizierung selbst durch; eine externe Umleitung oder ein umgeschriebener Authentifizierungs-Header unterbricht Browser-Logout und OAuth-Ermittlung.

10. Anmeldung und Abmeldung über die öffentliche URL prüfen¶

Öffne zuerst die öffentliche URL im Browser: Die Anmeldeseite muss erscheinen, die Anmeldung gelingen und die Session nach dem Neuladen bestehen bleiben. Prüfe anschließend den serverseitigen Session-Ablauf mit einem temporären Cookie-Jar. Ersetze URL und Zugangsdaten; verwende http:// für HTTP-Installationen:

PLATFORM_URL="https://datamimic.int.customernet.com"
COOKIE_JAR="$(mktemp)"
trap 'rm -f "$COOKIE_JAR"' EXIT

curl --fail-with-body --silent --show-error \
  --cookie-jar "$COOKIE_JAR" \
  --header "Origin: $PLATFORM_URL" \
  --data-urlencode "username=<email>" \
  --data-urlencode "password=<password>" \
  "$PLATFORM_URL/api/v2/session/login"

curl --fail-with-body --silent --show-error \
  --cookie "$COOKIE_JAR" \
  "$PLATFORM_URL/api/v2/me"

curl --fail-with-body --silent --show-error \
  --request POST \
  --cookie "$COOKIE_JAR" \
  --cookie-jar "$COOKIE_JAR" \
  --header "Origin: $PLATFORM_URL" \
  "$PLATFORM_URL/api/v2/session/logout"

STATUS="$(curl --silent --output /dev/null --write-out '%{http_code}' \
  --cookie "$COOKIE_JAR" \
  "$PLATFORM_URL/api/v2/me")"
test "$STATUS" = "401"

Login und Logout liefern 204; der authentifizierte Aufruf von /api/v2/me ist vor dem Logout erfolgreich, und der letzte Aufruf muss 401 liefern. Prüfe bei HTTPS zusätzlich die OAuth-Ermittlung über eine Projekt-MCP-URL. Prüfe bei HTTP die Projekt-MCP-URL mit einem Projektzugriffstoken nur über einen Client, der entfernte HTTP-Endpunkte erlaubt; dies prüft keine IDE-Integration. Prüfe bei mehr als einem Backend-Replikat außerdem eine Neuverbindung ohne Affinität.

Falls die Anmeldung fehlschlägt, vergleiche den tatsächlichen Browser-Origin mit der gerenderten öffentlichen URL und prüfe auf unerwartete HTTPS-Umleitungen.