I started writing a NixOps tutorial:
I’ve only written the first chapter so far, and want to extend it in the future to show how to how to modularise things, re-use more code and write sophisticated multi-machine interactions.
I’ve already pushed out some big nixops examples before, such as GitHub - nh2/nixops-gluster-example: Advanced nixops deployment example: GlusterFS, but with this tutorial I put extra effort on reproducibility, pinning the versions of not only nixpkgs but also Nix and NixOps (check the
./mynix script in the tutorial repo).
I’d appreciate any people trying out this first chapter and reporting if it worked.
This is great and looking forward to testing more complex examples like gluster!
Just a few points/wishlist.
- is there a reason for the ./mynix wrapper? shell.nix might be enough and can showcase nix-shell to newcomers.
- it also be great if we could have a dropdown box that switches different sections to use vagrant,aws,etc
- best practices for storing/sharing the nixops state
shell.nix might be enough
Is it? If you can show me a
shell.nix based example that can do all the things my wrapper can currently do, I’ll probably switch to it.
dropdown box that switches different sections to use vagrant,aws,etc
Not sure how you mean, like in the tutorial? I don’t think Github’s Markdown can do dropdown boxes. Also if I add those, I’d also have to keep them updated and ensure they work, so I’m not super sure about it.
best practices for storing/sharing the nixops state
Yes, that’d be a good addition, but I’ll probably focus on that after making some more sophisticated examples.
My preferred solution is to just use a bastion machine that all team members use. If high availability is needed against failure of the bastion machine, I’d put the nixops sqlite file onto a highly available POSIX network file system like CephFS.
Here is an example of a
shell.nix that pins two nixpkgs releases, it doesn’t pin any tool to the
unstable version but doing that is just a
Also, it’s much better for me to enter the custom environment at the beginning, using the commands, and then exit it. Probably it’s more efficient too…