Hi, at LogicBlox we use NixOS and NixOps extensively to deploy all sorts of clusters.
We are using dedicated deployment machines, from which different users can deploy the applications by sudo'ing to a shared user account. We back up all nix paths that nixops deployments use (using the 'nixops dump-nix-paths' command) to another standby machine as well as a S3 backed (private) binary cache. Also we backup the nixops state file every 15 minutes. This has been sufficient for our purposes until now. This way, in case of emergency, we can switch to standby server, or when shit hits the fan even more, we can have up a replacement deployment server within minutes. We also have continuously deployed systems, however these are also deployed from the shared machines. These deployments pull latest builds from Hydra (our CI system), and deploy them automatically. With regards to trace-ability / audit trail, NixOps logs to syslog which user (also via sudo) runs a nixops command, which might be helpful for that purpose. One thing to keep in mind is that the NixOps state file contains secrets, e.g. encryption or generated ssh keys, so make sure you keep it safe. I would only put it in a git repository if only you have full control over the repository, or a way to encrypt it before you push, or both :-). I think it would indeed be nice if we would have a way to choose the format for the NixOps state, and we would definitely welcome a PR for such a feature. Also, it would be good to hear from people, what kind of requirements they would have for such a feature. Cheers, Rob On Sun, Feb 22, 2015 at 8:11 PM, Thomas Hunger <[email protected]> wrote: > Could you expand on this a bit? I've been using nixops for a while, but >> only recently set up a Hydra server to run tests automatically. I'm now >> considering doing automated deployments out of hydra, but not quite sure >> how that should work. It would be simple to have a hydra job that runs >> "nixops deploy" but having a build with external side-effects like that >> seems problematic. >> > > We're running Jenkins for historical reasons. Jenkins allows executing > arbitrary shell scripts after a successful build / test. We run the tests > on Jenkins in the same nix-shell environment that we're using for > development. > Jenkins uses an exceedingly terrible XML config format but the files can > be generated which allows us to set up projects via nixops. Jenkins also > has some hooks and can e.g. be pinged by github to trigger a build. > > We briefly looked at Hydra but could not figure out how to configure it > via files (it looks like a point-and-click interface backed by a database). > Also, because we have a working system switching is very low priority for > us. There are some other open source CI systems like travis and drone which > we know of but haven't yet investigated. > > Even though it's very off-topic I'd definitely be interested in reading > more about how other companies are using nixops! > > ~ > > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- Rob Vermaas [email] [email protected]
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
