¿Alguien puede compartir su configuración funcional para limitar la tasa en nginx fuera de un contenedor Docker (configurado con Discourse en el socket)? Gracias..
Parece que no puedo ajustarlo correctamente y sigo limitando el tráfico válido.
¿Alguien puede compartir su configuración funcional para limitar la tasa en nginx fuera de un contenedor Docker (configurado con Discourse en el socket)? Gracias..
Parece que no puedo ajustarlo correctamente y sigo limitando el tráfico válido.
¿Te refieres a que el tráfico se está limitando cuando no debería, o a que no estás limitando el tráfico cuando sí deberías?
Exactamente… para empezar, he usado una plantilla desde dentro del contenedor y la he movido fuera. No sé si hay alguna configuración recomendada para la limitación de velocidad del nginx externo.
Parece que los emojis y los avatares son adecuados para límites diferentes al resto del tráfico.
¡Bump! ¿Realmente nadie está dispuesto a compartir sus consejos para gestionar los límites de tasa en nginx externo? ¡Gracias de antemano!
Por favor, no subas los temas. Si alguien tuviera una respuesta para ti, estoy seguro de que la habría ofrecido.
Asumiendo que has seguido las otras guías aquí en meta, y que nginx está configurado correctamente para pasar las IPs de los clientes al contenedor, ¿es esto realmente un problema de Discourse?
a) Por lo que sé, se recomienda usar nginx fuera del contenedor.
b) Debería estar adaptado específicamente a lo que requiere Discourse.
Así que, sí, lo veo como un problema relacionado con Discourse.
¿Es esto realmente cierto y una práctica recomendada?
La plantilla de límite de velocidad templates/web.ratelimited.template.yml debe eliminarse de la configuración de Docker y el límite de velocidad debe configurarse entonces en la instancia externa de nginx.
No, Discourse no requiere nginx fuera del contenedor.
Nginx ya existe dentro del contenedor y se configura automáticamente. Es de configuración cero siempre que hayas seguido la instalación estándar.
Si no estás ejecutando ningún otro servicio en el host, no necesitas ninguna instancia externa de nginx en absoluto.
Lo siento, pero no creo que reconstruir una aplicación durante más de 20 minutos sin ninguna página sin conexión sea una buena práctica (para sitios de alto tráfico).
Las reconstrucciones manuales que requieren tiempo de inactividad ocurren una o dos veces al año. Si actualizas a través de /admin/upgrade, las actualizaciones son transparentes.
Puedes reducir significativamente tus tiempos de reconstrucción con una instalación de dos contenedores, y te recomendaría que investigues esto independientemente de si usas nginx.
La instalación de dos contenedores suena bien. Pero no puedo encontrar ninguna documentación sobre eso aquí en el foro ![]()
No, no es así. Es posible, pero no es una recomendación estándar.
Aquí tienes la guía.
Si tu principal preocupación es el tiempo de inactividad durante las reconstrucciones, esa será tu mejor opción. Si necesitas ayuda para configurarlo, alguien en Marketplace podrá ayudarte.