3 ms·

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.

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.