Quelqu’un a-t-il réussi à configurer Discourse sur un vhost Apache, au lieu du serveur nginx par défaut ?
Il semble que la plupart des discussions autour d’Apache sur ces forums concernent l’exécution de Discourse sur un hôte qui exécute déjà Apache. Dans tous les cas que j’ai vus, les gens se contentent de faire passer Apache par un proxy vers nginx. Pour être clair : je veux que le conteneur backend Docker exécutant Discourse gère le serveur virtuel dans Apache, et non dans Nginx.
Plus précisément, j’espère exécuter le backend de Discourse dans Apache au lieu de Nginx afin d’activer mod_security. Configurer Nginx avec mod_security nécessite de compiler Nginx à partir du code source, une complexité que je souhaiterais éviter.
Mon serveur de production actuel exécute déjà plusieurs sites (WordPress, MediaWiki, etc.). Nous utilisons Nginx pour terminer le HTTPS et effectuer une limitation de débit DOS basique → cache Varnish → backend Apache avec mod_security. Si possible, je voudrais conserver cette architecture pour Discourse, avec le conteneur Docker backend de Discourse exécutant Apache avec mod_security, et non Nginx.
Quelqu’un a-t-il réussi à configurer Discourse pour qu’il s’exécute dans Apache ?
Désolé, je débute avec Docker. J’ai beaucoup de mal à comprendre comment le fichier ‘/etc/nginx/conf.d/discourse.conf’ est même placé dans le conteneur Docker. Quelqu’un pourrait-il expliquer les étapes de génération de ce fichier et de son placement dans le conteneur par le script ‘./launcher’ ?
EDIT : Attendez, Nginx est-il déjà compilé à partir du code source par Discourse ?
Non, personne n’y est parvenu. Discourse est étroitement lié à nginx. Il sera difficile, voire impossible, de le remplacer par Apache. Et comme vous serez la seule personne à le faire, personne ne se souciera du problème si cela plante.
Utilisez simplement le conteneur Docker que tout le monde sur la planète utilise et placez Apache devant si vous pensez que cela améliorera la sécurité d’une manière ou d’une autre.
Il semble donc que /etc/nginx/conf.d/discourse.conf soit généré dans le conteneur à partir du fichier modèle /var/docker/templates/web.template.yml — qui le copie en place depuis $home/config/nginx.sample.conf, puis effectue des modifications grâce aux blocs YAML replace (qui sont ensuite mis à jour dans d’autres modèles, tels que templates/web.socketed.template.yml).
Je supposais que le fichier nginx.sample.conf était simplement installé en place par nginx lors de la compilation à partir du code source dans image/base/install-nginx, mais le seul fichier nginx.sample.conf que j’ai trouvé dans le conteneur (/var/www/discourse/config/nginx.sample.conf) contenait déjà des directives spécifiques à Discourse.
Je préférerais éviter la chaîne nginx → varnish → apache → nginx
Pour être clair : pensez-vous qu’il serait plus sûr pour moi de mettre à jour le script ‘image/base/install-nginx’ afin de compiler nginx dans le conteneur Docker de Discourse avec le support de mod_security, plutôt que de mettre à jour le conteneur pour exécuter le vhost de Discourse derrière Apache (plutôt que Nginx) ? Si oui, quels sont les risques liés à la modification du script install-nginx ? Comment cela pourrait-il casser mon installation Discourse à l’avenir ?
PSA : Tout ce que vous proposez de faire, bien que techniquement faisable, n’est absolument pas pris en charge. Nous ne pouvons pas raisonnablement supporter toutes les combinaisons possibles que les gens imaginent pour héberger Discourse sur le web. Ainsi, le support sur ce forum est limité aux installations suivant le guide discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub.
Cela finira par inévitablement casser de multiples façons. Vous devrez continuellement fusionner les changements en amont et gérer votre fork indéfiniment.
@ledimeo C’est ce que @pfaffman a suggéré, et ce que je pense être préférable dans ce cas, pour éviter de casser les choses gravement à l’avenir lors de la sortie de nouvelles versions. Mais il semble qu’il utilise déjà un autre nginx en façade comme proxy inverse et ne souhaite pas :
Cela dit, je pense que faire passer apache par nginx (même si cela se traduit par ces quatre couches) serait au moins plus facile à maintenir que d’essayer de modifier le fonctionnement de Discourse dans l’installation officielle.
Donc, ajouter Apache comme proxy devant le nginx de Discourse est définitivement une option.
Je suis d’accord pour dire que pour un professionnel, cela faciliterait les mises à jour futures, et c’est un point important.
Cependant, ajouter une étape supplémentaire à l’architecture ne ferait pas seulement compliquer le débogage des problèmes à l’avenir — j’ai aussi des inquiétudes concernant les performances d’Apache en tant que proxy pour une application web utilisant le long polling, comme l’a souligné @sam dans ce post de 2016.
Je préfère généralement nginx à Apache, sauf en ce qui concerne mod_security. Ce serait formidable si les dépôts du système d’exploitation incluaient des paquets permettant d’activer mod_security dans nginx, comme c’est le cas pour Apache, mais actuellement, activer mod_security sur nginx nécessite de compiler nginx à partir du code source, tant sur RHEL/Cent que sur Debian. Et j’évite de dépendre de paquets compilés à partir du code source en production comme la peste.
En lien : J’ai exploré le script install-nginx et j’ai détecté une erreur logique mineure : la ligne de nettoyage censée supprimer les sources d’nginx de /tmp/ ne fait en réalité rien.
Il n’existe pas de répertoire /tmp/nginx/ : c’est /tmp/nginx-$VERSION/ (pour le moment, c’est /tmp/nginx-1.17.4/ et il y a aussi l’archive /tmp/nginx-1.17.4.tar.gz).
Malheureusement, mon script mis à jour /var/discourse/image/base/install-nginx ne semble pas être exécuté lorsque j’exécute /var/discourse/launcher destroy app && /var/discourse/launcher/rebuild app.
Y a-t-il une raison pour laquelle cette commande rebuild ne réexécuterait pas le script install-nginx mis à jour ?
Après une reconstruction, pouvez-vous toujours voir vos modifications ? Modifier directement les fichiers dans l’image de cette façon ne fonctionnera pas.
Vous devez utiliser des hooks pour modifier le fichier depuis votre app.yml
Si vous n’êtes pas familier avec Docker, ce chemin sera difficile…
discourse_docker contient le code source de notre image Docker de base qui réside dans le registre Docker public et qui ne sera jamais exécutée localement. La raison principale est de disposer d’une image réutilisable.
ok. Bon, j’ai menti au sujet de vim pour simplifier. En réalité, j’exécute ces commandes pour mettre à jour le script de manière idempotente et robuste.
cd /var/discourse/image/base
cp install-nginx install-nginx.`date "+%Y%m%d_%H%M%S"`.orig
# ajouter un bloc pour récupérer le module nginx ModSecurity juste avant de télécharger le code source de nginx
grep 'ModSecurity' install-nginx || sed -i 's%\(curl.*nginx\.org/download.*\)%# mod_security --maltfield\napt-get install -y libmodsecurity-dev modsecurity-crs\ncd /tmp\ngit clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git\n\n\1%' install-nginx
# mettre à jour la ligne de configuration pour inclure le module ModSecurity récupéré ci-dessus
sed -i '/ModSecurity/! s%^[^#]*./configure \(.*nginx.*\)%#./configure \1\n./configure \1 --add-module=/tmp/ModSecurity-nginx%' install-nginx
# ajouter une ligne dans la section de nettoyage
grep 'rm -fr /tmp/ModSecurity-nginx' install-nginx || sed -i 's%\(rm -fr.*/tmp/nginx.*\)%rm -fr /tmp/ModSecurity-nginx\n\1%' install-nginx
Où dois-je placer ces commandes afin que le script install-nginx réellement utilisé par le conteneur lors du démarrage soit modifié ?
