Qualcuno può condividere la sua configurazione funzionante per il rate limiting di nginx al di fuori di un contenitore Docker (configurato con Discourse sulla socket)? Grazie..
Sembra che non riesca a regolarlo correttamente e sto ancora limitando il traffico valido.
Ti riferisci al fatto che il traffico viene limitato quando non dovrebbe, o che non stai limitando il traffico quando dovresti?
Esatto… per iniziare, ho utilizzato un template all’interno del contenitore e l’ho spostato all’esterno. Non so se esista una configurazione consigliata per il rate limiting dell’nginx esterno.
Emoji e avatar sembrano richiedere limiti diversi rispetto al resto del traffico.
Aggiorna.. Davvero nessuno è disposto a condividere i suoi consigli per gestire i limiti di velocità esterni di nginx? Grazie in anticipo!
Per favore, non spingere i topic. Se qualcuno avesse una risposta per te, sono sicuro che l’avrebbe già fornita.
Assumendo che tu abbia seguito le altre guide qui su meta e che nginx sia configurato correttamente per passare gli indirizzi IP dei client nel contenitore, si tratta davvero di un problema di Discourse?
a) Per quanto ne so, è consigliato utilizzare nginx al di fuori del contenitore
b) Dovrebbe essere personalizzato in base a ciò che richiede Discourse
Quindi, sì, lo considero un problema legato a Discourse.
È davvero vero e una pratica raccomandata?
Il modello di limitazione della frequenza templates/web.ratelimited.template.yml dovrebbe essere rimosso dalla configurazione Docker e la limitazione della frequenza dovrebbe quindi essere configurata nell’istanza nginx esterna.
No, Discourse non richiede nginx al di fuori del contenitore.
Nginx è già presente all’interno del contenitore ed è configurato automaticamente. L’installazione è completamente automatica, a patto che tu abbia seguito la procedura standard.
Se non stai eseguendo altri servizi sull’host, non hai affatto bisogno di un’istanza esterna di nginx.
Mi dispiace, ma non credo che un rebuild dell’app di oltre 20 minuti senza alcuna pagina offline sia una buona pratica (per un sito ad alto traffico).
Le ricostruzioni manuali che richiedono un’interruzione del servizio avvengono una o due volte all’anno. Se esegui l’aggiornamento tramite /admin/upgrade, gli aggiornamenti sono senza interruzioni.
Puoi ridurre significativamente i tempi di ricostruzione con un’installazione a due container e ti consiglio di esaminare questa opzione indipendentemente dall’uso di nginx.
L’installazione a due container sembra buona. Ma non riesco a trovare alcuna documentazione a riguardo qui sul forum 
No, non è così. È possibile, ma non è una raccomandazione standard.
Ecco la guida.
Se la tua preoccupazione principale è il downtime durante le ricostruzioni, questa è la soluzione migliore. Se hai bisogno di aiuto per configurarla, qualcuno nel canale Marketplace sarà in grado di aiutarti.