Forum: NGINX Idea: Zeroconf/Avahi support?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
2e321cc0efe9422d37165e922298494e?d=identicon&s=25 Cliff Wells (Guest)
on 2009-03-09 19:51
(Received via mailing list)
I've been considering a pair of Nginx modules that would support
Avahi/Zeroconf.  That is, let Nginx announce itself via Avahi (one
module) and another that would let it detect other services via Avahi
(the second module) for use with the upstream module.

This would allow an Nginx instance to detect when new Nginx servers are
added to a cluster (upstream) and automatically start load balancing
them without having to edit the config file and signal Nginx.

It's also worth mentioning that some web frameworks already support
Zeroconf (TurboGears being one), so they would be supported as well.

Thoughts?  I'm interested in hearing if people see potential stumbling
blocks or show-stoppers before I invest a lot of energy in it.

Regards,
Cliff
Fda08117336cfde6562315df04b976e8?d=identicon&s=25 Dave Cheney (Guest)
on 2009-03-09 22:11
(Received via mailing list)
Hi Chris,

That is an excellent idea. I would be very interested in such a module
as it would allow me to use nginx to proxy a bunch of dynamic j2ee
applications. I'd be interested in working on the companion connector
for tomcat if one doesn't already exist.

The major stubling block I can see is integrating the avahi resolver
(for lack of a better word) into Nginx without blocking.

Cheers

Dave
2e321cc0efe9422d37165e922298494e?d=identicon&s=25 Cliff Wells (Guest)
on 2009-03-09 23:18
(Received via mailing list)
On Tue, 2009-03-10 at 08:05 +1100, Dave Cheney wrote:
> Hi Chris,
>
> That is an excellent idea. I would be very interested in such a module
> as it would allow me to use nginx to proxy a bunch of dynamic j2ee
> applications. I'd be interested in working on the companion connector
> for tomcat if one doesn't already exist.
>
> The major stubling block I can see is integrating the avahi resolver
> (for lack of a better word) into Nginx without blocking.

I'm still investigating, but I believe that Avahi supports async (via
dbus callback at least).

Cliff
4e1ae4b836a9cfe3945d8c661b37246b?d=identicon&s=25 Manlio Perillo (Guest)
on 2009-03-09 23:33
(Received via mailing list)
Cliff Wells ha scritto:
> I've been considering a pair of Nginx modules that would support
> Avahi/Zeroconf.  That is, let Nginx announce itself via Avahi (one
> module) and another that would let it detect other services via Avahi
> (the second module) for use with the upstream module.
>
> This would allow an Nginx instance to detect when new Nginx servers are
> added to a cluster (upstream) and automatically start load balancing
> them without having to edit the config file and signal Nginx.
>

This would probabily require a rewrite of the upstream module, to
support dynamic configuration.


 > [...]


Regards  Manlio
535e2bd84829abaf90def03e89299e20?d=identicon&s=25 Marcus Clyne (Guest)
on 2009-03-09 23:33
(Received via mailing list)
Cliff Wells wrote:
>> (for lack of a better word) into Nginx without blocking.
>>
Making Avahi non-blocking wouldn't be difficult.  If Avahi is
long-running, you can put it in a separate thread and send information
back to Nginx via writing information to a pipe (since Nginx isn't
thread-safe).  I'm not sure how Avahi works, but you might want to use
the a timed event (there are functions available for this in the Nginx
source) as a trigger.

Marcus.
2e321cc0efe9422d37165e922298494e?d=identicon&s=25 Cliff Wells (Guest)
on 2009-03-10 00:01
(Received via mailing list)
On Mon, 2009-03-09 at 22:26 +0000, Marcus Clyne wrote:
> > >
> > > The major stubling block I can see is integrating the avahi resolver
> > > (for lack of a better word) into Nginx without blocking.
> > >
> Making Avahi non-blocking wouldn't be difficult.  If Avahi is
> long-running, you can put it in a separate thread and send information
> back to Nginx via writing information to a pipe (since Nginx isn't
> thread-safe).  I'm not sure how Avahi works, but you might want to use
> the a timed event (there are functions available for this in the Nginx
> source) as a trigger.

It seems Avahi is actually designed to be tied into an event loop:

http://www.mail-archive.com/avahi@lists.freedeskto...


Cliff
535e2bd84829abaf90def03e89299e20?d=identicon&s=25 Marcus Clyne (Guest)
on 2009-03-10 00:01
(Received via mailing list)
Manlio Perillo wrote:
>
> This would probabily require a rewrite of the upstream module, to
> support dynamic configuration.
>
What about using a repeating timed event that checked for new upstream
servers, perhaps launching the search in a new thread?  If the server
makeup has changed, then an event could be triggered to change the
upstream configuration?  This wouldn't require re-writing the upstream
module, but would it cause problems to existing connections to upstream
servers?  Since events and file descriptors would already be registered
by this point, the main problem might be with connections where the next
upstream needed to be selected, but that might still be ok (depending on
how it's implemented, which I've not looked at).

Of course rewriting of the upstream module might give a more elegant
solution. ;-)
>
> > [...]
>
>
> Regards  Manlio
>
>

Marcus.
535e2bd84829abaf90def03e89299e20?d=identicon&s=25 Marcus Clyne (Guest)
on 2009-03-10 10:22
(Received via mailing list)
> It seems Avahi is actually designed to be tied into an event loop:
>
> http://www.mail-archive.com/avahi@lists.freedeskto...
>
>
Even better. :-)

Marcus.
4e1ae4b836a9cfe3945d8c661b37246b?d=identicon&s=25 Manlio Perillo (Guest)
on 2009-03-11 15:18
(Received via mailing list)
Marcus Clyne ha scritto:
>>
> What about using a repeating timed event that checked for new upstream
> servers, perhaps launching the search in a new thread?  If the server
> makeup has changed, then an event could be triggered to change the
> upstream configuration?

This is already feasible without touching Nginx code.

Just write a small server (in a language like Python), than when a new
upstream is available, modify the Nginx configuration file and send an
HUP signal to the Nginx process.


 > [...]


Regards  Manlio
535e2bd84829abaf90def03e89299e20?d=identicon&s=25 Marcus Clyne (Guest)
on 2009-03-11 16:06
(Received via mailing list)
> This is already feasible without touching Nginx code.
>
> Just write a small server (in a language like Python), than when a new
> upstream is available, modify the Nginx configuration file and send an
> HUP signal to the Nginx process.
Sounds like a better idea, though I'm in Nginx-hacking mode at the
moment so didn't think of it. ;-)

It would be pretty easy to adapt it to other servers, too - you'd just
need to change the output configuration.

Perhaps this type of monitor already exists, if not for Nginx for
something else.

Marcus.
This topic is locked and can not be replied to.