use ENV variable in EntryPoint for Distroless image

[ZenwalkerD]

Hi All

I have 2 different applications (web apps) and 1 common Dockerfile through which i am building the apps and containerize it. So far i was using full fledged images (debian); where in i was passing the exe name into the entrypoint as environment variable.

Now i was playing with distroless and its great. It offers lot size reduction. So i was doing the same and hit a road block.
I do not prefer to maintain 2 dockerfiles for 2 apps.

I am unable to pass the environment variable to the entry point vector as shown:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
SHELL ["/bin/bash", "-c"]
ARG csprojFileName
COPY . /home/src
RUN dotnet publish "$csprojFileName.csproj"

FROM mcr.microsoft.com/dotnet/runtime-deps:8.0-noble-chiseled
ARG csprojFileName
ENV CSPROJFILENAME $csprojFileName
EXPOSE 8080
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["./$CSPROJFILENAME"]

i tried changing ENTRYPOINT as ENTRYPOINT ["./${CSPROJFILENAME}"]; but no luck.

Please help; what could be the alternative approach if above is not supported?

[lbussell]

Hi @ZenwalkerD. I tried to use your Dockerfile as-is to build a test project and found a few issues with it:

1. If you use Ubuntu Noble for your final image, you should also use the Noble SDK image - mcr.microsoft.com/dotnet/sdk:8.0-noble.
2. dotnet publish failed because it was in the wrong directory, and publish output was not placed in /app/publish.

The Dockerfile was able to build after changing those things in the first layer:

- FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
+ FROM mcr.microsoft.com/dotnet/sdk:8.0-noble AS build
SHELL ["/bin/bash", "-c"]
ARG csprojFileName
- COPY . /home/src
+ WORKDIR /home/src
+ COPY . .
- RUN dotnet publish "$csprojFileName.csproj"
+ RUN dotnet publish "$csprojFileName.csproj" -o /home/src/app/publish
...

However, using the environment variable in the ENTRYPOINT instruction still won't work, so the Dockerfile won't run. Environment variable expansion is handled by the shell. Since the exec form for ENTRYPOINT instructions doesn't use the shell, this is the expected behavior. Distroless images cannot expand that environment variable at runtime since they don't have a shell - so you'll need to specify the exact executable name in the ENTRYPOINT instruction. You can see moby/moby#4783 for more info. One other option could be to rename the executable to something known in the build stage before it is copied to the final image.

I should note that there's nothing wrong with using separate Dockerfiles for separate apps - in fact I would expect it. As apps are developed over time, requirements and dependencies change, and they may necessitate different Dockerfiles anyways.

Finally, consider taking a look at our Ubuntu Chiseled ASP.NET app sample Dockerfile for inspiration. You can easily upgrade it to Noble by replacing jammy with noble. https://github.com/dotnet/dotnet-docker/blob/main/samples/aspnetapp/Dockerfile.chiseled

[ZenwalkerD]

Thanks for the correction added for the Dockerfile build part. Yes i also figured and changed it locally. But did not update here.

But i was more focused on the ENTRYPOINT problem i was having.

I understand that it does not have a shell; but i wish there was to atleast do very basic stuff.

I note ur point on multiple docker files. For sure ill take that approach as its evident that its the only route i have.

[richlander]

Have you considered using dotnet publish to generate your images? That would skip this whole problem area entirely.

@baronfel

[ZenwalkerD]

I am sorry i do not understand. In the multistage build dockerfile i pasted above; i am doing dotnet publish to build the application. I guess you are referring to visual studio publish docker option???
I prefer dockerfile way of doing things though :)

[richlander]

I am referring to dotnet publish producing an OCI image. See https://devblogs.microsoft.com/dotnet/streamline-container-build-dotnet-8/.

[ZenwalkerD]

Thank you. I learned something new. Very nice to have in build support!