Ho aggiornato uno dei miei server forum Discourse, quindi ho aperto la porta UDP 443 anziché solo TCP nel firewall del Cloud Panel di IONOS (sono del Regno Unito).
Non utilizzo un CDN perché questo forum in particolare non ha molti utenti, ma ha molte categorie.
Ho avuto qualche difficoltà a garantire che la geolocalizzazione degli IP tramite nginx funzionasse correttamente, e ora il forum funziona bene senza problemi nei /logs.
Ho configurato i log del proxy in rotazione con Docker Compose e apprezzo il fatto che Caddy esegua una censura automatica dei campi sensibili nei log del proxy, qualcosa che non avevo notato prima con Nginx. Anche se ricordo di aver usato i log del proxy solo due volte nei 2 anni in cui ho usato Discourse in produzione.
Spero di capire quanto interesse ci sarebbe se pubblicassi una guida che spiegasse quali comandi ho eseguito e cosa è successo quando li ho eseguiti, per passare dalla Guida all’installazione Docker per principianti al forum ora leggermente più adatto ai dispositivi mobili: posso includere i comandi per la manutenzione futura, ad esempio l’aggiornamento di Caddy a una versione più recente, ma non ho ancora testato questi comandi sul mio VPS IONOS L.
Grazie, non avevo visto quella PR. È interessante: la mia configurazione è leggermente diversa, poiché ho mantenuto il server web nginx di Discourse in posizione ed eseguo Caddy separatamente in Docker Compose davanti ad esso, principalmente per fornire HTTP/3 al bordo della rete.
C’è una piccola modifica lato Discourse: ho aggiunto un hook persistente in app.yml in modo che nginx utilizzi il valore di X-Forwarded-For di Caddy per l’IP reale del cliente quando le richieste arrivano tramite la socket Unix. Inizialmente avevo bisogno di una soluzione alternativa con X-Real-IP in Caddy, ma dopo aver aggiunto la correzione lato nginx sono riuscito a rimuoverla e a verificare che Discourse registri ancora l’IP corretto del cliente.
Ho anche disabilitato esplicitamente QUIC 0-RTT/early data nella configurazione di Caddy, lasciando abilitato HTTP/3, per evitare quel caso particolare legato ai early data.
Il mio approccio abilita anche la registrazione degli accessi HTTP di Caddy a livello di sito, il che mi fornisce la censura predefinita di Caddy per le intestazioni delle credenziali sensibili. Ruoto i log json-file risultanti di Docker a 25 MB × 3. Ho notato che la PR attuale ha il blocco di rotazione dei log nelle opzioni globali di Caddy, che la documentazione di Caddy descrive come configurazione della registrazione runtime piuttosto che della registrazione degli accessi HTTP.
Quindi non è esattamente un’installazione standard completamente intatta, ma è anche un approccio diverso rispetto alla sostituzione completa di nginx con Caddy.
Daremo un’occhiata più attenta a quella PR. Per ora sono principalmente interessato a sapere se c’è abbastanza interesse per questo approccio da rendere utile una guida passo passo, piuttosto che iniziare subito a scriverne una.
Solo una correzione/precisazione a quanto detto sopra.
Quando ho descritto inizialmente il risultato come un:
forum più adatto ai dispositivi mobili, una delle cose che avevo notato era che il primo round trip all’apertura della PWA su Safari iOS sembrava troppo lento.
Tuttavia, ora rimpiango di aver incluso questa affermazione nella mia risposta successiva:
La disabilitazione di 0-RTT era qualcosa che avevo provato mentre diagnosticavo il problema dell’IP del client, ma non sembra essere stata necessaria. Entrambi gli errori di PostgreSQL relativi a unix: sono continuati anche quando 0rtt off era già configurato.
Il cambiamento che sembra aver risolto quegli errori è stato invece l’hook persistente in app.yml, che modifica nginx in modo che utilizzi il valore X-Forwarded-For di Caddy per l’IP reale del client quando le richieste arrivano tramite il socket Unix.
Ho quindi rimosso l’impostazione 0rtt off e ripristinato il comportamento predefinito di Caddy. HTTP/3 funziona ancora e l’IP corretto del client continua a essere passato a Discourse.
Quindi, se ci sarà abbastanza interesse da parte mia per preparare una guida passo passo, non includerei la disabilitazione di QUIC 0-RTT come parte obbligatoria della configurazione.
Quindi l’HTTP/3 diretto dall’nginx esistente di Discourse è sicuramente un’alternativa valida.
Un motivo per cui potrei comunque preferire Caddy per questa configurazione specifica è 0-RTT. Dopo la correzione sopra indicata, ho riabilitato il comportamento predefinito di Caddy per QUIC 0-RTT, e sulla PWA di Safari per iOS ho notato un miglioramento significativo nell’esperienza di caricamento che stavo cercando di ottimizzare.
Per quanto ne sappia dalla documentazione di nginx, le versioni precedenti alla 1.29.1 non possono abilitare 0-RTT quando compilate con OpenSSL, indipendentemente da ssl_early_data, quindi l’nginx 1.26.3 attualmente presente nel mio container Discourse può gestire HTTP/3 ma non questa specifica ottimizzazione.
Quindi sono interessato a confrontare i due approcci, piuttosto che dare per scontato che Caddy sia necessario solo per HTTP/3.