NixOps: Declarative Provisioning and Deployment

• It is declarative. There is no difference between doing a new deployment or doing an
  upgrade of an existing deployment. The resulting machine configurations will be the
  same, allowing deployments to be upgraded or reproduced reliably.

• There are several prominent configuration management systems with declarative models,
  such as Cfengine, Puppet and Chef. However, the systems they manage still have
  underlying imperative configuration models, such as configuration files in /etc
  that are updated in place by deployment actions. Thus the result of a deployment may
  still depend on the previous configuration of the system.

• It performs provisioning. For instance, if we instantiate an Amazon EC2 machine
  as part of a larger deployment, it may be necessary to put the IP address or host
  name of that machine in a configuration file on another machine, and to ensure that
  any changes are propagated properly.

• It allows abstracting over the target environment. The same specification can be
  deployed to different cloud backends.

• NixOps ensures that machines can talk to each other, e.g. by creating tunnels
  between machines in different EC2 regions.

• With NixOps, the same toolchain supports both development and production use.
  By contrast, Vagrant provisions VirtualBox virtual machines to set up test
  environments which can then be configured by tools such as Chef. To deploy to e.g.
  EC2, other tools are required.

• It uses a single configuration formalism (Nix’s purely functional language) for
  package management and system configuration management. This makes it very easy to add
  ad hoc packages to a deployment.

• The functional approach is less suited to automatically finding optimal solutions
  to sets of constraints (e.g. to find a deployment that satisfies a feature model).

• NixOps tracks the state of deployments in a SQLite database.

Ref: Charon: Declarative Provisioning and Deployment

NixOS

NixOps deploys NixOS machines, so we start with a brief overview of NixOS’ configuration
model. In NixOS, machines are configured by providing a file (typically
/etc/nixos/configuration.nix) that specifies the desired configuration of the system.
For instance, the following file specifies that we want a machine that runs the
Apache web server:

    { services.httpd.enable = true;
      services.httpd.documentRoot = "/data";
    }

Configuration changes are realised by running the command nixos-rebuild, which
evaluates the system configuration, builds all dependencies, and finally starts,
restarts or stops any new, changed or removed system services in the new configuration.

For instance, if the previous configuration had services.httpd.enable = false, then
running nixos-rebuild will cause Apache httpd to be built or downloaded (if it wasn’t
already present in the system), an httpd.conf configuration file to be generated, and
finally httpd to be started.

In NixOS, all system services are started and monitored using the systemd program
(ref: https://nixos.org/nixos/manual/index.html#sec-systemctl). You can ask for detailed
status information about a unit, for instance, the PostgreSQL database service:

$ systemctl status postgresql.service

More resources:

• A cheat sheet and rough mapping between Ubuntu and NixOS
• NixOS Wiki

Nix

NixOS builds on Nix, a purely functional package manager. NixOS uses Nix to build
packages and other static system configuration artifacts such as configuration files in
a reproducible way. The file configuration.nix is essentially a parameter to a Nix
function that evaluates to a large dependency graph of packages, configuration files and
boot scripts in the Nix store, together constituting the system.

Nix stores these artifacts in the filesystem in locations such as
/nix/store/wjbcr40b...-apache-httpd-2.2.23/, where wjbcr40b... is a cryptographic
hash of the dependencies of the artifact.
As a result when upgrading the old system configuration is never overwritten, allowing
efficient rollbacks and nearly atomic upgrades. This is super helpful when we
accidentally crash our system.

Here is a nice tour of Nix where you can get more
familiar with Nix.

More resources:

• Nix Pills:
  • Chapter 4. The Basics of the Language
  • Chapter 5. Functions and Imports