4 ms·
The OP is talking about reproducible builds. A docker image is a build artifact. If I gave you a Dockerfile for a node.js service that installed its dependenci
by zomglings 5y ago
The OP is talking about reproducible builds. A docker image is a build artifact.
If I gave you a Dockerfile for a node.js service that installed its dependencies using npm, and the service used non-trivial dependencies, and I gave you this file 10 years after it was first written, chances are you would not be able to build a new image using that Dockerfile.
This would be a problem for you if you had to make some small change to that node.js service (without changing any dependencies).
- Art9681 5y agoThere are other container build tools such as Kaniko that have solved the reproducible builds issue right? If we're operating at scale, it probably means we are using some flavor of Kubernetes and the Docker runtime is no longer relevant. Would Redhat OpenShift's source-to-image (S2I) build process solve the reproducible builds requirement? This space moves quickly and the assumptions we had last week may no longer be relevant. For example Crunchy Postgres offers an enterprise supported Kubernetes Operator that leverages stateful sets. Yet I am reading in these comments that it is an unsolved issue.
- Thaxll 5y agoDocker is also used to build things not just run them, multistage build with dependency vendoring, you have a 100% reproducible build. It's very easy to do in Go. You pin the version used to build your app ( the runtime version ) In your git repo you have dependcies That's it.