J’ai mis à jour l’un de mes serveurs de forum Discourse, afin d’ouvrir le port UDP 443 au lieu du seul TCP dans le pare-feu du Cloud Panel IONOS (je suis basé au Royaume-Uni).
Je n’utilise pas de CDN car ce forum en particulier n’a pas un grand nombre d’utilisateurs, mais il contient beaucoup de catégories.
J’ai eu quelques difficultés à configurer correctement la géolocalisation des IP via nginx, et le forum fonctionne désormais sans aucun problème dans /logs.
J’ai mis en place une rotation des journaux de proxy avec Docker Compose, et j’apprécie le fait que Caddy effectue un masquage automatique des champs sensibles dans les journaux de proxy, quelque chose que je n’avais pas vraiment remarqué avec Nginx auparavant. Bien que je me souvienne seulement avoir utilisé les journaux de proxy deux fois au cours des deux années où j’ai utilisé Discourse en production.
J’aimerais savoir s’il y aurait de l’intérêt si je publiais un guide détaillant les commandes que j’ai exécutées et ce qui s’est passé à chaque étape, pour passer du guide d’installation Docker pour débutants au forum actuel, légèrement plus adapté aux mobiles. Je peux inclure des commandes pour la maintenance future, par exemple la mise à niveau de Caddy vers une version plus récente, mais je n’ai pas encore testé ces commandes sur mon VPS IONOS L.
Merci, je n’avais pas vu cette PR. C’est intéressant – ma configuration est légèrement différente car j’ai conservé le serveur web nginx de Discourse et fait fonctionner Caddy séparément dans Docker Compose devant, principalement pour fournir HTTP/3 au niveau du périmètre.
Il y a un petit changement côté Discourse : j’ai ajouté un hook persistant dans app.yml afin que nginx utilise la valeur X-Forwarded-For de Caddy pour l’adresse IP réelle du client lorsque les requêtes arrivent via le socket Unix. J’avais initialement besoin d’une solution de contournement avec X-Real-IP dans Caddy, mais après avoir ajouté la correction côté nginx, j’ai pu la supprimer et vérifier que Discourse enregistrait toujours la bonne adresse IP du client.
J’ai également explicitement désactivé QUIC 0-RTT/les données anticipées dans la configuration de Caddy tout en laissant HTTP/3 activé, afin d’éviter ce cas limite supplémentaire lié aux données anticipées.
Mon approche permet également d’activer la journalisation des accès HTTP de Caddy au niveau du site, ce qui me donne la suppression automatique par défaut des en-têtes de credentials sensibles par Caddy. Je fais la rotation des journaux Docker json-file résultants à 25 Mo × 3. J’ai remarqué que la PR actuelle place son bloc de rotation des journaux dans les options globales de Caddy, ce que la documentation de Caddy décrit comme la configuration de la journalisation en temps d’exécution plutôt que celle des accès HTTP.
Ce n’est donc pas tout à fait une installation standard inchangée, mais c’est aussi une approche différente de celle qui consiste à remplacer nginx par Caddy entièrement.
Je jeterai un coup d’œil plus attentif à cette PR. Pour l’instant, je suis principalement intéressé par savoir s’il y a suffisamment d’intérêt pour cette approche pour qu’un guide étape par étape en vaille la peine, plutôt que de commencer à en écrire un immédiatement.
Juste une correction/précision concernant ce que j’ai dit plus haut.
Lorsque j’ai initialement décrit le résultat comme un :
forum plus adapté aux mobiles, une des choses que j’avais remarquées était que l’aller-retour initial lors de l’ouverture de la PWA sur Safari iOS semblait auparavant trop lent.
Cependant, je regrette maintenant d’avoir inclus cette affirmation dans ma réponse ultérieure :
La désactivation de 0-RTT était quelque chose que j’avais essayé pendant le diagnostic du problème d’IP client, mais cela ne semble pas avoir été nécessaire. Les deux erreurs PostgreSQL impliquant unix: ont persisté alors que 0rtt off était déjà configuré.
Le changement qui semble avoir résolu ces erreurs était plutôt le hook persistant dans app.yml qui modifie nginx afin qu’il utilise la valeur X-Forwarded-For de Caddy pour l’IP client réelle lorsque les requêtes arrivent via le socket Unix.
J’ai donc maintenant supprimé le paramètre 0rtt off et restauré le comportement par défaut de Caddy. HTTP/3 fonctionne toujours et l’IP client correcte continue d’être transmise à Discourse.
Ainsi, s’il y a suffisamment d’intérêt pour que je prépare un guide étape par étape, je n’inclurai pas la désactivation de QUIC 0-RTT comme partie obligatoire de la configuration.
Merci – j’ai vérifié la version d’nginx actuellement incluse dans mon conteneur Discourse app, et vous avez raison : elle peut fournir directement HTTP/3 :
Ainsi, le HTTP/3 direct via le nginx existant de Discourse constitue bien une alternative sérieuse.
Une raison pour laquelle je pourrais tout de même préférer Caddy dans cette configuration particulière est le 0-RTT. Après la correction mentionnée ci-dessus, j’ai réactivé le comportement QUIC 0-RTT par défaut de Caddy, et j’ai constaté une amélioration significative de l’expérience de chargement sur Safari iOS (PWA), que je cherchais à optimiser.
D’après ce que je comprends de la documentation d’nginx, les versions antérieures à 1.29.1 ne peuvent pas activer le 0-RTT lorsqu’elles sont compilées avec OpenSSL, indépendamment de la directive ssl_early_data. Par conséquent, la version nginx 1.26.3 actuellement présente dans mon conteneur Discourse prend en charge HTTP/3, mais pas cette optimification spécifique.
Je suis donc intéressé par une comparaison des deux approches, plutôt que de supposer que Caddy est indispensable uniquement pour HTTP/3.