4 ms·

It means that your containers only have what you explicitly put there. There's none of the niceties that the distro's typically include. It means you have to s

It means that your containers only have what you explicitly put there. There's none of the niceties that the distro's typically include. It means you have to stop treating your containers a little less like VM's and start treating them a bit more like OS processes. For instance, you can't get a shell on one unless you bother installing that shell yourself.

metadat 2y ago
How would you install a shell without a package manager? Edit: @mhio That's what I suspected, thank you.
- dralley 2y ago
  I assume the images are pre built based on a manifest provided by the developer. The developer decides whether or not to include a shell and which shell to include.
  - metadat 2y ago
    What are these manifests? I presume you are correct - the images are prebuilt (as typical for docker), but then it's like coreos, what you get is whatever you `docker pull'ed, most likely very basic (by design). Great in cases where the app is a self-contained Go program only requiring libc, but not useful when you need to apt/yum/dnf install anything.
- mhio 2y ago
  You don't. There are tools like `nsenter` to act on the container namespaces. https://manpages.debian.org/bookworm/util-linux/nsenter.1.en.html https://manpages.debian.org/bookworm/util-linux/nsenter.1.en...
  - deleted 2y ago
    [deleted]
idontwantthis 2y ago
Is this that hard to do on your own? You can base from scratch if you want. Then you’d have to add just what you need which I guess could be hard.
- __MatrixMan__ 2y ago
  Probably not, I've never tried it. But I assume you can waste a bit of time puzzling out the few things to include which are actually needed every time, and a distroless image has that pre-puzzled for you. If I wanted to be so specific about what's going into my images I'd probably just build them with nix.
- jpalomaki 2y ago
  I guess the key thing is that they promise the security fixes for 12 years. This is interesting, because in large org you ofren have lot of stuff you just want to keep on running with minimal changes.
- sbarre 2y ago
  I would say a lot of developers don't really know their way around a Linux distro as well as you might think? It's the same logic as frameworks or other building blocks: why leave all these decisions up to individual teams, when everyone should be doing things more or less the same way? If need to do something custom, you'll know what you're doing and you can do that. Otherwise, use good defaults provided by people who know better than you.
bigstrat2003 2y ago
I mean... one certainly could do this. And then as soon as anything breaks with that container, the person trying to fix it will curse the day you were born. People already go way too far with stripping container images, and it's awful for troubleshooting. The last thing we need as an industry is taking that silly trend even bother.
- wmf 2y ago
  If you're going to use minimal container images you definitely need to know how to inject tools into the container.
  - mschuster91 2y ago
    Yeah and it's a true pain. Double that if your container security policy requires running in fully rootless mode (i.e. not just the usual CAP_ALL drop but also container uid != 0), quadruple if you're in a Kubernetes environment, and even more if you can't access the nodes themselves directly (AWS EKS).
  - tremon 2y ago
    I'd say you need to know how to properly instrument your containers so that you'll never need to get inside. If your team is on the level of "we need tools inside the container for troubleshooting", then don't use minimized containers like these.
- jpalomaki 2y ago
  It's about security and reducing the probability of getting CVEs for your running containers. Less software you bundle there, less security issues you will have. And this in turn means less work on maintenance as you don't need to update, test and deploy new versions of images so often.
- bitwize 2y ago
  When the cow gets sick, you shoot it.
  - 2y ago

metadat 2y ago

How would you install a shell without a package manager? Edit: @mhio That's what I suspected, thank you.

dralley 2y ago
I assume the images are pre built based on a manifest provided by the developer. The developer decides whether or not to include a shell and which shell to include.
- metadat 2y ago
  What are these manifests? I presume you are correct - the images are prebuilt (as typical for docker), but then it's like coreos, what you get is whatever you `docker pull'ed, most likely very basic (by design). Great in cases where the app is a self-contained Go program only requiring libc, but not useful when you need to apt/yum/dnf install anything.
mhio 2y ago
You don't. There are tools like `nsenter` to act on the container namespaces. https://manpages.debian.org/bookworm/util-linux/nsenter.1.en.html https://manpages.debian.org/bookworm/util-linux/nsenter.1.en...
- deleted 2y ago
  [deleted]

idontwantthis 2y ago

Is this that hard to do on your own? You can base from scratch if you want. Then you’d have to add just what you need which I guess could be hard.

__MatrixMan__ 2y ago
Probably not, I've never tried it. But I assume you can waste a bit of time puzzling out the few things to include which are actually needed every time, and a distroless image has that pre-puzzled for you. If I wanted to be so specific about what's going into my images I'd probably just build them with nix.
jpalomaki 2y ago
I guess the key thing is that they promise the security fixes for 12 years. This is interesting, because in large org you ofren have lot of stuff you just want to keep on running with minimal changes.
sbarre 2y ago
I would say a lot of developers don't really know their way around a Linux distro as well as you might think? It's the same logic as frameworks or other building blocks: why leave all these decisions up to individual teams, when everyone should be doing things more or less the same way? If need to do something custom, you'll know what you're doing and you can do that. Otherwise, use good defaults provided by people who know better than you.

bigstrat2003 2y ago

I mean... one certainly could do this. And then as soon as anything breaks with that container, the person trying to fix it will curse the day you were born. People already go way too far with stripping container images, and it's awful for troubleshooting. The last thing we need as an industry is taking that silly trend even bother.

wmf 2y ago
If you're going to use minimal container images you definitely need to know how to inject tools into the container.
- mschuster91 2y ago
  Yeah and it's a true pain. Double that if your container security policy requires running in fully rootless mode (i.e. not just the usual CAP_ALL drop but also container uid != 0), quadruple if you're in a Kubernetes environment, and even more if you can't access the nodes themselves directly (AWS EKS).
- tremon 2y ago
  I'd say you need to know how to properly instrument your containers so that you'll never need to get inside. If your team is on the level of "we need tools inside the container for troubleshooting", then don't use minimized containers like these.
jpalomaki 2y ago
It's about security and reducing the probability of getting CVEs for your running containers. Less software you bundle there, less security issues you will have. And this in turn means less work on maintenance as you don't need to update, test and deploy new versions of images so often.
bitwize 2y ago
When the cow gets sick, you shoot it.
- 2y ago