4 ms·

> Docker became popular because it allows one to build, publish and then consume containers. True, but Docker is an awful choice for those things (builds are p

> Docker became popular because it allows one to build, publish and then consume containers. True, but Docker is an awful choice for those things (builds are performed "inside out" and aren't reproducible, publishing produces unauditable binary-blobs, consumption bypasses cryptographic security by fetching "latest" tags, etc.)

yjftsjthsd-h 5y ago
It's still superior to everything that came before it (at least, that I'm aware of), and cleared the "good enough" bar. Actually, I'm still not aware of anything that solves those issues without making it way harder to use - ex. nix addresses your points but has an awful learning curve.
tra3 5y ago
Can you expand on how builds aren't reproducible? I though Dockerfile ensured that builds are indeed reproducible?
- Ajedi32 5y ago
  Running the same script every time doesn't necessarily guarantee the same result. Lots of docker build scripts have the equivalent of date > file.txt or curl https://www.random.org/integers/?num=1&min=1&max=1000&col=1&base=10&format=plain&rnd=new > file.txt Buried deep somewhere in the code. But yeah I don't see any reason why you couldn't theoretically make a reproducible build with Docker.
  - tra3 5y ago
    If you have dynamism like this in your build, doesn't that imply that no build system is reproducible?
    - amarshall 5y ago
      Yes, but previous commenter said > I [thought] Dockerfile ensured that builds are indeed reproducible? The example straightforwardly disproves that.
    - Ajedi32 5y ago
      My point was just that Docker doesn't ensure reproducibility. Whether a build is reproducible or not depends on the steps used, so its possible but not "ensured". If you wanted to guarantee reproducibility, a hypothetical purely-functional build system could do that. I personally don't think that's necessary though, or that it would be worth the requisite trade-offs.
  - MD87 5y ago
    Docker images actually contain the timestamp each layer was built at, so are basically de-facto non-reproducible. Buildah from Red Hat has an argument to set this programmatically instead of using the current date, but AFAIK there's no way to do that with plain old docker build.
    - gmfawcett 5y ago
      The nixpkgs workaround is to build images with build-date == 1970-01-01. Annoying but reproducible.
  - mlrhazi 5y ago
    Would that not be cached? It would not actually run that date command again, right? unless you change that date line itself, in the Dockerfile.
    - amarshall 5y ago
      If you’re using a cached version, you haven’t really reproduced anything but the cache itself. Reproducibility means creating the same output given the same input, every time, regardless of some local cache. That said, the above example isn’t specific to Docker.
    - anamexis 5y ago
      Or if you change anything that comes before that line.
zapita 5y ago
> builds are performed "inside out" Docker supports multi-stage builds. They are quite powerful and allow you go beyond the "inside out" model (which still works fine for many use cases). > ...and aren't reproducible You can have reproducible builds with Docker. But Docker does not require your build to be reproducible. This allowed it to be widely adopted, because it meets users where they are. You can switch your imperfect build to Docker now, and gradually improve it over time. This is a pragmatic approach which in the long run improves the state of the art more than a purist approach.
KronisLV 5y ago
> builds are performed "inside out" and aren't reproducible This is probably a good argument because of how hard it is to do anything in a reproducible manner, if you care even about timestamps and such matching up. Yet, i'd like to disagree that it's because of inherent flaws with Docker, merely how most people choose to build their software. Nobody wants to use their own Nexus instance as a storage for a small set of audited dependencies, configure it to be the only source for all of them, build their own base images, seek out alternatives for all of the web integrated build plugins etc. Most people just want to feed the machine a single Dockerfile (or the technology specific equivalent, e.g. pom.xml) and get something that works out and thus the concerns around reproducibility get neglected. Just look at how much effort the folks over at Debian have put into reproducibility: https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds That said, a decent middle ground is to use a package cache for your app dependencies, specific pinned versions of base images (or build your own ones on top of the common ones, e.g. a customized Alpine base image) and multi stage builds, you are probably 80% of the way there, since if need be, you could just dump the image's file system and diff it against a known copy. Nexus (some prefer Artifactory, some other solutions): https://www.sonatype.com/products/repository-oss https://www.sonatype.com/products/repository-oss Multi stage builds: https://docs.docker.com/develop/develop-images/multistage-build/ https://docs.docker.com/develop/develop-images/multistage-bu... The rest 20% might take a decade until reproducibility is as user friendly as Docker currently is, just look at how slowly Nix is adopted. > publishing produces unauditable binary-blobs It's just a file system that consists of a bunch of layers, isn't it? What prevents you from doing: docker run --name dump-test alpine:some-very-specific-version sh -c exit docker export -o alpine.tar dump-test docker rm dump-test You get an archive that's the full file system of the container. Of course, you still need to check everything that's actually inside of it and where it came from (at least the image persists the information about how it was built normally), but to me it definitely seems doable > consumption bypasses cryptographic security by fetching "latest" tags I'm not sure how security is bypassed if the user chooses to use whatever is the latest released version. That just seems like a bad default on Docker's part and a careless action on the user's part. Actually, there's no reason why you should limit yourself to just using tags, since something like "my-image:2022-02-18" might be accidentally overwritten unless your repo specifically prevents this from being allowed. If you want, you can actually run images by their hashes, for example, Harbor makes this easy to do by letting you copy those values from their UI, though you can also do so manually. For example, let's say that we have two Dockerfiles: # testA.Dockerfile FROM alpine:some-very-specific-version RUN mkdir /test && echo "A" > /test/file CMD cat/test/file # testB.Dockerfile FROM alpine:some-very-specific-version RUN mkdir /test && echo "B" > /test/file CMD cat/test/file If we use just tags to refer to the images, we can eventually have them be overriden, which can be problematic: # Example of using version tags, possibly problematic docker build -t test-a -f testA.Dockerfile . docker run --rm test-a docker build -t test-a -f testB.Dockerfile . docker run --rm test-a In the second case we get the "B" output even though the tag is "test-a" because of a typo, user error or something else. Yet, we can also use hashes: # Example of using hashes, more dependable docker build -t test-a -f testA.Dockerfile . docker image inspect test-a | grep "Id" docker run --rm "sha256:93ee9f8e3b373940e04411a370a909b586e2ef882eef937ca4d9e44083cece7c" docker build -t test-a -f testB.Dockerfile . docker image inspect test-a | grep "Id" docker run --rm "sha256:8dd9ba5f1544c327b55cbb75f314cea629cfb6bbfd563fe41f40e742e51348e2" docker build -t test-a -f testA.Dockerfile . docker image inspect test-a | grep "Id" docker run --rm "sha256:93ee9f8e3b373940e04411a370a909b586e2ef882eef937ca4d9e44083cece7c" Here we see that if your underlying build is reproducible, then the resulting image hash for the same container will be stable. Furthermore, someone overwriting the test-a tag didn't break you being able to run the first correctly built image because the tags are just convenience, so you'll be able to run the previous one. Of course, that loops back to the reproducible build discussion if you care about hashes matching up, rather than just tags not being overwritten.

yjftsjthsd-h 5y ago

It's still superior to everything that came before it (at least, that I'm aware of), and cleared the "good enough" bar. Actually, I'm still not aware of anything that solves those issues without making it way harder to use - ex. nix addresses your points but has an awful learning curve.

tra3 5y ago

Can you expand on how builds aren't reproducible? I though Dockerfile ensured that builds are indeed reproducible?

Ajedi32 5y ago
Running the same script every time doesn't necessarily guarantee the same result. Lots of docker build scripts have the equivalent of date > file.txt or curl https://www.random.org/integers/?num=1&min=1&max=1000&col=1&base=10&format=plain&rnd=new > file.txt Buried deep somewhere in the code. But yeah I don't see any reason why you couldn't theoretically make a reproducible build with Docker.
- tra3 5y ago
  If you have dynamism like this in your build, doesn't that imply that no build system is reproducible?
  - amarshall 5y ago
    Yes, but previous commenter said > I [thought] Dockerfile ensured that builds are indeed reproducible? The example straightforwardly disproves that.
  - Ajedi32 5y ago
    My point was just that Docker doesn't ensure reproducibility. Whether a build is reproducible or not depends on the steps used, so its possible but not "ensured". If you wanted to guarantee reproducibility, a hypothetical purely-functional build system could do that. I personally don't think that's necessary though, or that it would be worth the requisite trade-offs.
- MD87 5y ago
  Docker images actually contain the timestamp each layer was built at, so are basically de-facto non-reproducible. Buildah from Red Hat has an argument to set this programmatically instead of using the current date, but AFAIK there's no way to do that with plain old docker build.
  - gmfawcett 5y ago
    The nixpkgs workaround is to build images with build-date == 1970-01-01. Annoying but reproducible.
- mlrhazi 5y ago
  Would that not be cached? It would not actually run that date command again, right? unless you change that date line itself, in the Dockerfile.
  - amarshall 5y ago
    If you’re using a cached version, you haven’t really reproduced anything but the cache itself. Reproducibility means creating the same output given the same input, every time, regardless of some local cache. That said, the above example isn’t specific to Docker.
  - anamexis 5y ago
    Or if you change anything that comes before that line.

zapita 5y ago

> builds are performed "inside out" Docker supports multi-stage builds. They are quite powerful and allow you go beyond the "inside out" model (which still works fine for many use cases). > ...and aren't reproducible You can have reproducible builds with Docker. But Docker does not require your build to be reproducible. This allowed it to be widely adopted, because it meets users where they are. You can switch your imperfect build to Docker now, and gradually improve it over time. This is a pragmatic approach which in the long run improves the state of the art more than a purist approach.

KronisLV 5y ago

> builds are performed "inside out" and aren't reproducible This is probably a good argument because of how hard it is to do anything in a reproducible manner, if you care even about timestamps and such matching up. Yet, i'd like to disagree that it's because of inherent flaws with Docker, merely how most people choose to build their software. Nobody wants to use their own Nexus instance as a storage for a small set of audited dependencies, configure it to be the only source for all of them, build their own base images, seek out alternatives for all of the web integrated build plugins etc. Most people just want to feed the machine a single Dockerfile (or the technology specific equivalent, e.g. pom.xml) and get something that works out and thus the concerns around reproducibility get neglected. Just look at how much effort the folks over at Debian have put into reproducibility: https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds That said, a decent middle ground is to use a package cache for your app dependencies, specific pinned versions of base images (or build your own ones on top of the common ones, e.g. a customized Alpine base image) and multi stage builds, you are probably 80% of the way there, since if need be, you could just dump the image's file system and diff it against a known copy. Nexus (some prefer Artifactory, some other solutions): https://www.sonatype.com/products/repository-oss https://www.sonatype.com/products/repository-oss Multi stage builds: https://docs.docker.com/develop/develop-images/multistage-build/ https://docs.docker.com/develop/develop-images/multistage-bu... The rest 20% might take a decade until reproducibility is as user friendly as Docker currently is, just look at how slowly Nix is adopted. > publishing produces unauditable binary-blobs It's just a file system that consists of a bunch of layers, isn't it? What prevents you from doing: docker run --name dump-test alpine:some-very-specific-version sh -c exit docker export -o alpine.tar dump-test docker rm dump-test You get an archive that's the full file system of the container. Of course, you still need to check everything that's actually inside of it and where it came from (at least the image persists the information about how it was built normally), but to me it definitely seems doable > consumption bypasses cryptographic security by fetching "latest" tags I'm not sure how security is bypassed if the user chooses to use whatever is the latest released version. That just seems like a bad default on Docker's part and a careless action on the user's part. Actually, there's no reason why you should limit yourself to just using tags, since something like "my-image:2022-02-18" might be accidentally overwritten unless your repo specifically prevents this from being allowed. If you want, you can actually run images by their hashes, for example, Harbor makes this easy to do by letting you copy those values from their UI, though you can also do so manually. For example, let's say that we have two Dockerfiles: # testA.Dockerfile FROM alpine:some-very-specific-version RUN mkdir /test && echo "A" > /test/file CMD cat/test/file # testB.Dockerfile FROM alpine:some-very-specific-version RUN mkdir /test && echo "B" > /test/file CMD cat/test/file If we use just tags to refer to the images, we can eventually have them be overriden, which can be problematic: # Example of using version tags, possibly problematic docker build -t test-a -f testA.Dockerfile . docker run --rm test-a docker build -t test-a -f testB.Dockerfile . docker run --rm test-a In the second case we get the "B" output even though the tag is "test-a" because of a typo, user error or something else. Yet, we can also use hashes: # Example of using hashes, more dependable docker build -t test-a -f testA.Dockerfile . docker image inspect test-a | grep "Id" docker run --rm "sha256:93ee9f8e3b373940e04411a370a909b586e2ef882eef937ca4d9e44083cece7c" docker build -t test-a -f testB.Dockerfile . docker image inspect test-a | grep "Id" docker run --rm "sha256:8dd9ba5f1544c327b55cbb75f314cea629cfb6bbfd563fe41f40e742e51348e2" docker build -t test-a -f testA.Dockerfile . docker image inspect test-a | grep "Id" docker run --rm "sha256:93ee9f8e3b373940e04411a370a909b586e2ef882eef937ca4d9e44083cece7c" Here we see that if your underlying build is reproducible, then the resulting image hash for the same container will be stable. Furthermore, someone overwriting the test-a tag didn't break you being able to run the first correctly built image because the tags are just convenience, so you'll be able to run the previous one. Of course, that loops back to the reproducible build discussion if you care about hashes matching up, rather than just tags not being overwritten.