Open emdagh opened 12 months ago
@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.
I have a local image based on
mcr.microsoft.com/dotnet/runtime:7.0-alpine
that installs postgresql-client. Let's call thatmcr.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
tocontoso/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)