aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafik Salama <ra...@oysterbooks.com>
Subject Nix and Aurora
Date Thu, 13 Aug 2015 19:48:17 GMT
I don't know how many people here would be interested in this, but I'm
hoping to draw some interest from the list (besides benley who inspired the
work).

We've been using Nix <http://nixos.org/nix/> to build and distribute the
programs we run on Aurora for a few months. It's been a tremendous success.
We first came across Nix when looking for an alternative to Docker for
isolating package dependencies and avoiding running jobs as root. Mesos
gives us the isolation we need, so Docker seemed an unjustifiable overhead
simply to isolate dependences.

In our current setup, we create a Nix profile for each task, install the
dependencies, run the processes, then clean up the Nix profile. All the
jobs are configured using the standard Pystachio configuration and we've
written some Python helpers to wrap the tasks with the proper Nix init and
cleanup processes. Basically our jobs consist of two files: one which
defines the dependencies using Nix expressions, and another which specifies
the Aurora processes and tasks. The Aurora processes depend on the
dependencies defined in Nix, but the link is implicit.

You can see where I'm going with this.

So, to form a more perfect union, I've been experimenting with replacing
pystachio configurations with Nix expressions. I have a proof of concept of
the work here: https://github.com/rafikk/nix-aurora

The repo contains the hello_world.py example from the Aurora tutorial. The
main thing to note is what happens to the fetch_package process. Since Nix
produces a cryptographic hash of its inputs, we can avoid the checksum
"trick". And since the package is really a dependency of the "hello_world"
process, we can model this explicitly by specifying the package as a build
input to the process and remove the "fetch_package" process altogether. Nix
takes care of building all the package dependencies and provides the store
paths. (this means we can even avoid copying the code into the sandbox in
the first place. just reference it from /nix/store).

As it's written, the example works with the Vagrant VM. A bit more work is
required to distribute the sandbox and dependencies to the executors.

I hope the benefits are apparent. Please let me know if you're interested
in getting this to production-grade or have any feedback!

Thanks,
Rafik

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message