4 ms·

This isn’t too far from how most containers are built nowadays. Usually you just use Alpine or slim Debian images. The benefit of using those distro images is t

This isn’t too far from how most containers are built nowadays. Usually you just use Alpine or slim Debian images. The benefit of using those distro images is that they provide a lot of utilities you might want in a container, like a shell. As an aside, the approach you described is how Nix works, and you can use Nix to produce OCI images.

iso1631 3y ago
> The benefit of using those distro images is that they provide a lot of utilities you might want in a container, like a shell. Why would you want a shell in a container? Surely the idea of a container is to run a program, not act as interactive environment.
- kroolik 3y ago
  Troubleshooting inside the container or simple scripting.
- rolisz 3y ago
  To debug stuff.
- leodag 3y ago
  It's not necessarily interactive, it's also pretty common to have a shell script for initialization/setup.
- the-alchemist 3y ago
  Like others have said, for debugging, although the proper-but-rarely-done solution is to use PID namespaces to attach another container containing the shell, rather than including it in the raw Docker image.
- giobox 3y ago
  "docker exec -it" debugging/troubleshooting. It's generally harder to debug/troubleshoot random issues if there is no shell in the container, and you can get a working shell in a 10mb container image so not like it adds some dramatic inconvenience or size. Sure its not 100 percent necessary, but it's enormously convenient at times and I personally wouldn't build my own container images without a shell I can drop into usually, unless there are technical or security reasons to avoid doing it for the given application. The shell can also be useful for certain scripting steps during image build, not all containers are just going to copy in a statically compiled binary etc. In fact, I'd say the latter is significantly rarer than the former, at least in my experience. Being able to do commands like: $ docker exec -it mycontainer sh is generally very helpful during development. > https://docs.docker.com/engine/reference/commandline/exec/ https://docs.docker.com/engine/reference/commandline/exec/
- tracker1 3y ago
  Depends on the application. If it's a single, stand-alone application meant to run in a bare container, sure. But many applications are more complicated, or have been shimmed into a container, but generally run on a given Linux system. Diagnostics and debugging inside the running container kind of requires some level of shell and interactivity. Alpine and Debian-slim images usually have enough for this purpose. If you can navigate the file system and list files at the very least, you can exfiltrate data as needed relatively easily though.

iso1631 3y ago

> The benefit of using those distro images is that they provide a lot of utilities you might want in a container, like a shell. Why would you want a shell in a container? Surely the idea of a container is to run a program, not act as interactive environment.

kroolik 3y ago
Troubleshooting inside the container or simple scripting.
rolisz 3y ago
To debug stuff.
leodag 3y ago
It's not necessarily interactive, it's also pretty common to have a shell script for initialization/setup.
the-alchemist 3y ago
Like others have said, for debugging, although the proper-but-rarely-done solution is to use PID namespaces to attach another container containing the shell, rather than including it in the raw Docker image.
giobox 3y ago
"docker exec -it" debugging/troubleshooting. It's generally harder to debug/troubleshoot random issues if there is no shell in the container, and you can get a working shell in a 10mb container image so not like it adds some dramatic inconvenience or size. Sure its not 100 percent necessary, but it's enormously convenient at times and I personally wouldn't build my own container images without a shell I can drop into usually, unless there are technical or security reasons to avoid doing it for the given application. The shell can also be useful for certain scripting steps during image build, not all containers are just going to copy in a statically compiled binary etc. In fact, I'd say the latter is significantly rarer than the former, at least in my experience. Being able to do commands like: $ docker exec -it mycontainer sh is generally very helpful during development. > https://docs.docker.com/engine/reference/commandline/exec/ https://docs.docker.com/engine/reference/commandline/exec/
tracker1 3y ago
Depends on the application. If it's a single, stand-alone application meant to run in a bare container, sure. But many applications are more complicated, or have been shimmed into a container, but generally run on a given Linux system. Diagnostics and debugging inside the running container kind of requires some level of shell and interactivity. Alpine and Debian-slim images usually have enough for this purpose. If you can navigate the file system and list files at the very least, you can exfiltrate data as needed relatively easily though.