[fivea]

> You can regenerate your base images every day or more often and have consistent containers created from an image.

That solves nothing, as it just moves the unreproducibility to a base image at the cost of extra complexity. Arguably that can even make the problem worse as you just add a delta between updates where there is none if you just run apt get upgrade.

> Freshly generated image can be tested in a pipeline to avoid issues and you won't hit issues like inability to scale due to misbehaving new containers.

You already get that from container images you build after running apt get upgrade.

[hericium]

`apt` runs during the creation of 1-3 VM images per architecture and not during creation of dozens of container images based on each VM image.

When we have VM images upon which all our usual Docker images were successfully built, we trust it more than `FROM busybox/alpine/ubuntu` with following Docker builds. I've detailed the process in a neighboring comment[1] but you're right that it doesn't suit all workflows.

[1] https://news.ycombinator.com/item?id=30810251

[orf]

For AMIs (and other VM images) it might make more sense. With containers? Not so much. And with a distributed socket image caching layer it makes even less sense.