Announcing Hail — A service for pull-based continuous deployment from Hydra

Here at Takt we’re using nix to build our haskell projects, so of course we’re using hydra. Hydra works well as a continuous integration solution, but doesn’t fit very smoothly into any existing continuous deployment system.

Enter hail. Write a hydra job that builds a script to setup your service, point hail to that job, and your machine will keep itself up to date as the job changes. More concretely:

1. Create a hydra job whose output contains an executable bin/activate that idempotently sets up or switches to the latest version of whatever you’re deploying. This could e.g. be starting a single service (see setupSystemdUnits in nixpkgs for a distro-agnostic systemd solution) or switching to an entire new NixOS system configuration.
2. Set up your nix configuration to be able to pull from your hydra’s binary cache (you probably want the netrc-file option in your nix.conf for a private hydra)
3. Run hail pointing to your hydra job

hail works by regularly polling the latest build of the given hydra job, pulling down the result into a profile when it changes, and running the activation script.

You can even use hail to manage itself. If you’re using hail to deploy a NixOS system, this just entails putting the hail service into the NixOS configuration. If you’re deploying individual services, you can use hail-systemd-bootstrap (or something analogous for other init systems) to build a hail profile that manages hail itself. Then, to bootstrap, you can run hail with the --oneshot flag on the machine to manually pull the job down once, and be self-maintained thereafter. Currently we’re using ansible to set up hail on a freshly provisioned ec2 machine, but we’re working on an AMI that checks the instance metadata for the hydra job url appropriate for that instance and sets itself up automatically.

hail-0.1.0.1 is now up on Hackage and is hosted in the Takt github. Check the README for more details!