How to add the Shell into Chiseled Image for Troubleshooting

[AbdulShaikh]

Describe the Problem

Currently, we are utilizing standard Docker images for .NET Core and are considering transitioning to chiseled images. In our production environment, there are instances where we may need to get inside the container for troubleshooting purposes. How can we achieve similar capabilities with the distroless image? We are seeking the best approach to address this. Alternatively, is it feasible to incorporate a shell into the distroless image as needed?

Describe the Solution

We could employ separate Dockerfiles, one utilizing the chiseled image and the other the standard image, and adjust the Dockerfile based on the environment variable when troubleshooting is required. However, a drawback of this approach is the lack of consistency in using different images. Our preference is to maintain uniformity by continuing to use the same images rather than switching between different ones.

Additional Context

Current Image: mcr.microsoft.com/dotnet/aspnet:8.0
Move to Image: mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled-extra

[MichaelSimons]

What are the troubleshooting scenarios? Would the dotnet/monitor address any of your scenarios?

It is possible to add Bash on top of the .NET chiseled images. The UX is not great nor is the documentation. This issue tracks improving the documentation. This comment illustrates the pattern that can be used to add additional package.

[AbdulShaikh]

The scenarios could involve verifying/checking the DB connectivity inside the container, ensuring that the domain is correctly resolved related to Docker networking, or checking application logs, among other tasks. Up to this point, we have been comfortably handling these tasks or similar ones.

[akoken]

You cannot shell into the distroless container as it lacks both a shell and a package manager. This aligns with the core principle of distroless images, aimed at minimising the attack surface. They contain only the essential system libraries necessary for running the application.

For troubleshooting purposes, you might consider utilising ephemeral containers, a special container type that runs temporarily within an active pod. This can be achieved through the kubectl debug command. If you use Docker instead of K8s, there is a similar command named docker debug.

If you prefer to continue using regular images, you can install tools during the build stage and then copy them to your final stage:

FROM mcr.microsoft.com/dotnet/sdk:8.0 as build
...
RUN dotnet tool install gcdump --tool-path /tools
...

FROM mcr.microsoft.com/dotnet/aspnet:8.0 as final
...
COPY --from=build /tools . 
...