NuGet restore failing in Docker Container
I was tempted to write about this before, but I didn’t as there is already a very good, highly rated stack overflow answer with the solution. However, I’m just reinstalling Docker desktop and getting things working again and I wish I had written this stuff down as I’ve forgotten it. One of the many reasons to write blog posts is to fix stuff in my memory and as my own personal development notes. So in that spirit…
We have a very simple .Net Core MVC solution.
It has the following NuGet packages
Install-Package NugetSample.NugetDemo.Demo -Version 1.0.0 Install-Package bootstrap -Version 4.5.0
With this DockerFile to containerise it
FROM mcr.microsoft.com/dotnet/core/aspnet AS base WORKDIR /app EXPOSE 80 EXPOSE 443 FROM mcr.microsoft.com/dotnet/core/sdk WORKDIR /src COPY ["Template.Web.csproj", "Template.Web/"] RUN dotnet restore "Template.Web/Template.Web.csproj" COPY . . WORKDIR "/src/Template.Web" RUN dotnet build "Template.Web.csproj" -c Release -o /app FROM build AS publish RUN dotnet publish "Template.Web.csproj" -c Release -o /app FROM base AS final WORKDIR /app COPY --from=publish /app . ENTRYPOINT ["dotnet", "Template.Web.dll"]
We go to the directory with the DockerFile and try to build it into a container with
docker build .
It fails on the dotnet restore step like so …
i.e. with this error
C:\Program Files\dotnet\sdk\3.1.302\NuGet.targets(128,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [C:\src\Template.Web\Template.Web.csproj] C:\Program Files\dotnet\sdk\3.1.302\NuGet.targets(128,5): error : No such host is known. [C:\src\Template.Web\Template.Web.csproj] The command 'cmd /S /C dotnet restore "Template.Web/Template.Web.csproj"' returned a non-zero code: 1
NuGet is failing us
The container doesn’t have connectivity to the internet so can’t get bring down the packages. We can see this clearly by building this very very simple docker file
FROM mcr.microsoft.com/dotnet/core/sdk RUN ping google.com
The ping fails. The host (my development machine) does have internet access – I would have noticed if that had gone down and I would be hysterically ringing Telstra (again). So it’s something specific to the container.
The DNS server is wrong in the container. To fix, hardcode the DNS into Docker i.e. put this JSON
"dns": ["10.1.2.3", "184.108.40.206"]
into the Docker daemon settings. In Docker Desktop it’s here
And restart the docker service. The container now has internet access, NuGet restore will work and we can now containerise our very simple web application.
As ever, the demo code is on my GitHub site
The very simple application
and its docker file
Docker file for the internet test
This Stack Overflow answer has the resolution to this with a very good explanation. Also it has other (probably better) ways to fix this and resolutions to other Docker network issues that you may face.
Awesome resolution. How did you get to this resolution?
I have the same issue,It is failing at nuget restore command with non zero error code.
tried pinging google.com it doesn’t work though server has internet access and tried to build sample dockerfile which you mentioned it is failed.
I’ve contacted infra team and told that i am not able to ping google.com but server has internet connectivity.. then they allowed ICMP echo and reply rules and sample build is working now but actual build for my project is not working.
i tried to change docker engine dns as you said as a last option but i am not able to change.
Same docker file and same application code is built in other server and it is perfect working.
I am not sure what is missed in the new server.
Could you please help.
There are alternatives to hardcoding the DNS in the docker daemon here – https://stackoverflow.com/a/45644890 and here https://stackoverflow.com/a/20431030. I would work through all those. Hardcoding the DNS was the quickest resolution for me – but that said I have complete control over my development environment. It seems like you don’t (as may people don’t).
Also risking the obvious – perhaps restarting the docker daemon might kick it into life.
You are a saviour!!! Thanks man. Loving the community.
Thank you very much.. you Rock!!
This helped! Thank you!
Thanks man saved my time…great work .. keep it up
Thank you very much, working properly now.
Thanks a lot. Finally got the solution after wasting a lot of time.