[Nix-dev] [disnix] Deactivation of services

Sander van der Burg - EWI S.vanderBurg at tudelft.nl
Fri Apr 15 14:59:10 CEST 2011


> Yes, it is clear now. BTW, I must say that disnix (together with nix) is
> so great when it comes to deployment it's not even funny. Let me tell
> you what I achieved in a couple of days (just as a reminder, I'm
> deploying Django application):

I'm really looking forward to see the exact details and what you have achieved :-)

> I hope to write some blog posting about all of this and probably make
> this whole thing available to others once I clean everything up. My idea
> is to create a little (maybe Django- or Python-specific) deployment
> framework on top of disnix. But from my initial understanding of disnix
> itself it seems it's mostly a wrapper on top of base nix tools, so if I
> find and limitations I can still build my own solution easily (I think
> I would go with higher level language - like Python, I know, I'm
> biased, because I sometimes get segfaults with disnix - see note below).

Disnix is essentially complementary to the "ordinary" Nix, not a replacement. Disnix provides additional features required for networks of machines, such as interfaces, a notion to model distributed system concepts and tools to perform distributed deployment tasks.

> The only missing part I'd still like to get is hot reloading of nginx
> (it has this possibility that if you send SIGHUP to the nginx it will
> reload its configuration while still running). I haven't started working
> on it yet so I'm not sure if it's even possible with current disnix
> incarnation.

In principle, Disnix uses types for every service and each type is attached to an activation script. As a special case, there is also a 'wrapper' type available, which allows developers to include a custom wrapper script inside the service, performing the activation and deactivation. This type can be used to implement your own activation/deactivation semantics. All the properties defined in the infrastructure model for that machine are available as environment variables while running this wrapper script. You can use this to perform the activation/deactivation etc. for nginx. For example, during activation you can even check whether an existing instance is running an send it a SIGHUP.

The Disnix TCP proxy example uses wrapper types. You can use this as a reference.

> Anyway, let me thank you once again!

I'm delighted to hear that Disnix gives satisfiable results!

> P.S. as for the segmentation faults: they occur if I put nested
> attribute sets in the infrastructure.nix,

Ok, thanks for pointing this out. I think I should restrict the usage of sub attribute sets or at least make sure that they don't wreck havoc, as they can't be used directly by the activation scripts (in build expressions they can though). I will implement a fix for this ASAP.

I will also clarify the semantics of the infrastructure model a bit more in the manual, so that people know about disappearing machines. I think maybe more people will encounter the same issue you had.

Thank you for the feedback!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110415/307ade19/attachment.html 


More information about the nix-dev mailing list