Nginx - Google Summer of Code ideas
mike
mike503 at gmail.com
Sat Mar 14 20:02:59 MSK 2009
I'd like to say first - during brainstorming there are no bad ideas :)
On Sat, Mar 14, 2009 at 8:00 AM, Manlio Perillo
<manlio_perillo at libero.it> wrote:
> Its because DAV is not simple to implement.
But nginx already does DAV. I use it for mogilefs without a problem.
What needs to be determined is what is missing to make this happen.
Obviously there are some limitations, but I am sure it can be done.
>>> This does not need to be done with Nginx.
>>> Just use a pre existing healthchecking software with each of the upstream
>>> servers.
>>
>> and what, have an /etc/nginx/upstreams.conf file that i manually
>> update and kill -HUP nginx or whatever appropriate signal to reload
>> every time i notice an upstream going up or down?
>>
>
> Right.
That just seems .... messy. Although if the avahi/zeroconf idea gets
mixed in this might become a moot point as I understand it it would be
discovering and adding/removing automagically.
> If this requires some internal rewrite of Nginx, then I'm not sure it is a
> good idea.
That's why it's thrown out there as an idea.
I'm sure it can be done with a third party module. After all it's just
issuing an HTTP request to an upstream and getting back a response,
and then removing it from the pool.
upstream backend {
server backend1.example.com weight=5 check=tcp;
server backend2.example.com:8080 check=response
url=http://foo.com/health.php expect="hello world";
server unix:/tmp/backend3;
}
etc?
check=tcp is simple, check=response would expect a plaintext response back.
Or, those attributes could be cleaned up or put into it's own type of block:
response foo {
url http://foo.com/health.php
expect "hello world";
}
block, and check=response response=@foo;
If would need to be smart enough to pick out the host piece so it can
issue the proper Host: when connecting to the internal IPs of the
servers.
More information about the nginx
mailing list