4 ms·
Those caring about space usage presumably wouldn't include an entire OS in their containers?
by chriswarbo 4y ago
Those caring about space usage presumably wouldn't include an entire OS in their containers?
- KronisLV 4y agoHmm, it depends - sometimes that's a decent tradeoff for development velocity vs distroless containers (from scratch) outside of particular project requirements, in other cases it can just be nice to have some common packages or even tools in your containers, for debugging/troubleshooting, especially if you don't change the base image too often, so it can also benefit from the caching. As for the (compressed) size of some common base images: SIZE WHAT 3 MB alpine:3.17.1 29 MB ubuntu:jammy-20221130 31 MB debian:stable-20230109-slim 53 MB debian:stable-20230109 32 MB almalinux:9.1-minimal-20221201 66 MB almalinux:9.1-20221201 44 MB rockylinux:9.1.20221221-minimal 61 MB rockylinux:9.1.20221221 In most cases the OS/userland related layers (which will generally be more cut down than a "full" OS install) will be smaller than the runtimes for languages like Java, .NET, Python, Ruby, Node and so on, though things can get interesting with updates (e.g. slower builds if you cut out package cache in any layer where you need to install software, so it doesn't bloat the layer size, if you need more than one install command per container).
- deno 4y agoYou include the Base as a layer rather than bundle it so it’s amortized over several releases. Google has a tool to actually bundle your base and cut it down to the very essentials. This is only a thing with Docker and similar. With something like Flatpak it doesn’t even matter if you bundle because OSTree can deduplicate on file level.