Est-ce que quelqu’un pourrait partager sa configuration fonctionnelle pour la limitation de débit de nginx en dehors d’un conteneur Docker (configuré avec Discourse sur le socket) ? Merci..
Je semble incapable de le régler correctement et je continue à limiter le trafic valide.
Voulez-vous dire que le trafic est limité alors qu’il ne devrait pas l’être, ou que vous ne limitez pas le trafic alors que vous devriez le faire ?
Exactement… pour commencer, j’ai utilisé un modèle à l’intérieur du conteneur et l’ai déplacé à l’extérieur. Je ne sais pas s’il existe une configuration recommandée pour la limitation de débit de nginx externe.
Les emojis et les avatars semblent convenir à des limites différentes du reste du trafic.
Bump… Vraiment, personne n’est prêt à partager ses astuces pour gérer les limites de taux pour nginx externe ? Merci d’avance !
S’il vous plaît, ne faites pas remonter les sujets. Si quelqu’un avait une réponse pour vous, il l’aurait certainement donnée.
En supposant que vous ayez suivi les autres guides ici sur meta, et que nginx soit correctement configuré pour transmettre les adresses IP des clients au conteneur, s’agit-il réellement d’un problème lié à Discourse ?
a) À ma connaissance, il est recommandé d’utiliser nginx en dehors du conteneur.
b) Il devrait être conçu sur mesure pour répondre aux besoins de Discourse.
Donc, oui, je considère cela comme un problème lié à Discourse.
Est-ce vraiment vrai et une pratique recommandée ?
Le modèle de limitation de débit templates/web.ratelimited.template.yml doit être supprimé de la configuration Docker, et la limitation de débit doit ensuite être configurée dans l’instance nginx externe à la place.
Non, Discourse ne nécessite pas nginx en dehors du conteneur.
Nginx existe déjà à l’intérieur du conteneur et est configuré automatiquement. C’est une configuration sans intervention manuelle, à condition d’avoir suivi l’installation standard.
Si vous n’exécutez aucun autre service sur l’hôte, vous n’avez pas besoin d’une instance nginx externe.
Désolé, mais je ne pense pas qu’une reconstruction d’application de plus de 20 minutes sans aucune page hors ligne soit une bonne pratique (pour un site à fort trafic).
Les reconstructions manuelles nécessitant une interruption de service ont lieu une ou deux fois par an. Si vous effectuez la mise à jour via /admin/upgrade, les mises à jour sont transparentes.
Vous pouvez réduire considérablement vos temps de reconstruction avec une installation à deux conteneurs, et je vous recommande de vous y intéresser, que vous utilisiez nginx ou non.
L’installation en deux conteneurs semble bien. Mais je ne trouve aucune documentation à ce sujet ici sur le forum 
Non, ce n’est pas le cas. C’est possible, mais ce n’est pas une recommandation standard.
Voici le guide.
Si votre principale préoccupation est l’arrêt de service lors des reconstructions, c’est votre meilleure option. Si vous avez besoin d’aide pour la configuration, quelqu’un dans Marketplace pourra vous aider.