nginx proxy_pass basato sul fatto che il metodo di richiesta POST, INSERIRE o ELIMINARE

Ho due iKaaro istanze in esecuzione sulla porta 8080 e 9080, dove il 9080 istanza è di sola Lettura.

Non sono sicuro di come usare nginx per esempio, se il metodo di richiesta POST, PUT, DELETE e poi inviare a scrivere istanza (8080) inviare a 9080 istanza.

Ho fatto qualcosa con la posizione utilizzando le regex, ma questo non è corretto.

Da http://wiki.nginx.org/HttpLuaModule vedo che c’è il ‘metodo HTTP costanti”, che può essere chiamato, così è corretto aggiungere un blocco di posizione come:

location ~* "(ngx.HTTP_POST|ngx.HTTP_DELETE|ngx.HTTP_PUT)" {
    proxy_pass http://127.0.0.1:8080;

Grazie

  • Si può spiegare la domanda un po ‘ meglio? Hai provato che l’installazione? Si verificano errori con esso (quali)?
InformationsquelleAutor khinester | 2011-12-21

 

4 Replies
  1. 35

    Ho appena fatto una prova veloce, e questo ha funzionato per me:

    server {
      location /{
        # This proxy_pass is used for requests that don't
        # match the limit_except
        proxy_pass http://127.0.0.1:8080;
    
        limit_except PUT POST DELETE {
          # For requests that *aren't* a PUT, POST, or DELETE,
          # pass to :9080
          proxy_pass http://127.0.0.1:9080;
        }
      }
    }
    • questo è ancor di più
    • inoltre non fare affidamento su qualsiasi di moduli di terze parti
    • Non funziona per me nginx 1.7.6..
    • Questo è piuttosto confusa, prima dici don't match the limit_except e prima che il limit_except dici aren't, quindi se ho un GET richiesta, non coincide con la limit_except (così 8080 secondo commento), ma anche GET non è “una PUT, POST, o ELIMINA”, quindi 9080
    • Ho spostato il secondo commento in limit_except blocco. Fa che rendere più chiaro per voi che le richieste saranno gestite da tale blocco interno e non esterno proxy_pass?
  2. 11

    Presumo che hai le basi. I. E., è stato installato Lua 5.1, o meglio ancora, LuaJIT 2.0, sul server, compilato Nginx con il ngx_lua modulo e configurato ngx_lua come richiesto.

    Con quella in atto, Questo farà il lavoro:

    location /test {
        content_by_lua '
            local reqType = ngx.var.request_method
            if reqType == ngx.HTTP_POST 
                OR reqType == ngx.HTTP_DELETE 
                OR reqType == ngx.HTTP_PUT 
            then
                res = ngx.location.capture("/write_instance")
            else
                res = ngx.location.capture("/read_instance")
            end
            ngx.say(res.body)
        ';
    }
    location /write_instance {
        internal;
        proxy_pass http://127.0.0.1:8080;
    }
    location /read_instance {
        internal;
        proxy_pass http://127.0.0.1:9080;
    }

    AGGIORNAMENTO

    Ho pensato che forse si erano specificamente utilizza Lua in un ambito più ampio. L’esempio riportato di seguito potrebbe anche lavorare sullo stesso principio come limit_except.

    location /test {
        if ($request_method !~* GET) {
            # For Write Requests
            proxy_pass http://127.0.0.1:8080;
        }
        # For Read Requests
        proxy_pass http://127.0.0.1:9080;
    }

    Entrambi i “se” e “limit_except” blocco di creare efficacemente un nidificati blocco di posizione e una volta che la condizione partite, ma solo il gestore di contenuto (“proxy_pass”) dell’interno blocco di posizione così creato verrà eseguito.

    Non completamente ottenendo questo è il motivo per cui se è a volte detto di essere “male”, ma in questo caso il “male” è un comportamento comune a entrambi i “se” e “limit_except”, potrebbe essere esattamente quello che vuoi.

    Così tre scelte per voi da scegliere!

    Di notare, tuttavia, che è necessario guardare che non è possibile ottenere morso da il “male” comportamento con i “se” o “limit_except” opzioni se avete bisogno di impostare altre direttive.

    I. E., se si imposta una direttiva all’interno del “se” o “limit_except blocco, che potrebbe non essere attivo al di fuori di essa e allo stesso modo, è qualcosa di fuori può essere ereditato all’interno. Quindi devi guardare come impostazioni predefinite vengono ereditate, o non, come potrebbe essere il caso, con entrambi gli approcci.

    Tutti i potenziali problemi elencati sul Se è Male pagina si applicano ugualmente ai “se” e “limit_except” qui. Lua base di scripting approccio evitare molti di questi potenziali insidie, come suggerito nella pagina.

    Buona fortuna!

    • grazie per questo ha senso.
    • grazie per la dettagliata di espianto, quindi ho bisogno di prendersi cura se il IfiSEvil devo eseguire altre direttive. Potrebbe essere necessario, come ho anche bisogno di includere un URL specifico, come ad esempio la posizione ~* “(login|new_content)” { … ma cerco di capire e venire qui con la mia nginx.file conf per vedere se può essere migliorato.
    • Cercare di separare le query dal problema specifico. Presumo che con le tre opzioni che si hanno, la domanda specifica su come indirizzare le richieste di Nginx basato sul metodo di richiesta è stato risposto in modo esauriente. È possibile che si “se” direttamente o “limit_except”, che è un tipo di istruzione se con il potenziale di problemi in mente, o utilizzare un metodo di scripting come il Lua esempio per evitare questi problemi. Si potrebbe desiderare di prendere in considerazione di accettare l’una o l’altra delle risposte date e chiede una nuova domanda se ci sono altri problemi.
    • Questa è stata un’informativa risposta. Sto cercando di utilizzare la prima soluzione (il content_by_lua approccio), ma sto notando che la chiamata a ngx.say(res.body) non include le intestazioni dall’oggetto response, solo il corpo. Come posso ottenere il response header scritto il finale ngx risposta?
  3. 1

    Nel caso In cui qualcuno cerca di un modo per fare condizioni di metodo di richiesta, la sintassi è:

    if ($request_method = DELETE ) {
       . . . 
    }
  4. 1

    Mi raccomando il nginx funzione di mappa. Questo va al di fuori della posizione di blocco:

    map $request_method $destination {
        default 8080;
        PUT 9080;
        POST 9080;
        DELETE 9080;
    }

    Poi nella posizione di blocco:

    proxy_pass http://127.0.0.1:$destination

    Questo è tutto, espressioni regolari, in modo da poter fare le cose come:

    map $request_method $cookie_auth $destination {
        default 8080;
        "^POST " 9080;
        "^PUT someAuthCookieValue" 9080;
    }

    Plus questo evita l’uso di se. E ‘ abbastanza impressionante. L’ho utilizzato per indirizzare tutti di scrivere per il traffico di WordPress cluster di uno FastCGI socket TCP su un nodo remoto, ma invia in lettura il traffico locale FastCGI socket UNIX.

Lascia un commento