4 ms·

Other than integration with the rest of the Nix/NixOS ecosystem, how is NixOps different from Puppet? Reading briefly through the examples, it seems very orien

Other than integration with the rest of the Nix/NixOS ecosystem, how is NixOps different from Puppet? Reading briefly through the examples, it seems very oriented towards provisioning machine instances rather than provisioning behavior across networks or multi-machine services, which is something that Puppet really excels at. What features does this offer in addition to ones that Puppet provides? That said, I've been getting tired of Puppet recently for some unrelated reasons, so I'll definitely give this a try.

zimbatm 9y ago
NixOS is the system configuration layer and closer to puppet in solo mode. With a single (or multiple) nix file(s) it's possible to configure a machine and it's services entirely. NixOps is the cloud configuration layer, it provisions cloud resources and uploads NixOS configuration to the machines. It's closer to terraform in that regard. It also has a state file (currently sqlite3) and uses a push model to propagate configuration changes. What's missing right now is a third option where an agent is installed on the machines for a more dynamic configuration of the cluster as a whole. This role will probably be filled by Kubernetes or Nomad.
- wmertens 9y ago
  Note that with nixops, you can pass variables to the whole deployment configuration, and as such, your deployment is "dynamic" if you reconfigure it often enough :) Here's a deployment of mesos where you can specify how many slaves and masters you want: https://github.com/wmertens/nixops-mesos https://github.com/wmertens/nixops-mesos
phunehehe0 9y ago
> Other than integration with the rest of the Nix/NixOS ecosystem Nix/NixOS is the big deal actually. NixOps is just icing on the cake. A NixOS installation is configured by building/copying over a system profile, and then activating it. With just NixOS, you edit a configuration file on the server, then run a command that will build a system profile from that configuration and activate it. With NixOps, you have configuration files on your workstation, and run commands to build the system profiles, copy it to the servers, and activate them. Of course you can do all of this without NixOps. It just makes certain things easier. Puppet and others can do all of this, too. However state transition tend to be the weakest link (e.g. tell Puppet to provision a brand new server vs one that has run some other stuff, how sure are you that the resulting systems are the same?). Nix/NixOS takes care of that (most of the time anyway -- there are still things like data migrations that applications have to take care of).
solatic 9y ago
Linux wasn't designed to be an immutably-configured operating system. When systems like Puppet try to apply configuration to a target server, they're operating on top of a layer which is inherently stateful, which has a propensity to cause all sorts of problems. What if somebody manually entered this server and screwed with the configuration, outside of Puppet? What if poorly packaged applications don't cleanly uninstall or upgrade properly? Systems like Puppet tend to just throw an error at the sysadmin and walk away. NixOS treats immutable configuration as a first-class citizen at the OS level. Dependenices are not installed into /usr or /etc, rather specific versions of packages (identified by their hashes) are installed into /nix/store and then symlinked back to /usr or /etc. Different applications that require different versions of the same dependency, when packaged according to standard, harmoniously co-exist on the same server because the Nix packaging system symlinks the dependencies between each other in /nix/store. You don't realize the full power of this setup until you make a mistake, make your system unbootable, and calmly tell GRUB to just use the last valid configuration - a few minutes later and you're back at a desktop. Conventional configuration management tool like Puppet tend to be worthless in those kinds of failure modes, and most sysadmins would be implementing backup restoration procedures.
- aseipp 9y ago
  Here's another example that is simple, but one I still appreciate: I wanted a slightly newer kernel. How do I get it, and ensure all the "downstream" dependencies are rebuilt (e.g. kernel modules)?[1] I write this into my configuration.nix: boot.kernelPackages = pkgs.linuxPackages_latest; I run `nixos-rebuild switch && reboot` and I'm done. I can switch back to the last one if I wanted, but this new one takes place immediately. I just did this on a server 20 minutes ago. There are other small things I can do with this. What if I didn't want to boot this kernel to boot, just test it? $ nixos-rebuild build-vm $ ./result/bin/run-*-vm This will instantly drop you into a QEMU-KVM instance that is using NixOS with your `configuration.nix`, but if you rebooted nothing would change. (You can also specify a different configuration.nix to test other machines![2]) Or I could boot it, but just once and switch back pretty easily if something was wrong. --- Another: What if I wanted Tarsnap backups of something? (This may be out of date, but it's my old config, and I wrote the Tarsnap module) services.tarsnap.enable = true; services.tarsnap.archives = { nixos = { checkpointBytes = "5GB"; directories = [ "/root" "/etc/nixos" ]; }; home = { excludes = [ "*.o" "*.hi" ]; checkpointBytes = "5GB"; directories = [ "/home/a" ]; }; }; Now I can do things like this: $ systemctl start tarsnap@home $ systemctl start tarsnap@nixos To start on demand. Or I can configure timers/cron to do this manually. Lots of other small things. Binary caches, your own Hydra, remote/multi-architecture builds, etc. One time I "configured" my NixOS laptop install before getting my laptop: on a remote testing server, over remote KVM. Pushed it to git. I cloned my configuration.nix during NixOS installation on my laptop a few days later, and I replicated my laptop in 10 minutes. :) Combine this with Hydra (CI) server: You can even write tests and have your laptop configuration continuously integrated all the time?!?!?!? That said NixOS isn't always the easiest thing to use, but it does come with some big advantages! [1] I'm aware of DKMS (and have even worked on modules using it where it was fine) but I've still had it break once or twice. Maybe that was VMWare's fault :) [2] If you share code between all your configuration.nix files, this becomes a lot easier.
nh2 9y ago
To say what my sibling comments say, more briefly: With the nix system you can fully declaratively state your entire fleet of machines, from your highest level application configs all the way down to kernel patches. When you run nixops, your machines become exactly as specified. That this works reliably is a novelty: most other configuration management tools work like "action runners" that try in a best-effort fashion to achieve the desired state, but that doesn't always work (for example in Ansible, declaring a package as installed installs it, but NOT declaring a package will not uninstall it). It is made possible because the nix system is designed from the bottom up to be declarative. That makes it different from Puppet.
- majewsky 9y ago
  > most other configuration management tools work like "action runners" that try in a best-effort fashion to achieve the desired state, but that doesn't always work (for example in Ansible, declaring a package as installed installs it, but NOT declaring a package will not uninstall it). Most other configuration management tools have no choice. I got my own [1] to the point where it cannot only provision files/users/groups, but also clean them up correctly most of the time. However, since it is not the final authority (the package manager is... or rather, root is), there will always be situations where the entity that needs to be provisioned will be found to be in an entirely unanticipated state. You have basically two ways to solve this conundrum: 1. just throw everything away and start from a clean slate when the configuration changes (aka containers) 2. do configuration management in the package manager and encourage/force root to keep his filthy hands off the system partition (aka NixOS et al) [1] https://github.com/holocm/holo https://github.com/holocm/holo
  - jacques_chester 9y ago
    BOSH uses both tactics. It deals in whole VMs, but parks deployed software in a known location that's the same for all stemcells.

zimbatm 9y ago

NixOS is the system configuration layer and closer to puppet in solo mode. With a single (or multiple) nix file(s) it's possible to configure a machine and it's services entirely. NixOps is the cloud configuration layer, it provisions cloud resources and uploads NixOS configuration to the machines. It's closer to terraform in that regard. It also has a state file (currently sqlite3) and uses a push model to propagate configuration changes. What's missing right now is a third option where an agent is installed on the machines for a more dynamic configuration of the cluster as a whole. This role will probably be filled by Kubernetes or Nomad.

wmertens 9y ago
Note that with nixops, you can pass variables to the whole deployment configuration, and as such, your deployment is "dynamic" if you reconfigure it often enough :) Here's a deployment of mesos where you can specify how many slaves and masters you want: https://github.com/wmertens/nixops-mesos https://github.com/wmertens/nixops-mesos

phunehehe0 9y ago

> Other than integration with the rest of the Nix/NixOS ecosystem Nix/NixOS is the big deal actually. NixOps is just icing on the cake. A NixOS installation is configured by building/copying over a system profile, and then activating it. With just NixOS, you edit a configuration file on the server, then run a command that will build a system profile from that configuration and activate it. With NixOps, you have configuration files on your workstation, and run commands to build the system profiles, copy it to the servers, and activate them. Of course you can do all of this without NixOps. It just makes certain things easier. Puppet and others can do all of this, too. However state transition tend to be the weakest link (e.g. tell Puppet to provision a brand new server vs one that has run some other stuff, how sure are you that the resulting systems are the same?). Nix/NixOS takes care of that (most of the time anyway -- there are still things like data migrations that applications have to take care of).

solatic 9y ago

Linux wasn't designed to be an immutably-configured operating system. When systems like Puppet try to apply configuration to a target server, they're operating on top of a layer which is inherently stateful, which has a propensity to cause all sorts of problems. What if somebody manually entered this server and screwed with the configuration, outside of Puppet? What if poorly packaged applications don't cleanly uninstall or upgrade properly? Systems like Puppet tend to just throw an error at the sysadmin and walk away. NixOS treats immutable configuration as a first-class citizen at the OS level. Dependenices are not installed into /usr or /etc, rather specific versions of packages (identified by their hashes) are installed into /nix/store and then symlinked back to /usr or /etc. Different applications that require different versions of the same dependency, when packaged according to standard, harmoniously co-exist on the same server because the Nix packaging system symlinks the dependencies between each other in /nix/store. You don't realize the full power of this setup until you make a mistake, make your system unbootable, and calmly tell GRUB to just use the last valid configuration - a few minutes later and you're back at a desktop. Conventional configuration management tool like Puppet tend to be worthless in those kinds of failure modes, and most sysadmins would be implementing backup restoration procedures.

aseipp 9y ago
Here's another example that is simple, but one I still appreciate: I wanted a slightly newer kernel. How do I get it, and ensure all the "downstream" dependencies are rebuilt (e.g. kernel modules)?[1] I write this into my configuration.nix: boot.kernelPackages = pkgs.linuxPackages_latest; I run `nixos-rebuild switch && reboot` and I'm done. I can switch back to the last one if I wanted, but this new one takes place immediately. I just did this on a server 20 minutes ago. There are other small things I can do with this. What if I didn't want to boot this kernel to boot, just test it? $ nixos-rebuild build-vm $ ./result/bin/run-*-vm This will instantly drop you into a QEMU-KVM instance that is using NixOS with your `configuration.nix`, but if you rebooted nothing would change. (You can also specify a different configuration.nix to test other machines![2]) Or I could boot it, but just once and switch back pretty easily if something was wrong. --- Another: What if I wanted Tarsnap backups of something? (This may be out of date, but it's my old config, and I wrote the Tarsnap module) services.tarsnap.enable = true; services.tarsnap.archives = { nixos = { checkpointBytes = "5GB"; directories = [ "/root" "/etc/nixos" ]; }; home = { excludes = [ "*.o" "*.hi" ]; checkpointBytes = "5GB"; directories = [ "/home/a" ]; }; }; Now I can do things like this: $ systemctl start tarsnap@home $ systemctl start tarsnap@nixos To start on demand. Or I can configure timers/cron to do this manually. Lots of other small things. Binary caches, your own Hydra, remote/multi-architecture builds, etc. One time I "configured" my NixOS laptop install before getting my laptop: on a remote testing server, over remote KVM. Pushed it to git. I cloned my configuration.nix during NixOS installation on my laptop a few days later, and I replicated my laptop in 10 minutes. :) Combine this with Hydra (CI) server: You can even write tests and have your laptop configuration continuously integrated all the time?!?!?!? That said NixOS isn't always the easiest thing to use, but it does come with some big advantages! [1] I'm aware of DKMS (and have even worked on modules using it where it was fine) but I've still had it break once or twice. Maybe that was VMWare's fault :) [2] If you share code between all your configuration.nix files, this becomes a lot easier.

nh2 9y ago

To say what my sibling comments say, more briefly: With the nix system you can fully declaratively state your entire fleet of machines, from your highest level application configs all the way down to kernel patches. When you run nixops, your machines become exactly as specified. That this works reliably is a novelty: most other configuration management tools work like "action runners" that try in a best-effort fashion to achieve the desired state, but that doesn't always work (for example in Ansible, declaring a package as installed installs it, but NOT declaring a package will not uninstall it). It is made possible because the nix system is designed from the bottom up to be declarative. That makes it different from Puppet.

majewsky 9y ago
> most other configuration management tools work like "action runners" that try in a best-effort fashion to achieve the desired state, but that doesn't always work (for example in Ansible, declaring a package as installed installs it, but NOT declaring a package will not uninstall it). Most other configuration management tools have no choice. I got my own [1] to the point where it cannot only provision files/users/groups, but also clean them up correctly most of the time. However, since it is not the final authority (the package manager is... or rather, root is), there will always be situations where the entity that needs to be provisioned will be found to be in an entirely unanticipated state. You have basically two ways to solve this conundrum: 1. just throw everything away and start from a clean slate when the configuration changes (aka containers) 2. do configuration management in the package manager and encourage/force root to keep his filthy hands off the system partition (aka NixOS et al) [1] https://github.com/holocm/holo https://github.com/holocm/holo
- jacques_chester 9y ago
  BOSH uses both tactics. It deals in whole VMs, but parks deployed software in a known location that's the same for all stemcells.