3 ms·

> That was the Docker manifesto. It essentially still is. Unless the Dockerfiles are kept secret, any container can be replicated from the given Dockerfile. B

> That was the Docker manifesto. It essentially still is. Unless the Dockerfiles are kept secret, any container can be replicated from the given Dockerfile. Barring extreme (distro/system/hardware)-level quirks, a Docker container should be able to run anywhere that Linux can.

spott 1y ago
A container can very rarely be reproduced by a dockerfile. I imagine with a lot of discipline (no apt update, no “latest” tag, no internet access) you can make a reproducible docker file…. But it is far from normal.
- taberiand 1y ago
  Well sure, making a 100% reproducible build is hard - but Docker makes it easier, not harder. If 100% reproducible is the goal, what's easier than docker?
  - zelphirkalt 1y ago
    Tools that have been designed with reproducibility in mind. Like Guix. Beware, I am definitely not claiming those are easy to use in general. Just that you can get to reproducibility using them more reliably and maybe easier than with docker.
  - otabdeveloper4 1y ago
    > but Docker makes it easier, not harder Incorrect. Step one of reproducibility is "disable unconstrained downloading from the internet". Docker does the opposite.
    - taberiand 1y ago
      Presumably if your goal is a reproducible build you just wouldn't do any unconstrained downloading in the process of designing the dockerfile and building the image. Making a choice to use a tool poorly for you requirements isn't a problem with the tool.
      - soraminazuki 1y ago
        The claim the parent was addressing was that Docker helps with reproducibility. It doesn't. Docker does nothing at all in this regard. If you want a reproducible Docker image, you're on your own. For example, the most common problem is that many build scripts out in the wild download stuff willy nilly without verifying anything. I've seen NPM package post install scripts do the craziest things. Catching all of that is harder than most would give credit for at first glance, considering that tons of build scripts are written in Turing complete languages. Help from tooling is essential. When you have to fight the tool to achieve reproducibility, not choosing to do so isn't "using a tool poorly." It's simply using the tool as is. Especially when the vast majority of Dockerfiles out there happily run something along the lines of `apt install foo`, again, without verifying anything.
        deleted 1y ago
        [deleted]
        taberiand 1y ago
        Ok, so what tools are less work to create a reproducible build than using docker carefully?
        soraminazuki 1y ago
        The Nix package manager. It forces all inputs to a package be specified precisely. Files either have to come from the build recipe or have its hash verified. Builds are properly sandboxed and can't freely access the network. Dependencies are completely static and no "resolution" ever takes place. The tool catches sources of irreproducibility for you.
  - metabagel 1y ago
    Vagrant creates reproducible VMs. Not quite the same thing of course. https://developer.hashicorp.com/vagrant https://developer.hashicorp.com/vagrant
  - jpgvm 1y ago
    Full reproducibility isn't easy, there is a cost to it. However the payoff is rather significant so if you can temper that cost a bit and make it less inconvenient to achieve then you have a winning solution. I have cooked this up based on Bazel, rules_oci and rules_distroless: https://github.com/josephglanville/images https://github.com/josephglanville/images Specifically this file is a busybox based image with some utilities included from a Debian snapshot: https://github.com/josephglanville/images/blob/master/toolbox/BUILD.bazel https://github.com/josephglanville/images/blob/master/toolbo... More difficult than Dockerfile? Sure. However better in pretty much every way otherwise including actual simplicity.
  - soraminazuki 1y ago
    A Dockerfile is essentially a shell script with access to the outside world. It has unconstrained network access. It can access local hardware and filesystem if instructed to. However, it doesn't verify that whatever stuff it took from the outside remains the same across builds. Docker doesn't care if the same Dockerfile builds Apache httpd in one build and Nginx in another. It literally can't get more irreproducible than that. But mysteriously, people say that Docker is reproducible because, uh, you can download gigabyte-sized binary blobs from the Docker registry. I wonder, what's not reproducible by that metric? Docker images may be portable compared to binaries targeting traditional FHS distros. But it's not reproducible whatsoever.
- angra_mainyu 1y ago
  People rarely mean 100% build reproducibility, but simply within a reasonable limit, Dockerfiles are mostly "run stable" and provide the same OS abstraction and process encapsulation.
manquer 1y ago
You are mixing build time reproduction with run time ones. Docker images (not files) help with the run time consistency . Docker (files) barely scratch the surface of build reproducibility. Most applications depend on the distribution package manager ( apt, apk etc) and language package manager (npm, cargo, etc), both sets of them have various challenges in consistent dependency resolution. In addition build steps might have ordering challenges RPC calls to remote services no longer running and so on. Anyone trying to to build a docker image from 10 years back experiences this problem
- wink 1y ago
  You're right in the absolute form, but I've yet to see a Dockerfile where (with a little thinking and elbow grease) I couldn't "easily" port it or update it, even after years. It's basically the best and easiest "I am documenting how it works now" thing without any arcane "works on my machine" quirks I have yet found. So I'm still agreeing here that it's a very good approximation of this idea. Real reproducability is miles better, but usually cannot be formulated in a ~20 line single file "recipe". (and before anyone mentions Nix.. no, there's so much inherent complexity involved, that doesn't count like "apt-get install docker && docker build ."

spott 1y ago

A container can very rarely be reproduced by a dockerfile. I imagine with a lot of discipline (no apt update, no “latest” tag, no internet access) you can make a reproducible docker file…. But it is far from normal.

taberiand 1y ago
Well sure, making a 100% reproducible build is hard - but Docker makes it easier, not harder. If 100% reproducible is the goal, what's easier than docker?
- zelphirkalt 1y ago
  Tools that have been designed with reproducibility in mind. Like Guix. Beware, I am definitely not claiming those are easy to use in general. Just that you can get to reproducibility using them more reliably and maybe easier than with docker.
- otabdeveloper4 1y ago
  > but Docker makes it easier, not harder Incorrect. Step one of reproducibility is "disable unconstrained downloading from the internet". Docker does the opposite.
  - taberiand 1y ago
    Presumably if your goal is a reproducible build you just wouldn't do any unconstrained downloading in the process of designing the dockerfile and building the image. Making a choice to use a tool poorly for you requirements isn't a problem with the tool.
    - soraminazuki 1y ago
      The claim the parent was addressing was that Docker helps with reproducibility. It doesn't. Docker does nothing at all in this regard. If you want a reproducible Docker image, you're on your own. For example, the most common problem is that many build scripts out in the wild download stuff willy nilly without verifying anything. I've seen NPM package post install scripts do the craziest things. Catching all of that is harder than most would give credit for at first glance, considering that tons of build scripts are written in Turing complete languages. Help from tooling is essential. When you have to fight the tool to achieve reproducibility, not choosing to do so isn't "using a tool poorly." It's simply using the tool as is. Especially when the vast majority of Dockerfiles out there happily run something along the lines of `apt install foo`, again, without verifying anything.
      - deleted 1y ago
        [deleted]
      - taberiand 1y ago
        Ok, so what tools are less work to create a reproducible build than using docker carefully?
        soraminazuki 1y ago
        The Nix package manager. It forces all inputs to a package be specified precisely. Files either have to come from the build recipe or have its hash verified. Builds are properly sandboxed and can't freely access the network. Dependencies are completely static and no "resolution" ever takes place. The tool catches sources of irreproducibility for you.
- metabagel 1y ago
  Vagrant creates reproducible VMs. Not quite the same thing of course. https://developer.hashicorp.com/vagrant https://developer.hashicorp.com/vagrant
- jpgvm 1y ago
  Full reproducibility isn't easy, there is a cost to it. However the payoff is rather significant so if you can temper that cost a bit and make it less inconvenient to achieve then you have a winning solution. I have cooked this up based on Bazel, rules_oci and rules_distroless: https://github.com/josephglanville/images https://github.com/josephglanville/images Specifically this file is a busybox based image with some utilities included from a Debian snapshot: https://github.com/josephglanville/images/blob/master/toolbox/BUILD.bazel https://github.com/josephglanville/images/blob/master/toolbo... More difficult than Dockerfile? Sure. However better in pretty much every way otherwise including actual simplicity.
- soraminazuki 1y ago
  A Dockerfile is essentially a shell script with access to the outside world. It has unconstrained network access. It can access local hardware and filesystem if instructed to. However, it doesn't verify that whatever stuff it took from the outside remains the same across builds. Docker doesn't care if the same Dockerfile builds Apache httpd in one build and Nginx in another. It literally can't get more irreproducible than that. But mysteriously, people say that Docker is reproducible because, uh, you can download gigabyte-sized binary blobs from the Docker registry. I wonder, what's not reproducible by that metric? Docker images may be portable compared to binaries targeting traditional FHS distros. But it's not reproducible whatsoever.
angra_mainyu 1y ago
People rarely mean 100% build reproducibility, but simply within a reasonable limit, Dockerfiles are mostly "run stable" and provide the same OS abstraction and process encapsulation.

manquer 1y ago

You are mixing build time reproduction with run time ones. Docker images (not files) help with the run time consistency . Docker (files) barely scratch the surface of build reproducibility. Most applications depend on the distribution package manager ( apt, apk etc) and language package manager (npm, cargo, etc), both sets of them have various challenges in consistent dependency resolution. In addition build steps might have ordering challenges RPC calls to remote services no longer running and so on. Anyone trying to to build a docker image from 10 years back experiences this problem

wink 1y ago
You're right in the absolute form, but I've yet to see a Dockerfile where (with a little thinking and elbow grease) I couldn't "easily" port it or update it, even after years. It's basically the best and easiest "I am documenting how it works now" thing without any arcane "works on my machine" quirks I have yet found. So I'm still agreeing here that it's a very good approximation of this idea. Real reproducability is miles better, but usually cannot be formulated in a ~20 line single file "recipe". (and before anyone mentions Nix.. no, there's so much inherent complexity involved, that doesn't count like "apt-get install docker && docker build ."