3 ms·

> I never really feel 100% confident that something is gonna work as I hope until I physically try it I ended up in the same situation too, but discovered rela

by diggan 1y ago

> I never really feel 100% confident that something is gonna work as I hope until I physically try it I ended up in the same situation too, but discovered relatively quickly that NixOS makes it really easy to build clean VMs from your config that you can run and test against, then when validated, you apply the configuration to the actual hardware. I'm doing this for all my servers managed with NixOS right now, and managed to prevent multiple issues being deployed, including something that would prevent a clean boot and since the host is headless, would have required me to connect monitor and keyboard in order to recover. Really glad NixOS is setup the way it is, although you're right the learning curve is rough. At least I can easily re-install my infrastructure really trivially, which helps me sleep at night.

zxexz 1y ago
I’m using that exact feature for a blue/green/another color deploy setup, it’s very nice. The server with the hosted application builds a vm of itself, run some checks. Route traffic to (RR). If it’s all good, send the VM to a secondary house and route to there. On the primary, reboot (usually kexec). Switch back over. Should probably just be using a persistent but this is some pretty heterogenous hardware and…it works
bjackman 1y ago
Yeah I make extensive use of this and it's absolutely fantastic. I can write a config, very quickly check it seems correct on a QEMU guest, and then deploy "the same" config to a physical host (slower to boot, harder to debug, annoying to power cycle) and be highly confident it's gonna behave like the VM did. This is incredibly valuable! But by "hard to know if it's gonna work" I was talking more about architecture-level concerns. Not "is my Nix code correct" but "is this thing I'm envisaging a thing that the ecosystem supports?" I usually just have to sit down and try coding it up, and there's always an element of uncertainty about whether I'll succeed. Whereas if I sit down to get something done in Ansible I don't really have any such doubts. (But the result will be dramatically worse).
- tlavoie 1y ago
  Regarding how a bunch of the pieces go together, I found this blog post from Shopify quite useful: https://shopify.engineering/what-is-nix https://shopify.engineering/what-is-nix
- woile 1y ago
  how do you do this and what do you use? do you just manually trigger qemu? I'd love to be able to boot VM with different nix configurations.
  - bjackman 1y ago
    Usually I just use `nix run .#nixosConfigurations.<my config>.config.system.build.vm` This boots directly into the kernel with QEMU's '-kernel' option, and it mounts the host Nix store into the guest via Plan 9 FS. So there is some significant difference vs a full system, e.g. it's not possible to nixos-rebuild the VM. But if you're just testing high-level stuff it's totally fine. Then there's also a .vmWithBootloader variant which behaves a bit more like a physical machine, IIUC it builds a disk image and boots it via Nixos' actual bootloader.

by diggan 1y ago

zxexz 1y ago

I’m using that exact feature for a blue/green/another color deploy setup, it’s very nice. The server with the hosted application builds a vm of itself, run some checks. Route traffic to (RR). If it’s all good, send the VM to a secondary house and route to there. On the primary, reboot (usually kexec). Switch back over. Should probably just be using a persistent but this is some pretty heterogenous hardware and…it works

bjackman 1y ago

Yeah I make extensive use of this and it's absolutely fantastic. I can write a config, very quickly check it seems correct on a QEMU guest, and then deploy "the same" config to a physical host (slower to boot, harder to debug, annoying to power cycle) and be highly confident it's gonna behave like the VM did. This is incredibly valuable! But by "hard to know if it's gonna work" I was talking more about architecture-level concerns. Not "is my Nix code correct" but "is this thing I'm envisaging a thing that the ecosystem supports?" I usually just have to sit down and try coding it up, and there's always an element of uncertainty about whether I'll succeed. Whereas if I sit down to get something done in Ansible I don't really have any such doubts. (But the result will be dramatically worse).

tlavoie 1y ago
Regarding how a bunch of the pieces go together, I found this blog post from Shopify quite useful: https://shopify.engineering/what-is-nix https://shopify.engineering/what-is-nix
woile 1y ago
how do you do this and what do you use? do you just manually trigger qemu? I'd love to be able to boot VM with different nix configurations.
- bjackman 1y ago
  Usually I just use `nix run .#nixosConfigurations.<my config>.config.system.build.vm` This boots directly into the kernel with QEMU's '-kernel' option, and it mounts the host Nix store into the guest via Plan 9 FS. So there is some significant difference vs a full system, e.g. it's not possible to nixos-rebuild the VM. But if you're just testing high-level stuff it's totally fine. Then there's also a .vmWithBootloader variant which behaves a bit more like a physical machine, IIUC it builds a disk image and boots it via Nixos' actual bootloader.