Nick Szaunig
e8f0bd4f55
Docker Image bauen und veroeffentlichen / build-and-push (push) Successful in 2m6s
Der Zielcluster nutzt Traefik, nicht ingress-nginx. Saemtliche Annotationen der Form nginx.ingress.kubernetes.io/* ignoriert Traefik ersatzlos und still: sie erzeugen keinen Fehler, wirken aber auch nicht. Das betraf das Upload-Limit (proxy-body-size) ebenso wie die Zeitlimits, und ingressClassName zeigte auf "nginx". Damit aendert sich auch die Diagnose des fehlgeschlagenen Video-Uploads. Belegt aus Traefiks Quelltext (pkg/config/static/static_config.go, SetDefaults) und der Referenzdokumentation: - readTimeout des EntryPoints: Default 60s, beschrieben als "maximum duration for reading the entire request, including the body". Er umfasst also die gesamte Uebertragung des Uploads. Bei 20-100 MB ueber eine normale Upload-Leitung ist das schnell ueberschritten — 80 MB bei 10 Mbit/s sind rund 64 Sekunden. Laeuft er ab, kappt Traefik die Verbindung und antwortet mit einer eigenen HTML-Fehlerseite. Das ist die wahrscheinlichste Quelle des "Unexpected token '<'" im Browser. - responseHeaderTimeout: von SetDefaults NICHT gesetzt, bleibt 0, und "If zero, no timeout exists". Die Dauer des ffmpeg-Transcodings ist bei Traefik also NICHT begrenzt — anders als zuvor angenommen. - Body-Groesse: Traefik erzwingt keine Obergrenze (begrenzt ist nur maxHeaderBytes mit 1 MB fuer die Header). Ein Gegenstueck zu nginx' proxy-body-size wird nicht gebraucht. readTimeout gehoert zur statischen EntryPoint-Konfiguration und laesst sich nicht per Ingress-Annotation setzen. Das Manifest dokumentiert deshalb ausfuehrlich, welche Einstellung in der Traefik-Installation noetig ist (Helm: ports.websecure.transport.respondingTimeouts.readTimeout: 600s). Weiter angepasst: ingressClassName auf "traefik", HTTPS-Umleitung ueber eine Traefik-Middleware statt der nginx-Annotation, und der Hinweis zu X-Forwarded-For nennt jetzt Traefiks forwardedHeaders.trustedIPs — davon haengt ab, ob lib/rate-limit.ts dem Header trauen darf. Die Kommentare in lib/uploads.ts und lib/csrf.ts verwiesen auf die entfernten nginx-Einstellungen und sind entsprechend berichtigt.
109 lines
4.9 KiB
YAML
109 lines
4.9 KiB
YAML
# Ingress fuer Traefik (der im Zielcluster eingesetzte Ingress-Controller),
|
|
# optional zusammen mit cert-manager fuer automatisches TLS. Host unten
|
|
# anpassen (muss zu NEXT_PUBLIC_SITE_URL in 01-configmap.yaml passen).
|
|
#
|
|
# ============================================================================
|
|
# WICHTIG fuer die Admin-Uploads: eine Einstellung fehlt hier zwangslaeufig
|
|
# ============================================================================
|
|
# Der Video-Upload (bis 100 MB, MAX_UPLOAD_VIDEO_BYTES in lib/uploads.ts)
|
|
# scheitert mit Traefiks Standardeinstellung, sobald die Uebertragung laenger
|
|
# als 60 Sekunden dauert. Das ist bei 20-100 MB ueber eine normale
|
|
# Upload-Leitung schnell erreicht: 80 MB bei 10 Mbit/s sind rund 64 Sekunden.
|
|
#
|
|
# Verantwortlich ist "readTimeout" des EntryPoints. Traefik beschreibt ihn als
|
|
# "maximum duration for reading the entire request, including the body" — er
|
|
# umfasst also die gesamte Uebertragung des Uploads, nicht nur die Header.
|
|
# Der Standardwert ist 60s. Laeuft er ab, kappt Traefik die Verbindung und
|
|
# antwortet mit einer eigenen HTML-Fehlerseite; im Browser erschien davon nur
|
|
# "Unexpected token '<', "<!DOCTYPE "... is not valid JSON", weil die Antwort
|
|
# kein JSON mehr war (lib/upload-client.ts meldet diesen Fall inzwischen mit
|
|
# dem HTTP-Status statt als Parse-Fehler).
|
|
#
|
|
# Dieser Wert laesst sich NICHT per Ingress-Annotation setzen — er gehoert zur
|
|
# statischen Konfiguration des EntryPoints und damit in die Traefik-
|
|
# Installation selbst. Mit dem offiziellen Helm-Chart:
|
|
#
|
|
# ports:
|
|
# websecure:
|
|
# transport:
|
|
# respondingTimeouts:
|
|
# readTimeout: 600s
|
|
#
|
|
# 600s deckt auch eine langsame Leitung ab. Ein hoher Wert ist hier
|
|
# unbedenklich, weil er nur greift, solange tatsaechlich Daten fliessen.
|
|
#
|
|
# Zwei Dinge, die bei Traefik ausdruecklich KEIN Problem sind:
|
|
#
|
|
# - Body-Groesse: Traefik erzwingt keine Obergrenze fuer den Request-Body
|
|
# (begrenzt ist nur maxHeaderBytes mit 1 MB, und das betrifft die Header).
|
|
# Eine Entsprechung zu nginx' "proxy-body-size" wird hier also nicht
|
|
# gebraucht. Nur falls eine "buffering"-Middleware im Einsatz ist, deren
|
|
# maxRequestBodyBytes pruefen.
|
|
# - Verarbeitungsdauer: "responseHeaderTimeout" (die Wartezeit auf die Antwort
|
|
# des Backends, also das ffmpeg-Transcoding) ist per Default 0 = kein Limit.
|
|
# Das Umrechnen darf demnach so lange dauern wie noetig; die Anwendung
|
|
# begrenzt es selbst auf 5 Minuten (TRANSCODE_TIMEOUT_MS in
|
|
# lib/video-transcode.ts).
|
|
#
|
|
# Sitzt zusaetzlich ein CDN davor (z.B. Cloudflare), gilt dessen eigenes
|
|
# Origin-Zeitlimit unabhaengig hiervon weiter — bei Cloudflare 100 Sekunden
|
|
# (Fehler 524), ebenfalls als HTML-Seite.
|
|
#
|
|
# ----------------------------------------------------------------------------
|
|
# X-Forwarded-For: lib/rate-limit.ts vertraut darauf, dass der Proxy diesen
|
|
# Header selbst setzt und einen vom Client mitgeschickten Wert verwirft —
|
|
# sonst liessen sich saemtliche Rate-Limits (Login, 2FA, Checkout) umgehen.
|
|
# Bei Traefik haengt das an "forwardedHeaders.trustedIPs" des EntryPoints:
|
|
# nur fuer dort aufgefuehrte Absender werden eingehende X-Forwarded-*-Header
|
|
# uebernommen, von allen anderen werden sie ersetzt. Vor dem Produktivbetrieb
|
|
# pruefen, dass diese Liste nicht unbeabsichtigt weit gefasst ist.
|
|
apiVersion: networking.k8s.io/v1
|
|
kind: Ingress
|
|
metadata:
|
|
name: wabenhain
|
|
namespace: wabenhain
|
|
annotations:
|
|
# Nur relevant, falls cert-manager installiert ist — sonst diese Zeile
|
|
# und den "tls:"-Block unten entfernen und den Host per HTTP betreiben
|
|
# oder TLS auf andere Weise terminieren.
|
|
cert-manager.io/cluster-issuer: letsencrypt-prod
|
|
# Erzwingt HTTPS ueber die Middleware unten. Legt die Traefik-Installation
|
|
# die Umleitung bereits EntryPoint-weit an (Helm-Chart:
|
|
# ports.web.redirectTo.port=websecure), sind diese Zeile UND die
|
|
# Middleware am Ende der Datei ueberfluessig. Der Namespace-Praefix im
|
|
# Wert ist Pflicht — Traefik loest den Namen sonst nicht auf.
|
|
traefik.ingress.kubernetes.io/router.middlewares: wabenhain-redirect-to-https@kubernetescrd
|
|
spec:
|
|
# Muss zur IngressClass der Traefik-Installation passen. Das offizielle
|
|
# Helm-Chart legt sie als "traefik" an; mit "kubectl get ingressclass"
|
|
# pruefen, falls der Ingress ohne Wirkung bleibt.
|
|
ingressClassName: traefik
|
|
tls:
|
|
- hosts:
|
|
- shop.example.com
|
|
secretName: wabenhain-tls
|
|
rules:
|
|
- host: shop.example.com
|
|
http:
|
|
paths:
|
|
- path: /
|
|
pathType: Prefix
|
|
backend:
|
|
service:
|
|
name: wabenhain-app
|
|
port:
|
|
number: 80
|
|
---
|
|
# Leitet HTTP dauerhaft auf HTTPS um; wird von der Annotation oben
|
|
# referenziert. Entfaellt samt Annotation, wenn die Umleitung bereits
|
|
# EntryPoint-weit konfiguriert ist.
|
|
apiVersion: traefik.io/v1alpha1
|
|
kind: Middleware
|
|
metadata:
|
|
name: redirect-to-https
|
|
namespace: wabenhain
|
|
spec:
|
|
redirectScheme:
|
|
scheme: https
|
|
permanent: true
|