6 ms·

I mean, that's exactly what a Dockerfile is for. I don't know of anyone seriously using Docker that isn't using Dockerfiles exclusively. I only know of a single

I mean, that's exactly what a Dockerfile is for. I don't know of anyone seriously using Docker that isn't using Dockerfiles exclusively. I only know of a single time when it's valuable to "commit" a new image (recovering logs from a stopped container). None of which is to detract from Nix. Nix+Docker is a powerful combination. It takes Docker's declarative nature all the way down to the compiler used to build the bits placed in the container.

hso1 10y ago
There's a post on building Docker images with Nix: https://news.ycombinator.com/item?id=11502989 https://news.ycombinator.com/item?id=11502989
OJFord 10y ago
I sort of agree, but I also think there's no reason to view Docker commits any differently to Git commits. Are you screwed if you lose a working .git project, or its maintainer? Well, yeah. But we don't actively worry about that happening all that much because we routinely take precautions like distributing it across developer's machines and servers. Maybe a commit does break, but that's why we didn't just overwrite the previous image. But also: > I only know of a single time when it's valuable to > "commit" a new image (recovering logs from a stopped > container) Not everything's open source.
- colemickens 10y ago
  It doesn't have anything to do with a commit breaking anything. It has to do with reproducability. As others have mentioned, a Dockerfile isn't perfect (I'd argue Dockerfile+Nix is pretty close) but at least you don't have to ask "Oh god, what did OJ Ford run manually before commiting the image we use in Prod." That's truly horrific and simply isn't a problem if you use a Dockerfile. >Not everything's open source. I don't know what that means. Whether the source is closed or not has zero impact on the use-cases I'm discussing for Docker. Even if the source of the base layer isn't available, it doesn't stop you from using that base layer in a new Dockerfile, at all.
benley 10y ago
The big difference is that nothing about Dockerfiles implies that the processes they perform to build an image are deterministic or repeatable. Will a build step that runs `curl https://github.com/something/whatever` https://github.com/something/whatever` do the same thing in six months that it does today? Docker doesn't help with that at all. Nix improves determinism by (almost) guaranteeing that if you build the same nix expression six months from now, you'll get exactly the same dependencies, all the way down to glibc. Either that or the build will just fail, if remote dependencies aren't downloadable anymore, which is always tons of fun.
- pacala 10y ago
  In practice, one can check the Dockerfile lineage of a given Docker image and assess the quality of the commands. Good practices are to use package managers with explicit versions, for example "apt-get install subversion-tools=1.3.2-5~bpo1". Or, if you so desire, just pipe NixOS outputs into Docker, as somebody else in this thread mentioned.
- thejosh 10y ago
  YES. Finally someone understands what really annoys me when I say that docker isn't 100% reproducible if you aren't using version pinning or something similar. If you have 2 developers, and one of them does a build the next day, you could have them with two different versions of a package when the version went up.
  - koverstreet 10y ago
    That isn't even the bad part - the bad part is that give some big complicated docker image (or any build in general!), you really have no practical way of knowing what's different. That should scare people.
  - mgkimsal 10y ago
    sounds like 'emerge hell' from gentoo 12 years ago.
    - 10y ago
cstrahan 10y ago
As another use points out, there was some relevant discussion earlier on HN about using Nix+Docker: https://news.ycombinator.com/item?id=11502989 https://news.ycombinator.com/item?id=11502989 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/ https://lwn.net/Articles/676831/ )). Edit: grammar
zenlikethat 10y ago
Tangential, but if you want to recover logs from a stopped container, why not use 'docker cp'?
zwischenzug 10y ago
There's a little company called 'RedHat'... https://github.com/openshift/source-to-image https://github.com/openshift/source-to-image

hso1 10y ago

There's a post on building Docker images with Nix: https://news.ycombinator.com/item?id=11502989 https://news.ycombinator.com/item?id=11502989

OJFord 10y ago

I sort of agree, but I also think there's no reason to view Docker commits any differently to Git commits. Are you screwed if you lose a working .git project, or its maintainer? Well, yeah. But we don't actively worry about that happening all that much because we routinely take precautions like distributing it across developer's machines and servers. Maybe a commit does break, but that's why we didn't just overwrite the previous image. But also: > I only know of a single time when it's valuable to > "commit" a new image (recovering logs from a stopped > container) Not everything's open source.

colemickens 10y ago
It doesn't have anything to do with a commit breaking anything. It has to do with reproducability. As others have mentioned, a Dockerfile isn't perfect (I'd argue Dockerfile+Nix is pretty close) but at least you don't have to ask "Oh god, what did OJ Ford run manually before commiting the image we use in Prod." That's truly horrific and simply isn't a problem if you use a Dockerfile. >Not everything's open source. I don't know what that means. Whether the source is closed or not has zero impact on the use-cases I'm discussing for Docker. Even if the source of the base layer isn't available, it doesn't stop you from using that base layer in a new Dockerfile, at all.

benley 10y ago

The big difference is that nothing about Dockerfiles implies that the processes they perform to build an image are deterministic or repeatable. Will a build step that runs `curl https://github.com/something/whatever` https://github.com/something/whatever` do the same thing in six months that it does today? Docker doesn't help with that at all. Nix improves determinism by (almost) guaranteeing that if you build the same nix expression six months from now, you'll get exactly the same dependencies, all the way down to glibc. Either that or the build will just fail, if remote dependencies aren't downloadable anymore, which is always tons of fun.

pacala 10y ago
In practice, one can check the Dockerfile lineage of a given Docker image and assess the quality of the commands. Good practices are to use package managers with explicit versions, for example "apt-get install subversion-tools=1.3.2-5~bpo1". Or, if you so desire, just pipe NixOS outputs into Docker, as somebody else in this thread mentioned.
thejosh 10y ago
YES. Finally someone understands what really annoys me when I say that docker isn't 100% reproducible if you aren't using version pinning or something similar. If you have 2 developers, and one of them does a build the next day, you could have them with two different versions of a package when the version went up.
- koverstreet 10y ago
  That isn't even the bad part - the bad part is that give some big complicated docker image (or any build in general!), you really have no practical way of knowing what's different. That should scare people.
- mgkimsal 10y ago
  sounds like 'emerge hell' from gentoo 12 years ago.
  - 10y ago

cstrahan 10y ago

As another use points out, there was some relevant discussion earlier on HN about using Nix+Docker: https://news.ycombinator.com/item?id=11502989 https://news.ycombinator.com/item?id=11502989 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/ https://lwn.net/Articles/676831/ )). Edit: grammar

zenlikethat 10y ago

Tangential, but if you want to recover logs from a stopped container, why not use 'docker cp'?

zwischenzug 10y ago

There's a little company called 'RedHat'... https://github.com/openshift/source-to-image https://github.com/openshift/source-to-image