[bornfreddy]

> They are the exact equivalent of shipping a developer's laptop off to the datacenter and replicating it as a production image.

I hear that a lot, but it's not really true, or it is true only if developer created the image manually. Does anyone do that?

As soon as you use a Dockerfile you have reproducible builds, allowing you to use a different base image, or even perform the installation without containers at all.

[CamouflagedKiwi]

> As soon as you use a Dockerfile you have reproducible builds

That is extremely optimistic. As soon as you do anything involving an update - `apt-get update` or similar - it's not reproducible any more, and of course you do need to do those things in most images. And if you don't need to do that, you can probably avoid doing the whole Dockerfile thing in the first place (although that may not be so easy if you're not set up for it).

[mrweasel]

> As soon as you use a Dockerfile you have reproducible builds

Depends on how you build your containers. If you have a build step, which pulls your dependencies from a trusted source and versions are locked down, then MAYBE. I've seen developers have all that in place, then in their deployable container they start by doing "apt-get update && apt-get upgrade" in the Dockerfile and install some runtime dependency that way.

There is also another problem, which I believe is what OP is referring to: People will write docker-compose file, Helm charts and what-have-you, which pulls down random images from Docker hub, never to upgrade them, because that breaks something or because: It's a container, it's secure. Fair enough if you pull down the official MariaDB image, or KeyCloak, you still need to upgrade them, and often, but they are mostly trustworthy. But what happens when your service depends on an image created by some dude in Pakistan in 2017 as part of his studies, and it has never been upgraded?

I had this discussion with a large client. They where upset that we didn't patch the OS right when new security updates came out, which to me was pointless when they shipped a container with a pre-release version of Tomcat 8 that was already 18 months out of date and had known security flaws.

[dsr_]

It's not a reproducible build, it's a reproducible deploy. Hopefully.

[bornfreddy]

Thank you, this is a much better term (and I agree with you and siblings, "reproducible build" is in most cases too optimistic).

But I stand by my point - container images are still way more manageable than dev laptop images.

[xorcist]

Dockerfiles makes it really hard to produce reproducible builds. Try it.