Q: "What does building a a Docker image using Nix give you over creating a regular Dockerfile to build a Docker image?"
A:
* Better abstraction (e.g. the example of a function that produces docker images)
* The Hydra build/CI server obviates the need for paying for (or administering a self hosted) docker registry, and avoids the imperative push and pull model. Because a docker image is just another Nix package, you get distributed building, caching and signing for free.
* Because Nix caches intermediate packages builds, building a Docker image via Nix will likely be faster than letting Docker do it.
* Determinism. With Docker, you're not guaranteed that you'll build the same image across two machines (imagine the state of package repositories changing -- it's trivial to find different versions of packages across two builds of the same Dockerfile). With Nix, you're guaranteed that you have the same determinism that any other Nix package has (e.g. everything builds in a chroot without network access (unless you provide a hash of the result, for e.g. tarball downloads))
---
IMO, NixOS almost subsumes Docker. Where Docker gives you a way to guarantee that the contents of an image will be the same across two machines, it does little to ensure that building that image from a given Dockerfile is a deterministic. One of Docker's neat tricks is using layers to try to save on disk util -- but even then, Nix beats Docker; if you start two different containers using Nix packages, the common packages are shared across both containers, whereas two different Docker images with an uncommon base would not share the common files.
Docker mostly looks like someone set out to answer two questions:
1. How can we work around all of the problems inherent in conventional package management so we can have a smidgen of determinism?
2. How can we have a relatively nice/cohesive UI around launching/inspecting containers and managing networking/bind-mounts?
#1 can be side-stepped entirely with a package manager that doesn't cause all of those problems in the first place (Nix/Guix).
#2 is still quite useful, but would have been better served as layering on top of something like Nix or Guix (not that I really approve of the "wannabe systemd" daemon approach that Docker employs (all while being, ironically, rather difficult to use with systemd: https://lwn.net/Articles/676831/ )).
Copying a comment I left on that blog post:
---
Q: "What does building a a Docker image using Nix give you over creating a regular Dockerfile to build a Docker image?"
A:
* Better abstraction (e.g. the example of a function that produces docker images)
* The Hydra build/CI server obviates the need for paying for (or administering a self hosted) docker registry, and avoids the imperative push and pull model. Because a docker image is just another Nix package, you get distributed building, caching and signing for free.
* Because Nix caches intermediate packages builds, building a Docker image via Nix will likely be faster than letting Docker do it.
* Determinism. With Docker, you're not guaranteed that you'll build the same image across two machines (imagine the state of package repositories changing -- it's trivial to find different versions of packages across two builds of the same Dockerfile). With Nix, you're guaranteed that you have the same determinism that any other Nix package has (e.g. everything builds in a chroot without network access (unless you provide a hash of the result, for e.g. tarball downloads))
---
IMO, NixOS almost subsumes Docker. Where Docker gives you a way to guarantee that the contents of an image will be the same across two machines, it does little to ensure that building that image from a given Dockerfile is a deterministic. One of Docker's neat tricks is using layers to try to save on disk util -- but even then, Nix beats Docker; if you start two different containers using Nix packages, the common packages are shared across both containers, whereas two different Docker images with an uncommon base would not share the common files.
Docker mostly looks like someone set out to answer two questions:
1. How can we work around all of the problems inherent in conventional package management so we can have a smidgen of determinism?
2. How can we have a relatively nice/cohesive UI around launching/inspecting containers and managing networking/bind-mounts?
#1 can be side-stepped entirely with a package manager that doesn't cause all of those problems in the first place (Nix/Guix).
#2 is still quite useful, but would have been better served as layering on top of something like Nix or Guix (not that I really approve of the "wannabe systemd" daemon approach that Docker employs (all while being, ironically, rather difficult to use with systemd: https://lwn.net/Articles/676831/ )).
Edit: grammar