In the interest of seeing new developments in DevOps, I went to a talk at Philly ETE on Nix OS, by Susan Potter, which ended up being quite interesting as it’s outside what I normally work on.
NixOS turns out to be a Linux distribution with specific tooling inspired by functional programming techniques (which out loud sounds confusingly like “*nix”). This includes specialized dependency management and a scripting language. Collectively this offers a number of compelling benefits: you should be able to easily run multiple versions of a particular runtime concurrently, and have repeatable installations (and rollbacks!) that self-document their dependencies. This also prevents side-effects on other users or by your past self on your present and future self.
If you build/install a package, it gets it’s own area on the filesystem with a uniquely named folder, isolated with chroot, which prevents it from having implicit dependencies on things you’ve installed, or environment variables you set and forgot about. It sounded like these use symlinks to manage references between the packages.
As I understand it, the dependency manager does all the downloading as a single step, then does the actual installations, so that the installation gets the benefits of being a non-side effecting process (i.e. you can run it as many times as you want and get the same result, so long as you have disk space).
Depending on the problem space you’re currently in, there are a bunch of different tooling options that offer overlapping functionality to Nix. I find the idea of functional/immutable deployments really compelling, knowing that on my own servers I haven’t done a great job of documenting my own setup. The biggest disadvantage to Nix seems to me to be that it requires you to use a custom OS, which is a pretty high level of buy-in.
As feature examples, the “chroot jail” feature is used by a number of tools (e.g. Docker or Dokku) for isolation. One note – I overheard another attendee mention that a lot of people are using Alpine linux as a minimalist Linux as a basis point for Docker images.
Chef and Puppet make some efforts to get server deployment to be concepts that live outside of individual machines, but in my limited view as an outsider they lack the compelling features of functional programming. Puppet seems to assume you have a lot of servers, although I do like the idea of being able to declare a desired state and have Puppet fix your machines to match that state. Kubernetes is an interesting toolset as well – this seems to also take over all your infrastructure, but in the demos I’ve seen it appears to be something one could actually make use of at a smaller scale.