That’s not entirely true. OverlayFS supports page cache sharing for files in image layers. If your images share the same base image layer, then it should share libc and friends in the page cache.
“Different inode” means a different file entirely, not necessarily its majorminor:inode tuple resolved through bind mounts/overlayFS/whatever. I’m saying that if you have containers using even slightly different base images, you effectively have n copies of libc in memory at once on the same system, which does not happen when you do not use containers.
If you’re running enough images on the same machine to make that a relevant point, you have absolutely no excuse not to provide common base images.
Basically, there are two scenarios here: you’re running some service for others to deploy their images (Azure etc), then you want isolation. Or you’re running your own images, then you should absolutely provide a common base image.
If your applications require different libc versions, then regardless if you used containers or not, you’d have each of them in memory. If they don’t require different versions, then you’re just blaming containers for something the user is responsible for managing. When alpine images are a dozen or so MBs, base image disk size is basically irrelevant in the grand scheme of things, as you probably have much more than that in dependencies/runtimes. Even Debian base images are pretty tiny these days. Depending on the application, you could have just a single binary with no OS files at all. So if you do care about disk and memory space, then you would take advantage of the tools containers give you to optimize for that. Its the users choice on how many resources they want to use, its not the fault of the tooling.
That’s not entirely true. OverlayFS supports page cache sharing for files in image layers. If your images share the same base image layer, then it should share libc and friends in the page cache.
https://docs.docker.com/storage/storagedriver/overlayfs-driver/#overlayfs-and-docker-performance
“Different inode” means a different file entirely, not necessarily its majorminor:inode tuple resolved through bind mounts/overlayFS/whatever. I’m saying that if you have containers using even slightly different base images, you effectively have n copies of libc in memory at once on the same system, which does not happen when you do not use containers.
If you’re running enough images on the same machine to make that a relevant point, you have absolutely no excuse not to provide common base images.
Basically, there are two scenarios here: you’re running some service for others to deploy their images (Azure etc), then you want isolation. Or you’re running your own images, then you should absolutely provide a common base image.
If your applications require different libc versions, then regardless if you used containers or not, you’d have each of them in memory. If they don’t require different versions, then you’re just blaming containers for something the user is responsible for managing. When alpine images are a dozen or so MBs, base image disk size is basically irrelevant in the grand scheme of things, as you probably have much more than that in dependencies/runtimes. Even Debian base images are pretty tiny these days. Depending on the application, you could have just a single binary with no OS files at all. So if you do care about disk and memory space, then you would take advantage of the tools containers give you to optimize for that. Its the users choice on how many resources they want to use, its not the fault of the tooling.