> The current state of containers where the dominant mentality is “shove everything possibly needed into a single image and treat it like a black box” isn’t the

> The current state of containers where the dominant mentality is “shove everything possibly needed into a single image and treat it like a black box” isn’t the best imo. I do something similar for my personal containers. I have a common Ubuntu base image, that I add a bunch of tools to, which I might need for debugging later and install apt updates to as a part of the build process and remove the apt cache (so instead of changing the base image all the time to a more recent one, I still have an up to date container, at the expense of some additional layers). Then, on top of that base image I have other specialized images, ones with Apache, some with JDK, some for .NET, Python, Node, Ruby etc., which I can then build my apps upon, while having a few useful tools in the container, as well as a bunch of shared layers that the nodes will be able to reuse. The only exceptions are images like PostgreSQL, MariaDB, SeaweedFS etc., which I just take from Docker Hub, usually the Bitnami variety: https://bitnami.com/stacks/containers https://bitnami.com/stacks/containers because I almost never need to connect to those or use them as base images, but rather just use them as connected services. Should enterprises do that? Probably not. It is, however, an immensely pleasant approach to things, that lets me not stress about optimization and just use what works for me.