dotnet / sdk-container-builds

Libraries and build tooling to create container images from .NET projects using MSBuild

Home Page:https://learn.microsoft.com/en-us/dotnet/core/docker/publish-as-container

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Can't use local daemon for caching images

emdagh opened this issue · comments

I have a local image based on mcr.microsoft.com/dotnet/runtime:7.0-alpine that installs postgresql-client. Let's call that mcr.microsoft.com/dotnet/runtime:7.0-alpine-postgresql.

When I select that image as a base image for my .NET container I get:
System.Net.Http.HttpRequestException: Response status code does not indicate success: 404 (Not Found).

This makes sense, only if the DOCKER_REGISTRY for pulling the images isn't set.

Changing the BaseImageName to contoso/runtime:7.0-alpine-postgresql verifies this, as it results in the following error:

System.Net.Http.HttpRequestException: No such host is known. (contoso:443)

@baronfel is there any workaround for using the local daemon instead of pushing intermediate images to the Docker registry before using them?

At the moment, trying to do so fails like this:

C:\Program Files\dotnet\sdk\8.0.101\Containers\build\Microsoft.NET.Build.Containers.targets(117,5): warning CONTAINER2020: FullyQualifiedBaseImageName does not specify a registry and will be pulled from Docke
r Hub. Please prefix the name with the image registry, for example: 'docker.io/<image>'. [C:\Users\MyUser
er\Documents\Development\GitHub\ScreenshotCreator\src\ScreenshotCreator.Api\ScreenshotCreator.Api.csproj]
C:\Program Files\dotnet\sdk\8.0.101\Containers\build\Microsoft.NET.Build.Containers.targets(202,5): error CONTAINER1015: Unable to access the repository 'mu88/screenshotcreator-playwright' at tag 'dev' in the
 registry 'docker.io'. Please confirm that this name and tag are present in the registry. [C:\Users\MyUser\Documents\Development\GitHub\ScreenshotCreator\src\ScreenshotCreator.Api\ScreenshotCreator.Api.csproj]

This is the related csproj:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
    <PlaywrightPlatform>all</PlaywrightPlatform>
    <ContainerBaseImage>mu88/screenshotcreator-playwright:latest</ContainerBaseImage>
  </PropertyGroup>
  <-- left out for brevity -->
</Project>

On the local Docker daemon, the image mu88/screenshotcreator-playwright:latest exists:

REPOSITORY                          TAG       IMAGE ID       CREATED             SIZE
mu88/screenshotcreator-playwright   latest    b9262a3dabdd   2 hours ago         1.7GB

There is no workaround - the tooling doesn't know how to read images from a local source at all. If we added this, we'd also have to think about how/when to pull from a remote source. Even if you have a tag locally, what if there's a more recent one on a remote? Right now users are always kept up-to-date, but we'd lose that assurance if we add this capability. We essentially need to develop a parallel to the Docker CLI's --pull always|missing|never flag, but for our tooling. Then decide on a default (likely always), but allow users like you to set it to missing to enable your use case.

A separate-but-related concern is that the tooling doesn't use a local tool like Docker or Podman as a cache - it has its own cache. So even if you had the image locally in your Docker, unless its in our cache we don't know about it. So we'd need to somehow reconcile what the source of the base image should be at the same time.