Le conteneur sur l’hôte ne lance jamais install-nginx comme indiqué ci-dessus.
Je ne suis pas sûr que ce sujet soit particulièrement utile.
Vous n’aimez pas l’architecture de Discourse, vous refusez d’accepter les explications des développeurs concernant les optimisations du produit, vous ne semblez pas familier avec Docker et, selon vos propres aveux, vous mentez dans vos questions, ce qui gaspille notre temps à tous.
Ce sujet porte déjà le tag unsupported-install car vous vous éloignez considérablement du périmètre du support gratuit offert à la communauté. Si ces questions vous tiennent vraiment à cœur, pourquoi ne pas créer un nouveau sujet dans Marketplace ? Ainsi, vous pourrez investir votre propre argent pour payer un consultant qui vous formera, plutôt que de gaspiller notre temps.
Je n’ai jamais fait, désolé. Donc, je dois placer les commandes sed ci-dessus dans la section hooks de app.yml ? Existe-t-il un exemple quelque part montrant comment procéder pour modifier un fichier dans le dépôt discourse_docker au moment du bootstrap ? Actuellement, cette section ne contient qu’une commande git clone pour les plugins.
Je pourrais probablement insérer ces commandes sed dans une section cmd comme c’est le cas pour git clone, mais je ne sais pas dans quel répertoire se trouvera le script install-nginx.
De plus, où se trouve app.yml ? Je n’ai pas pu faire de lien vers la section hooks ci-dessus car le répertoire containers est vide dans le dépôt 
Toute la documentation pour faire ces choses existe ici sur Meta. Nous aimons tous éviter de lire le manuel, mais dans ce cas, vous devriez vraiment revenir aux bases.
Franchement, vous abordez tout cela à l’envers.
Je vais renvoyer vers le tag unsupported-install : l’attente est que si vous décidez de vous écarter de l’installation standard, vous assumiez vous-même la charge technique supplémentaire.
Comment avez-vous installé l’instance ?
Désolé, mais je fais l’effort de rechercher de la documentation avant de poster. J’adorerais avoir un manuel Discourse, et j’ai déjà lu de nombreux sujets tagués #howo. Malheureusement, il ne semble pas exister de manuel Discourse.
Je vous remercie pour votre aide, et je suis sûr que cela aidera aussi les autres à l’avenir qui recherchent de la documentation sur la façon de réaliser ces actions…
D’abord discourse-setup, ce qui m’a finalement donné une installation cassée. Ensuite, j’ai édité manuellement app.yml suivi de ./launcher rebuild app
Je trouve que c’est une discussion intéressante, juste pour mieux connaître Discourse.
Je choisirais nginx, en modifiant peut-être suffisamment le fichier app.yml pour ajouter le module mod_security lors du processus de compilation, et en construisant mon propre image de base.
Maintenant, Discourse est un logiciel complexe qui fonctionne sur Rails, lui-même encore plus complexe à déployer facilement et de manière cohérente. C’est pourquoi l’équipe a fait un effort supplémentaire dans l’image Docker qu’elle produit.
Cette image contient beaucoup de « magie noire », avec des tonnes et des tonnes d’optimisations pour fonctionner aussi bien que possible dans l’installation prise en charge.
En sachant cela, et en étant capable de comprendre toutes les pièces du puzzle (comme les 2-3 dépôts nécessaires pour faire fonctionner Discourse), il n’est pas impossible d’obtenir ce que vous voulez.
Maintenant, sachant que votre configuration est nginx -> varnish -> apache, pourquoi ne pas exécuter nginx -> varnish -> Discourse en ajoutant mod_security à l’image de base et en le configurant avec des hooks.
La probabilité que mod_security améliore votre sécurité est très, très faible. Les personnes qui maintiennent Discourse accordent une grande importance à la sécurité, de sorte que les problèmes que mod_security est censé résoudre sont probablement déjà pris en charge. De plus, la probabilité que l’ajout de mod_security à votre image rende Discourse inutilisable est nettement supérieure à zéro. Si vous installez mod_security et constatez que Discourse ne fonctionne plus, vous devrez seul modifier Discourse pour qu’il soit compatible avec mod_security, soit convaincre les mainteneurs de Discourse que vous avez identifié un véritable problème de sécurité, soit être contraint de maintenir votre propre fork à l’avenir.
Rien de bon ne peut en résulter. Il est hautement improbable que cela puisse avoir des conséquences positives.
D’accord, un autre WAF frôle la sécurité par l’obscurité.
De véritables efforts proactifs sont déployés pour sécuriser les discussions :
Ce sujet s’est éloigné de la question initiale concernant l’exécution de Discourse sur Apache (par opposition à un proxy vers nginx).
Cependant, je pense qu’une discussion sur la mise en place d’un WAF (mod_security ou autre) devant Discourse serait utile à la communauté. J’ai donc créé un sujet distinct pour discuter spécifiquement de Discourse + WAF ici :