search

dotnet / sdk-container-builds

Libraries and build tooling to create container images from .NET projects using MSBuild
https://learn.microsoft.com/en-us/dotnet/core/docker/publish-as-container
MIT License
179 stars 38 forks source link

DOCKER_HOST ignored #490

Open Spacefish opened 1 year ago

Spacefish commented 1 year ago

The CI Example in the Blog Post https://hub.docker.com/_/microsoft-dotnet-nightly-sdk/ relies on an ubuntu-latest base image to run the build and uses the actions/setup-dotnet@v2 to setup the .NET SDK. After that the dotnet-sdk starts a local docker daemon to run the build.

On GitLab-CI we typically do this by running one or multiple "service" containers beside the buildstep, which can be reached via network.. In this case the docker:24-dind container (docker in docker).

Typically if you run a normal docker build you would set DOCKER_HOST environment variable to the hostname of the service container and the docker cli binary would talk to that docker daemon..

However the .NET SDK does not seem to care about the DOCKER_HOST environment variable, but tries to start a docker daemon locally nevertheless:

/root/.nuget/packages/microsoft.net.build.containers/7.0.400/build/Microsoft.NET.Build.Containers.targets(201,5): error CONTAINER1012: The local Docker daemon is not available, but pushing to a local Docker daemon was requested. Please start the daemon and try again. [/builds/my/project.csproj]

Would be cool, if the Microsoft.NET.Build.Containers honors the DOCKER_HOST environment variable..

baronfel commented 1 year ago

This error is thrown when docker info --format="{{json .}}" doesn't return anything usable, or does return usable json but that json tells us that the daemon couldn't be reached. We're not explicitly setting or removing any environment variables, so I'd expect that this environment variable would flow through. So I am surprised to see this report! I agree that it's something that we should support, I just don't see a reason why we don't currently.

Spacefish commented 1 year ago

Hm.. i guess this is caused by a previous error which i missed, which tells me about the docker binary not being present (No such file or directory)..

I am running this in the mcr.microsoft.com/dotnet/sdk:7.0 container with a docker:dind-24 container beside it. So the main problem seem to be, that the SDK-Container does not contain the docker client binary.

In order for this to work in my setup, i would probably have to create an container first which contains the .NET SDK (to launch the build) as well as the docker client binary..

Somehow was under the impression that the MSBuild Task which talks to the docker daemon does this directly via the API and does not call the docker-cli binary already present in the system.

It´s not that convinient to use it like that currently, as you either have to have a container with docker and install the .NET SDK into it or have the .NET SDK container and install the docker client into it. In order to just trigger the build which runs in another container anyway.

Maybe package the Docker Client binary as a NuGet Package and use that one during build?

baronfel commented 1 year ago

We do use the Registry HTTP API to manage layers and metadata when pushing to remote registries, if that's what you mean. I can see the point about using the docker socket directly, but as far as I know that's not a documented protocol that we could expect to be stable. Competing tools like Jib also use the binary to mediate access to the DOCKER_HOST, so I feel pretty confident in that decision.

In your case, I'd consider pushing to a registry (which could be an ACR, a GitHub Packages feed, or any number of other OCI-compliant feeds) and then consume it in other tooling.