All of them suck. Morph is at least tolerable for my needs.
EDIT: the main reason I don’t like nixops is that it’s built on Python 2 and doesn’t really scale well to machines managed by multiple humans. Morph is a simpler tool without as much persistent state and it’s made with a language toolchain that isn’t obsolete.
I started using nixops. It has some support for provisioning machines that I liked. When that broke, I used morph. It can’t do provisioning but than maybe also had less chance of breaking?
I had some trouble making Auto-updates possible with morph - I ended up with a pretty weird hack.
I’ve been looking at doing some horrifying hack in locally hosted CI to get auto-updates working on my servers, so that seems par for the course! What hack are you using?
To be honest, when I look at the code that I used, I am not fully confident that it still works :)
The idea is to setup a “normal” nixos configuration (in configuration.nix) and use nixos for auto-updating. + separating some bigger derivations out of that into their own “source” derivations.
In my morph config, I am using configuration.nix in a pretty, ahem, rough way by merging it with my other morph config (health checks etc) like this: ...} // (import ./configuration.nix { inherit config pkgs; })
I hope that makes sense.
My supposed auto-update (minimally censored to exclude the host/blog name) functionality that import via imports in configuration.nix:
{pkgs, lib, ...}:
{
system.autoUpgrade = {
enable = true;
channel = https://nixos.org/channels/nixos-unstable;
allowReboot = true;
dates = "20:25";
};
environment.etc = {
"nixos/configuration_nix" =
let myPath = ../.;
configPath =
if lib.canCleanSource myPath
then lib.sourceByRegex myPath [ ''^nix(/.*)?$'' ''^subdir(/.*\.nix)?$'' ]
else myPath;
# By separating the sources into a separate derivation, we do not need to copy
# the whole blog over whenever any nix config changes.
config = pkgs.runCommandNoCCLocal "config-with-sources" {} ''
mkdir $out
cp -R ${configPath}/* $out
chmod +w $out/subdir
ln -s ${./blog} $out/subdir/blog
'';
in
{
target = "nixos/configuration.nix";
text = "import ${builtins.trace "using ${config}" config}/subdir/configuration.nix";
};
};
}
So here you go, there is probably a much better simpler way.
If there was better support on public clouds, I’d be using NixOS all the time, this totally kills Ansible and other configuration management solutions.
There’s actually a terraform module that you can use to load configuration into NixOS machines. It’s been on my list to write about it, but I want to use it in production a bit more before I commit to writing about it.
Which platforms does it work (well) on? I’m using this script to bootstrap Hetzner servers, and I wouldn’t mind something a bit less manually involved.
I’ve only tested it with AWS, but as far as I understand it should work fine with Google Cloud and just about anything else as long as you have a NixOS system on it.
I wonder how hard it would be to extend this solution to create a ZFS-based installation.
I’d love to have a way of automatically installing NixOS onto one of OVH’s US-based servers. I’m thinking the best way to do this would be either PXE or a variation on this kexec-based solution.
Not very! You’d just mess with the part that configures disks and mounting. I don’t use ZFS in my VMs however it should be easy to do. I would also suggest messing with how it defines the disk in question. I’m going to set something up with ZFS zraid1 groups for when I do installation on my homelab once I get the rack ordered in July (depending on how the research for my homelab goes, I currently have a spreadsheet of hardware I’d want (a bunch of used 2U servers) but I really need to wait until I move to be sure that the new place has space for it.
How mature is the Nix tooling story? I’d like to migrate from my current solution for side projects (some bespoke shell tooling), however I’m a little afraid if I invest the time to do it right that it’ll be obsolete in months or require lots of maintenance.
There are still some growing pains, the biggest upcoming change will be Nix Flakes and the new nix 2.0 CLI. Flakes is currently in Beta(?) I dunno, it’s not default yet, but it’s easily install-able. The CLI is there now, but it’s not fully fleshed out yet, so you have to go back to nix- instead of nix sometimes.
I’m still fairly new, but so far it all seems stable enough.
I love Christine’s posts :)
I’m curious how people think of
morphvis a vis thenixopstool - is one obviously better than the other for managing several NixOS machines?All of them suck. Morph is at least tolerable for my needs.
EDIT: the main reason I don’t like nixops is that it’s built on Python 2 and doesn’t really scale well to machines managed by multiple humans. Morph is a simpler tool without as much persistent state and it’s made with a language toolchain that isn’t obsolete.
I started using nixops. It has some support for provisioning machines that I liked. When that broke, I used morph. It can’t do provisioning but than maybe also had less chance of breaking?
I had some trouble making Auto-updates possible with morph - I ended up with a pretty weird hack.
I’ve been looking at doing some horrifying hack in locally hosted CI to get auto-updates working on my servers, so that seems par for the course! What hack are you using?
To be honest, when I look at the code that I used, I am not fully confident that it still works :)
The idea is to setup a “normal” nixos configuration (in
configuration.nix) and use nixos for auto-updating. + separating some bigger derivations out of that into their own “source” derivations.In my morph config, I am using
configuration.nixin a pretty, ahem, rough way by merging it with my other morph config (health checks etc) like this:...} // (import ./configuration.nix { inherit config pkgs; })I hope that makes sense.
My supposed auto-update (minimally censored to exclude the host/blog name) functionality that import via
importsinconfiguration.nix:So here you go, there is probably a much better simpler way.
If there was better support on public clouds, I’d be using NixOS all the time, this totally kills Ansible and other configuration management solutions.
There’s actually a terraform module that you can use to load configuration into NixOS machines. It’s been on my list to write about it, but I want to use it in production a bit more before I commit to writing about it.
Which platforms does it work (well) on? I’m using this script to bootstrap Hetzner servers, and I wouldn’t mind something a bit less manually involved.
I can’t find the comment. A nice lobster user pointed me at nix-infect and I use it with Terraform like this:
I’ve only tested it with AWS, but as far as I understand it should work fine with Google Cloud and just about anything else as long as you have a NixOS system on it.
Vultr lets you upload an ISO and install from that.
Edit: They even have an existing nixos ISO you can use!
I usually make my own NixOS ISO that will automatically install NixOS on the machine with something like this that I really need to write a blogpost on.
I wonder how hard it would be to extend this solution to create a ZFS-based installation.
I’d love to have a way of automatically installing NixOS onto one of OVH’s US-based servers. I’m thinking the best way to do this would be either PXE or a variation on this kexec-based solution.
Not very! You’d just mess with the part that configures disks and mounting. I don’t use ZFS in my VMs however it should be easy to do. I would also suggest messing with how it defines the disk in question. I’m going to set something up with ZFS zraid1 groups for when I do installation on my homelab once I get the rack ordered in July (depending on how the research for my homelab goes, I currently have a spreadsheet of hardware I’d want (a bunch of used 2U servers) but I really need to wait until I move to be sure that the new place has space for it.
Nice! Though as a NixOS beginner it might be easier to start out with an existing ISO. :D
Granted, but being able to assimilate a new system in about 3 minutes is a fun party trick :D
Heck yes! I look forward to your post about it!
And just like that, I had to build an ISO! Thanks for pointing me at your repo, it was very helpful! :D
NixOS + packer gives you a decent story, and then you can set userdata to finish off your images on first boot. I wrote about it here: http://jackkelly.name/blog/archives/2020/08/30/building_and_importing_nixos_amis_on_ec2/
How mature is the Nix tooling story? I’d like to migrate from my current solution for side projects (some bespoke shell tooling), however I’m a little afraid if I invest the time to do it right that it’ll be obsolete in months or require lots of maintenance.
There are still some growing pains, the biggest upcoming change will be Nix Flakes and the new nix 2.0 CLI. Flakes is currently in Beta(?) I dunno, it’s not default yet, but it’s easily install-able. The CLI is there now, but it’s not fully fleshed out yet, so you have to go back to nix- instead of nix sometimes.
I’m still fairly new, but so far it all seems stable enough.
Good timing, I was going to switch from NixOps to Morph because I didn’t want to deal with state!