Caddy vor der Nginx-App über Docker Compose

Unterstützung Installation
,
1

Ich habe einen meiner Discourse-Forumsserver aktualisiert, um UDP 443 zu öffnen, anstatt nur TCP in der IONOS Cloud Panel-Firewall (ich komme aus Großbritannien).

Ich verwende kein CDN, weil dieses bestimmte Forum nicht viele Benutzer hat, aber viele Kategorien.

Ich hatte einige Schwierigkeiten, die IP-Geolokalisierung durch nginx korrekt einzurichten, und das Forum funktioniert jetzt einwandfrei, ohne Probleme in /logs.

Ich habe rotierende Proxy-Protokolle mit Docker Compose eingerichtet und schätze, dass Caddy einige automatische Maskierung sensibler Felder in den Proxy-Protokollen durchführt, was ich bei Nginx zuvor nicht bemerkt habe. Obwohl ich mich nur daran erinnere, Proxy-Protokolle zweimal in den 2 Jahren verwendet zu haben, in denen ich Discourse im Produktivbetrieb eingesetzt habe.

Ich hoffe, zu erfahren, wie viel Interesse es gäbe, wenn ich einen Leitfaden veröffentlichen würde, der durchläuft, welche Befehle ich ausgeführt habe und was passiert ist, als ich sie ausgeführt habe, um vom Anfänger-Docker-Installationsleitfaden zum jetzt etwas mobilfreundlicheren Forum zu gelangen – ich kann Befehle für zukünftige Wartungsaufgaben einbeziehen, z. B. das Upgrade von Caddy auf eine neuere Version, aber ich habe diese Befehle noch nicht auf meinem IONOS L VPS getestet.

2

FWIW, es gibt diesen PR: Add Caddy web server template as nginx alternative - Pull Request #952 - discourse/discourse_docker - GitHub

3

Danke, ich hatte diesen PR nicht gesehen. Das ist interessant – mein Setup ist etwas anders, da ich Discourses nginx-Webserver beibehalten und Caddy separat in Docker Compose davor laufen lasse, hauptsächlich um HTTP/3 am Edge bereitzustellen.

Es gibt eine kleine Änderung auf Discourse-Seite: Ich habe einen persistenten app.yml-Hook hinzugefügt, sodass nginx den X-Forwarded-For-Wert von Caddy für die echte Client-IP verwendet, wenn Anfragen über den Unix-Socket eintreffen. Ursprünglich brauchte ich einen Caddy-X-Real-IP-Workaround, aber nachdem ich die nginx-seitige Korrektur hinzugefügt hatte, konnte ich diesen entfernen und überprüfen, dass Discourse weiterhin die korrekte Client-IP aufzeichnet.

Ich habe auch QUIC 0-RTT/Early Data in der Caddy-Konfiguration explizit deaktiviert, während HTTP/3 aktiviert bleibt, um diesen zusätzlichen Early-Data-Edge-Case zu vermeiden.

Mein Ansatz ermöglicht auch Caddys HTTP-Access-Logging auf Site-Ebene, was mir Caddys Standard-Redaktion sensibler Credential-Header bietet. Ich rotiere die daraus resultierenden Docker-json-file-Logs bei 25 MB × 3. Ich habe bemerkt, dass der PR aktuell seinen rotierenden Log-Block in Caddys globalen Optionen hat, was in Caddys Dokumentation als Konfiguration des Runtime-Loggings und nicht des HTTP-Access-Loggings beschrieben wird.

Es ist also nicht ganz eine komplett unberührte Standardinstallation, aber es ist auch ein anderer Ansatz als den Austausch von nginx durch Caddy insgesamt.

Ich werde mir diesen PR genauer ansehen. Für jetzt bin ich hauptsächlich daran interessiert, ob genug Interesse an diesem Ansatz besteht, um eine Schritt-für-Schritt-Anleitung sinnvoll zu machen, anstatt sofort damit zu beginnen.

4

Nur eine Korrektur/Präzisierung zu dem, was ich oben gesagt habe.

Als ich das Ergebnis ursprünglich als ein

mobilfreundlicheres Forum beschrieb, war Teil dessen, was ich bemerkt hatte, dass die initiale Roundtrip-Zeit beim Öffnen der iOS-Safari-PWA zuvor zu langsam wirkte.

Allerdings bereue ich es nun, diese Aussage in meine spätere Antwort aufgenommen zu haben:

Das Deaktivieren von 0-RTT war etwas, das ich beim Diagnostizieren des Client-IP-Problems ausprobiert habe, aber es scheint nicht notwendig gewesen zu sein. Beide PostgreSQL-Fehler im Zusammenhang mit unix: traten weiterhin auf, während 0rtt off bereits konfiguriert war.

Die Änderung, die diese Fehler anscheinend behoben hat, war stattdessen der persistente app.yml-Hook, der nginx so modifiziert, dass er Caddys X-Forwarded-For-Wert für die echte Client-IP verwendet, wenn Anfragen über den Unix-Socket eintreffen.

Ich habe daher nun die Einstellung 0rtt off entfernt und Caddys Standardverhalten wiederhergestellt. HTTP/3 funktioniert weiterhin und die korrekte Client-IP wird weiterhin an Discourse weitergeleitet.

Wenn also irgendwann genug Interesse besteht, um eine Schritt-für-Schritt-Anleitung zusammenzustellen, würde ich das Deaktivieren von QUIC 0-RTT nicht als erforderlichen Teil der Konfiguration aufnehmen.

5

Das kannst du auch mit Vanilla Nginx machen: https://quic.nginx.org/

6

Danke – ich habe mir den in meinem Discourse-app-Container aktuell ausgelieferten nginx angesehen, und du hast recht, dass er HTTP/3 direkt bereitstellen kann:

nginx 1.26.3-3+deb13u7
OpenSSL 3.5.6
--with-http_v3_module

Direktes HTTP/3 über den bestehenden nginx von Discourse ist also definitiv eine echte Alternative.

Ein Grund, warum ich für dieses bestimmte Setup dennoch Caddy bevorzugen könnte, ist 0-RTT. Nach meiner Korrektur oben habe ich das standardmäßige QUIC-0-RTT-Verhalten von Caddy wieder aktiviert, und bei der iOS-Safari-PWA habe ich eine deutliche Verbesserung des Ladeerlebnisses festgestellt, das ich zu optimieren versuchte.

Soweit ich die nginx-Dokumentation richtig verstehe, können nginx-Versionen vor 1.29.1 0-RTT nicht aktivieren, wenn sie mit OpenSSL kompiliert wurden, unabhängig von ssl_early_data. Daher kann der nginx 1.26.3, der sich aktuell in meinem Discourse-Container befindet, zwar HTTP/3, aber nicht diese spezielle Optimierung durchführen.

Daher bin ich daran interessiert, die beiden Ansätze zu vergleichen, anstatt einfach anzunehmen, dass Caddy allein wegen HTTP/3 notwendig ist.