Nuget package restore error in Docker Compose build - docker

Question

I am getting nugget restore error while building using docker-compose behind proxy. I have set proxy in docker for windows. Nuget restore works for command line dotnet restore and visual studio debug, but not using docker-compose.
:\Program Files\dotnet\sdk\2.1.104\NuGet.targets(104,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [C:\src\WebApp.sln]
:\Program Files\dotnet\sdk\2.1.104\NuGet.targets(104,5): error : An error occurred while sending the request. [C:\src\WebApp.sln]
:\Program Files\dotnet\sdk\2.1.104\NuGet.targets(104,5): error : A connection with the server could not be established [C:\src\WebApp.sln]
ERROR: Service 'idenityapi' failed to build: The command 'powershell -Command $ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue'; dotnet restore -nowarn:msb3202,nu1503' r
turned a non-zero code: 1

Answer 1

SOLVED:
It turns out to be a networking issue. I am behind a corporate firewall at work that leverages TLS packet inspection to break apart SSL traffic. The build process while debugging runs as "me" on my local machine, however, the release build (docker-compose) actually pulls down a aspnetcore-build docker image, copies your code to the docker container, then runs dotnet restore to get fresh nuget packages for your docker image. These actions can be found in the Docker File in your project. This "dotnet restore" inside the container, runs under a different security context, and therefore was getting hung up. We traced the network traffic which was hard for me to get to because of how docker networking works. Fiddler was not catching the traffic. Using wireshark, we were able to catch it from a device level and see the drop. The reason it continued to fail from my home network was due to the configuration with our hypervisor & networking.
RESOLUTIONS:
Add a firewall rule for https://api.nuget.org/v3/index.json (Preferred)
OR
Build the image from VSTS in the cloud
OR
Build from a different network.
PS4 please post back if you are able to resolve this the same way? Having spent 3 days on this, I'm curious about your status.

Answer 2

When I ran into this issue with dotnet restore adding the corporate cert file fixed the issue. (May or may not be the same in your case?). Before RUN dotnet restore I added to the container's certificate store i.e.
ADD your-proxy-certificate-file.crt /usr/local/share/ca-certificates/your-proxy-certificate-file.crt
RUN update-ca-certificates
In theory, if dotnet restore works on your local machine, there's no reason you shouldn't be able to configure your container to work (without firewall rules or changing network!). You essentially need to configure the container to work behind your proxy with the same setup as your local machine.

Answer 3

You can check network adapter indexes. docker uses last in the list. if it's disconnected - you will not be able to restore packages as image is not able to get to the internet to download ones.
check network interface list:
❯ Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceMetric -Descending
Change index for LAN (ex. move it above Wi-Fi):
❯ Set-NetIPInterface -InterfaceAlias 'Local Area Connection* 1' -InterfaceMetric 100

Answer 4

I had similar problem when corporate SSL interception blocked nuget package restore. The error was slightly different though: "The remote certificate is invalid because of errors in the certificate chain: PartialChain"
The following solution helped me:
Export Windows certificate that is used to connect to SSL proxy in PEM format;
Add following lines to Dockerfile:
COPY ["exported_windows_cert_path_and_name.cer", "/usr/local/share/ca-certificates/cert_name.cer"]
RUN openssl x509 -inform PEM -in '/usr/local/share/ca-certificates/cert_name.cer' -out '/usr/local/share/ca-certificates/cert_name.crt'
RUN update-ca-certificates
It can also be used DER certificate type instead of PEM.

Answer 5

I too am getting this same error now. I've been working on it for 2 days to no avail. I've determined that it doesn't seem to be a network related issue. I can load the same project on my home laptop and it builds. I brought my work laptop home it doesn't build. That points me to my work laptop having something amis.
I had fiddler open, and it never tries to hit the URL. I'm running short on ideas at this point for what to do.
I tried creating another "template" project from a simple API/website... it builds fine... I add Nuget Packages and it suddenly fails.
My error message is exactly the same as PS4's.
Steps to reproduce this are easy.
1) Create a new .NET Core Web Project
2) Enable Docker support (either through new project wizard or Add context menu)
3) Select Release Mode
4) Hit Play/Debug/Go button.
One thing that PS4 and I both share is that both of us have "dotnet sdk 2.1.104"

Answer 6

I tried to change my network connection as well...recreated all the images and containers but it did not work then I tried
--disable-parallel and it worked.
Note: I am using docker-compose command to run all of my microservices and I entered --disable-parallel in my Docker file right after dotnet restore command

Answer 7

I was experiencing the same error during docker builds but mine was due to a bad nexus server that was simply unable to keep up with the number of requests being generated. The solutions listed above of --disable-parallel and <add key='maxHttpRequestsPerSource' value='16' /> do work but they cause the build to be incredibly slow.
The real solution wasn't available until package-source-mapping became available. https://devblogs.microsoft.com/nuget/introducing-package-source-mapping/
This allowed me to direct only the necessary connections to my custom nexus server and the rest to nuget.org which has no problem dealing with the connection count.
This is pulled from the article.
<!-- This is where installed packages will be stored locally. -->
<config>
<add key="globalPackagesFolder" value="globalPackagesFolder" />
</config>
<!-- Define my package sources, nuget.org and contoso.com. -->
<!-- `clear` ensures no additional sources are inherited from another config file. -->
<packageSources>
<clear />
<!-- `key` can be any identifier for your source. -->
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
<add key="contoso.com" value="https://contoso.com/packages/" />
</packageSources>
<!-- Define mappings by adding package ID patterns beneath the target source. -->
<!-- Contoso.* packages will be restored from contoso.com, everything else from nuget.org. -->
<packageSourceMapping>
<!-- key value for <packageSource> should match key values from <packageSources> element -->
<packageSource key="nuget.org">
<package pattern="*" />
</packageSource>
<packageSource key="contoso.com">
<package pattern="Contoso.*" />
</packageSource>
</packageSourceMapping>
Worked for me like a charm! Now i can build at normal build speeds and i don't overload the nexus server that is only hosting 1-2 proprietary packages.