lua - proxy_pass - proxy reverso nginx

nginx proxy_pass en función de si el método de solicitud es POST, PUT o DELETE

Question

Tengo dos instancias de iKaaro ejecutan en los puertos 8080 y 9080, donde la instancia de 9080 es de solo lectura.

No estoy seguro de cómo usar nginx, por ejemplo, si el método de solicitud es POST, PUT, DELETE y luego enviar para escribir en la instancia (8080), o enviar a la instancia en 9080.

He hecho algo utilizando la ubicación utilizando la expresión regular, pero esto no es correcto.

Desde http://wiki.nginx.org/HttpLuaModule veo que hay "constantes del método HTTP" a las que se puede llamar, así que es correcto agregar un bloque de ubicación como:

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

Gracias

Answer 1

Acabo de hacer una prueba rápida, y esto funcionó para mí:

server {
location / {
# This proxy_pass is used for requests that don''t
# match the limit_except
proxy_pass http://127.0.0.1:8080;
# For requests that *aren''t* a PUT, POST, or DELETE,
# pass to :9080
limit_except PUT POST DELETE {
proxy_pass http://127.0.0.1:9080;
}
}
}

Answer 2

En el caso de que alguien busque una manera de simplemente hacer condiciones por el método de solicitud, la sintaxis es:

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

Answer 3

Supongo que tienes lo básico en su lugar. IE, ha instalado Lua 5.1, o mejor aún, LuaJIT 2.0, en su servidor, compilado Nginx con el módulo ngx_lua y configurado ngx_lua según sea necesario.

Con eso en su lugar, esto hará el trabajo:

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;
}

ACTUALIZAR

Pensé que quizás estabas usando específicamente Lua en un ámbito más amplio. El siguiente ejemplo también funcionaría con el mismo principio que 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;
}

Tanto el bloque "if" como el "limit_except" crean efectivamente un bloque de ubicación anidado y una vez que la condición coincida, solo se ejecutará el controlador de contenido ("proxy_pass") del bloque de ubicación interno creado de este modo.

No entender completamente por qué se dice que algunas veces es "malo", pero en este caso el comportamiento "malo", común a ambos "if" y "limit_except", puede ser exactamente lo que usted desea.

Así que tres opciones para que usted elija!

Sin embargo, tenga en cuenta que tendrá que vigilar que no se vea afectado por el comportamiento "malo" con cualquiera de las opciones "si" o "límite_excepto" si necesita establecer otras directivas.

IE, si establece una directiva dentro del bloque "if" o "limit_except", es posible que no esté activa fuera de él y, de manera similar, algo que se establezca afuera puede ser heredado dentro. Así que hay que observar cómo se heredan los valores predeterminados, o no, según sea el caso, con ambos enfoques.

Todos los problemas potenciales enumerados en la página Si es malvado se aplican por igual a "si" y "límite_excepto" aquí. El enfoque de scripting basado en Lua evitará muchos de los posibles escollos como se sugiere en esa página.

¡Buena suerte!

Answer 4

Yo recomendaría la función de mapa nginx. Esto va fuera de su bloque de ubicación:

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

Luego en su bloque de ubicación:

proxy_pass http://127.0.0.1:$destination

Esto también es todo expresiones regulares, por lo que puede hacer cosas como:

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

Además, esto evita el uso de si lo hace. Es bastante impresionante Lo utilicé para dirigir todo el tráfico de escritura en un clúster de WordPress a un socket FastCGI TCP en un nodo remoto, pero envié el tráfico de lectura a un socket local de FastCGI UNIX.