Consider more flexible base image customization

[domsew]

Building container images directly from dotnet is a great feature, which significantly speeds up the devops process and is more convenient due to the lack of the Dockerfile. Sometimes there is a need to install additional packages (e.g. libldap, gpg, curl) which are not available by default. Due to lack of support of the RUN instruction, we have to fall back to the Dockerfile. Of course, workarounds exist, like installing packages in the ContainerAppCommand property, but it has its own limitations, like lack of a caching layer or impossibility of working in air-gaped envs.

The reasonable alternative is to use ContainerBaseImage, which would extend default dotnet images. The drawback here is a two-step build (first build base image from Dockerfile, and then dotnet publish). To automate this step, I propose to extend ContainerBaseImage property in such a way that it could consume local Dockerfile.

<PropertyGroup>
    <ContainerBaseImage>../Dockerfile.base</ContainerBaseImage>
</PropertyGroup>

Alternatively, additional property could be introduced, e.g.:

<PropertyGroup>
    <ContainerBaseDockerfile>
      FROM mcr.microsoft.com/dotnet/runtime:8.0
      RUN apt install curl gpg
    </ContainerBaseDockerfile>
</PropertyGroup>

Ideally, dotnet could pass some --build-arg to the Dockerfile (os, version, family, etc.).

What do you think about this idea?

[baronfel]

This is I think a duplicate of #125 - broadly yes we would like to have some kind of way of saying "use this specific Dockerfile as the build base", but there are more knobs to support (like which mechanism to use to build the image, what platform, etc) that we'd need to think about as well. And especially with the incoming multi-architecture support, what would this look like in that world? Happy to continue the discussion over in that issue, though!