Thanks for this post. It’s comforting knowing a bit about the basic mechanism running under the hood of NixOps since that’s what my companies use for all infrastructure work.
This isn’t entirely true, because it won’t auto-rollback if a changed service fails to start in its new configuration. It’ll just sit there dead. At least it’ll tell you it’s dead though :P
Is this auto-rollback feature possible? Would it just be a case of wrapping some deploy command (like nixops deploy) with something that checks the exit code and conditionally runs the rollback command? Would that actually be an undesirable feature?
For the (semi)automated but convenient updates there is niv: https://github.com/nmattia/niv
nivalso stores the version information in JSON and updates it there, so it’s a Haskell implementation of the same idea.Exactly, but with a couple of bells and whistles, especially when fetching sources from GitHub.
Thanks for this post. It’s comforting knowing a bit about the basic mechanism running under the hood of NixOps since that’s what my companies use for all infrastructure work.
Is this auto-rollback feature possible? Would it just be a case of wrapping some deploy command (like
nixops deploy) with something that checks the exit code and conditionally runs the rollback command? Would that actually be an undesirable feature?That’s exactly what we did at my previous role (did some checks and rolled back if they didn’t succeed), it’s not hard to implement.