3 ms·

We absolutely can, it's just easier to start from a distro image, install everything you might need, build the software, and call it a job done. Multi stage im

We absolutely can, it's just easier to start from a distro image, install everything you might need, build the software, and call it a job done. Multi stage images into a scratch final stage fix this, but you have to care about the problem first, and many people don't. Software with many unpredictable dependencies also makes it harder (it's a lot harder to make a really thin image if your program is python, for instance, than if it's compiled). Edit: actually reading TFA, it's a really good description of the issue. It focuses on nix, but the problem and difficulties are much more general.

soraminazuki 3y ago
The point is that people start from distro images not because it's easy. Rather, it's because there's no other way with Docker. It doesn't have to be this way with better tools. If you use a tool that has clear view of the dependencies of your software to build your image, "distroless" images would be the default. The pain of multi stage images is a Docker-induced problem, not a fundamental issue with packaging in general.
- dvfjsdhgfv 3y ago
  > The point is that people start from distro images not because it's easy. Rather, it's because there's no other way with Docker. It depends if the process you are going to run is compiled or interpreted. In the latter case you can use multi stage builds, with the former stages building what you need and the final one putting it all together. But it simply makes no sense for cases like Python where it would be terribly inefficient to repeat the same work everybody else is doing hence the FROM python:3.11-slim-bookworm usage.
  - LegibleCrimson 3y ago
    I think you meant "former case" rather than "latter case", but even with compiled programs it can be a little more complex, particularly for a dynamically linked program and especially if your program or libraries use dynamic loading. OpenSSL can do some dynamic loading and depend on environment variables and filesystem artifacts in surprising ways as well. If your program uses any hardcoded paths, it gets more complex as well. I find it pretty easy to write a program to run in a very minimal docker image, but compiling existing software for the same can be quite hard, and legacy libraries and application code make it even harder. For somebody who is just learning to program, they could easily never really learn the right techniques, because the wrong ones really do just work fine for them. Like electron, these things are very wasteful, but they do work pretty reliably.
- nunez 3y ago
  If I'm understanding what you wrote here, that is not true. You can write a Dockerfile that inherits from "scratch," which projects an almost entirely empty overlay volume into the container's root volume. (I think it writes a .dockerenv file still.) From there, you can add a minimal rootfs that provides exactly just the system libraries your app needs to run. This is the crux of the problem and a big part of the argument in this article: many devs don't know which dependencies they need from the system, so they create base images from the biggest Ubuntu base images they can find and then apt-get their way into a working system. This works, but now you have a 3Gi image that has a ton of stuff outside of your apps's core supply chain that introduce risk.
  - soraminazuki 3y ago
    I'm not sure which part you're saying is wrong. Your points seem to reaffirm what I wrote.

soraminazuki 3y ago

The point is that people start from distro images not because it's easy. Rather, it's because there's no other way with Docker. It doesn't have to be this way with better tools. If you use a tool that has clear view of the dependencies of your software to build your image, "distroless" images would be the default. The pain of multi stage images is a Docker-induced problem, not a fundamental issue with packaging in general.

dvfjsdhgfv 3y ago
> The point is that people start from distro images not because it's easy. Rather, it's because there's no other way with Docker. It depends if the process you are going to run is compiled or interpreted. In the latter case you can use multi stage builds, with the former stages building what you need and the final one putting it all together. But it simply makes no sense for cases like Python where it would be terribly inefficient to repeat the same work everybody else is doing hence the FROM python:3.11-slim-bookworm usage.
- LegibleCrimson 3y ago
  I think you meant "former case" rather than "latter case", but even with compiled programs it can be a little more complex, particularly for a dynamically linked program and especially if your program or libraries use dynamic loading. OpenSSL can do some dynamic loading and depend on environment variables and filesystem artifacts in surprising ways as well. If your program uses any hardcoded paths, it gets more complex as well. I find it pretty easy to write a program to run in a very minimal docker image, but compiling existing software for the same can be quite hard, and legacy libraries and application code make it even harder. For somebody who is just learning to program, they could easily never really learn the right techniques, because the wrong ones really do just work fine for them. Like electron, these things are very wasteful, but they do work pretty reliably.
nunez 3y ago
If I'm understanding what you wrote here, that is not true. You can write a Dockerfile that inherits from "scratch," which projects an almost entirely empty overlay volume into the container's root volume. (I think it writes a .dockerenv file still.) From there, you can add a minimal rootfs that provides exactly just the system libraries your app needs to run. This is the crux of the problem and a big part of the argument in this article: many devs don't know which dependencies they need from the system, so they create base images from the biggest Ubuntu base images they can find and then apt-get their way into a working system. This works, but now you have a 3Gi image that has a ton of stuff outside of your apps's core supply chain that introduce risk.
- soraminazuki 3y ago
  I'm not sure which part you're saying is wrong. Your points seem to reaffirm what I wrote.