4 ms·

"Downloading a pre-built image from a registry does not count as reproducibility, to me." Completely disagree... On my team, the lead devs build the docker ima

"Downloading a pre-built image from a registry does not count as reproducibility, to me." Completely disagree... On my team, the lead devs build the docker images, push them to a private repo, and everyone else pulls that exact image. Bringing up dev environments is almost instant. If a lead dev adds a dependency that breaks the build, everyone else is fine. They will fix the build and push it up when ready.

giobox 9y ago
I'd agree with zackify here too, unless I'm misunderstanding what was meant by "reproducibility". How is this different from say, pulling an external dependency from a repo manager, like we do all the time when building software? The ability to easily deploy pre-built Docker images from a registry is one of my favorite features of a Docker workflow, especially the time that can be saved when deploying components of a software stack to a local development environment. I find I have to deal with significantly less installation issues if the developer can just run a Docker Compose file or similar on their machine to get going.
- muxator 9y ago
  You are right, giobox: pulling an external dependency without guaranteeing its content impairs reproducibility (given that anyone else in this world uses this word in the same meaning I am. At this point I am starting to think that I am wrong). Let me give a short example, limiting to the Dockerfile format: RUN wget https://somehost/something.tar.gz is not reproducible: there is no guarantee that everyone is going to end up with the same container contents. RUN wget https://somehost/something.tar.gz && echo "123456 something.tar.gz" | md5sum -c is reproducible, even if there is an external dependency. You can rest assured that the RUN statement either will convey the same result everyone else is having, or an error. Similar considerations can be made for other statements (FROM something:latest, RUN apt install something, ...). But, as I was saying, maybe my personal opinion of what is "reproducible" is a bit too strict. I agree that using a registry & compose is very useful (and personally, do it all the time). Simply, that does not fit to the definition of reproducibility, for me.
  - deleted 9y ago
    [deleted]
muxator 9y ago
I think we are using two different meaning of "reproducible". To me, saying that a build is reproducible means that anyone is able to independently build a bit-for-bit exact copy of an artifact given only its description (source code + build scripts, Dockerfile, ...), more or less in the sense of [0]. For this definition, even content-addressability is not enough. [0] https://reproducible-builds.org/ https://reproducible-builds.org/
- yebyen 9y ago
  Well, I think you disagree on the meaning of the word "artifact." GP cares that all production deployments are identical to the development environment that went through system tests. To ops, a reproducible build is one that has been uploaded to the registry, because it can be ported over to the production cluster and it will be bit-for-bit identical. It is not necessary to reproduce the same build bit-for-bit because you have kept a copy and distributed it. You are not rebuilding the same thing twice because that is an inefficient use of resources. Nobody really cares that the timestamps are different when the builds started at different times of day, it is evident therefore that you will not produce bit-for-bit identical builds as long as your filesystem includes these kinds of metadata and details. If you built it again, it is to make a change, so there is no point in insisting on bit-for-bit reproducibility in your build process (unless you are actually trying to optimize for immutable infrastructure, in which case more power to you, and it might be a particularly desirable trait to have. Not for nothing!)
  - nqzero 9y ago
    that's a mirror, not a reproducible build
    - yebyen 9y ago
      No, you're right, I read the "reproducible builds" page and it's a good formal definition for the term. I just think that if you ask ten average devops people on the street what "reproducible" means in the context of their devops jobs, eight of them at minimum are not going to know this definition, or insist on a bit-for-bit representation that arises directly from pure source code like what meets the definition at http://reproducible-builds.org http://reproducible-builds.org We're going to think you mean "has a BDR plan in place." Or maybe I've underestimated the reach of this concept.
infinity0 9y ago
It's not reproducible because you didn't produce (i.e. build) anything, you just downloaded (i.e. copied) it. Calling what you did "reproducible" would be like calling a scientific paper "reproducible" because you're able to copy the table of results at the end into another paper.

giobox 9y ago

I'd agree with zackify here too, unless I'm misunderstanding what was meant by "reproducibility". How is this different from say, pulling an external dependency from a repo manager, like we do all the time when building software? The ability to easily deploy pre-built Docker images from a registry is one of my favorite features of a Docker workflow, especially the time that can be saved when deploying components of a software stack to a local development environment. I find I have to deal with significantly less installation issues if the developer can just run a Docker Compose file or similar on their machine to get going.

muxator 9y ago
You are right, giobox: pulling an external dependency without guaranteeing its content impairs reproducibility (given that anyone else in this world uses this word in the same meaning I am. At this point I am starting to think that I am wrong). Let me give a short example, limiting to the Dockerfile format: RUN wget https://somehost/something.tar.gz is not reproducible: there is no guarantee that everyone is going to end up with the same container contents. RUN wget https://somehost/something.tar.gz && echo "123456 something.tar.gz" | md5sum -c is reproducible, even if there is an external dependency. You can rest assured that the RUN statement either will convey the same result everyone else is having, or an error. Similar considerations can be made for other statements (FROM something:latest, RUN apt install something, ...). But, as I was saying, maybe my personal opinion of what is "reproducible" is a bit too strict. I agree that using a registry & compose is very useful (and personally, do it all the time). Simply, that does not fit to the definition of reproducibility, for me.
- deleted 9y ago
  [deleted]

muxator 9y ago

I think we are using two different meaning of "reproducible". To me, saying that a build is reproducible means that anyone is able to independently build a bit-for-bit exact copy of an artifact given only its description (source code + build scripts, Dockerfile, ...), more or less in the sense of [0]. For this definition, even content-addressability is not enough. [0] https://reproducible-builds.org/ https://reproducible-builds.org/

yebyen 9y ago
Well, I think you disagree on the meaning of the word "artifact." GP cares that all production deployments are identical to the development environment that went through system tests. To ops, a reproducible build is one that has been uploaded to the registry, because it can be ported over to the production cluster and it will be bit-for-bit identical. It is not necessary to reproduce the same build bit-for-bit because you have kept a copy and distributed it. You are not rebuilding the same thing twice because that is an inefficient use of resources. Nobody really cares that the timestamps are different when the builds started at different times of day, it is evident therefore that you will not produce bit-for-bit identical builds as long as your filesystem includes these kinds of metadata and details. If you built it again, it is to make a change, so there is no point in insisting on bit-for-bit reproducibility in your build process (unless you are actually trying to optimize for immutable infrastructure, in which case more power to you, and it might be a particularly desirable trait to have. Not for nothing!)
- nqzero 9y ago
  that's a mirror, not a reproducible build
  - yebyen 9y ago
    No, you're right, I read the "reproducible builds" page and it's a good formal definition for the term. I just think that if you ask ten average devops people on the street what "reproducible" means in the context of their devops jobs, eight of them at minimum are not going to know this definition, or insist on a bit-for-bit representation that arises directly from pure source code like what meets the definition at http://reproducible-builds.org http://reproducible-builds.org We're going to think you mean "has a BDR plan in place." Or maybe I've underestimated the reach of this concept.

infinity0 9y ago

It's not reproducible because you didn't produce (i.e. build) anything, you just downloaded (i.e. copied) it. Calling what you did "reproducible" would be like calling a scientific paper "reproducible" because you're able to copy the table of results at the end into another paper.