I am using dotnet:2.1-sdk as a package while building docker image.
The RUN dotnet restore command is failing with below errors:
**error : Unable to load the service index for source https://api.nuget.org/v3/index.json.**
**error : A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond**
**The command 'cmd /S /C dotnet restore' returned a non-zero code: 1**
Its an issue with proxy because if I bypass the corporate network and connect to my personal network, it works.
I also tried placing the NuGet.Config file the source directory and also tried to copy it to WORKDIR. Nothing worked.
Please let me know the procedure of setting the "Proxy" for making dotnet restore work in the docker environment.
Thanks.
Check my answer here.
Basically, you should instruct the docker build environment to use the proxy by adding build arguments like:
docker build --build-arg HTTP_PROXY=<proxy URL> --build-arg HTTPS_PROXY=<proxy URL> -t <application name>
Related
Calling dotnet restore <project> from my Dockerfile is resulting in a NU1301: Unable to load the service index for source error. I've been going through many of the suggested similar questions and continue to have issues. Here is as much info about the things I've tried as I can provide:
Docker Engine has its DNS set to "8.8.8.8"
Using Linux containers
RUN ping google.com succeeds (so I can reach the internet)
Works perfectly fine hitting the nuget.org feed
The nuget.config file currently has credentials in it just to get this working
This will be removed for a different approach once I get this working
These are the same credentials (username/PAT) that I use during development on my host machine
RUN curl <nuget_feed_url> succeeds
Running the restore command with --verbosity detailed doesn't provide any other error messages but the one
Here is the section of the Dockerfile in question
FROM mcr.microsoft.com/dotnet/aspnet:6.0.13 AS base
# Create dockeruser in base layer
RUN addgroup --system --gid 1000 dockergroup \
&& adduser --system --uid 1000 --ingroup dockergroup --shell /bin/sh dockeruser
WORKDIR /app
EXPOSE 8080
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
# Arguments are required in each stage in order to get the correct value
WORKDIR /src
COPY ["src/Nucleus.LumberYard.API/", "Nucleus.LumberYard.API/"]
COPY ["./nuget.config", "./nuget.config"]
WORKDIR "/src/Nucleus.LumberYard.API"
#COPY [".editorconfig", "./"]
RUN dotnet restore "Nucleus.LumberYard.API.csproj"
RUN dotnet build "Nucleus.LumberYard.API.csproj" -c Release --no-restore
Environment info
Docker Desktop v3.3.1
Docker v20.10.5
Based on my understanding you have the following scenario:
a .NET 6 application with some references to nuget packages
some nuget packages are taken from the usual Nuget public repository, some others are taken from a private nuget feed
you are distributing your application via a docker image and during the docker build process you want to run a dotnet restore command targeting one of your csproj file
the dotnet restore command fails because the dotnet cli is unable to talk with your private nuget feed
I encountered the very same situation with the project I'm working on. We have a private Nuget feed hosted in Azure Devops and we too had some troubles figuring out how to solve this.
First of all, let's clarify the root cause of the problem.
You did the right thing veryfying that you are able to reach the nuget feed from your build machine, via the curl command you mentioned.
What is actually failing is the authentication between your build machine and the private nuget feed.
The first thing you need is a personal access token with read permissions for your nuget feed. You can follow this guide to create the personal access token you need.
Once you have the token, you need to provide it to the dotnet cli.
There are several ways to do so, I'm going to explain the one that worked for us.
Instead of adding the nuget source to the nuget.config file, we registers it via a cli command.
I'm quite sure there is a way to do exactly the same thing via the nuget.config file (see here for more details).
This is the cli command we use inside of our docker file:
RUN dotnet nuget add source https://foo.bar.com/something/nuget/v3/index.json -u "whatever" -p "my-personal-access-token" --store-password-in-clear-text --valid-authentication-types "basic"
Notice that:
https://foo.bar.com/something/nuget/v3/index.json is the absolute URL pointing to the index of your private nuget feed
the username can be whatever you like. You do need to provide a value, but I didn't notice any difference even putting there a random string like whatever
the fictious value my-personal-access-token must be substituted with the personal access token you have created as a first step
Here you can find the full reference for the dotnet nuget add source command.
After registering this source with the dotnet cli, you will be able to run your dotnet restore command with no errors.
Hope this helps!
Having an ASP.NET Core 2.2 web application, I try to restore NuGet packages behind a coperate proxy
FROM mcr.microsoft.com/dotnet/core/sdk:2.2 AS sdk-image
WORKDIR /app/
ARG HTTP_PROXY
ENV HTTP_PROXY ${HTTP_PROXY}
ENV HTTPS_PROXY ${HTTP_PROXY}
COPY MyProject.csproj .
RUN dotnet restore
with the following docker-compose.yml:
version: '2'
services:
tool:
build:
context: .
args:
http_proxy: ${HTTP_PROXY}
networks:
default:
ipam:
driver: default
config:
- subnet: 192.168.239.0/21
The network got overriden because Dockers default network conflicts with internal company ranges. HTTP_PROXY is set on the host to a full url like http://user:password#proxy.internal:81.
When running docker-compose up --build it fails on restore:
Step 7/15 : RUN dotnet restore
---> Running in 62c8bb6f2f72
/usr/share/dotnet/sdk/2.2.402/NuGet.targets(123,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [/app/MyProject.csproj]
/usr/share/dotnet/sdk/2.2.402/NuGet.targets(123,5): error : GSSAPI operation failed with error - An unsupported mechanism was requested (Unknown error). [/app/MyProject.csproj]
ERROR: Service 'tool' failed to build: The command '/bin/sh -c dotnet restore' returned a non-zero code: 1
I could not find much information about this issue. A Github issue got this through their local TFS. But I don't have any self hosted repository, just the corporate proxy between me and NuGets server.
Seems like this is caused when the proxy requires NTLM, but the corresponding library is missing. I had this problem behind a corporate proxy and fixed it by installing the gss-ntlmssp package like this in Docker:
RUN apt-get install -y gss-ntlmssp
After installing those package, the authentication to the proxy for fetching NuGet packages works well.
I am having problems with my docker build script for a basic Azure Function. I have been following this blog post:
https://medium.com/#adrianromanin/azure-functions-on-a-docker-container-7b00d2c36eb2
At the point of the nuget restore I get the following errors:
Restoring packages for
C:\src\dotnet-function-app\functionsanddockerdemo.csproj... C:\Program
Files\dotnet\sdk\2.1.403\NuGet.targets(114,5): error : Unable to load
the service index for source https://api.nuget.org/v3/index.json.
[C:\src\dotnet-function-app\functionsanddockerdemo.csproj] C:\Program
Files\dotnet\sdk\2.1.403\NuGet.targets(114,5): error : A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond
[C:\src\dotnet-function-app\functionsanddockerdemo.csproj] The command
'cmd /S /C dotnet restore
src/dotnet-function-app/functionsanddockerdemo.csproj -s
https://api.nuget.org/v3/index.json' returned a non-zero code: 1
My docker build script:
FROM microsoft/dotnet:2.1-sdk AS installer-env
COPY . /src/dotnet-function-app
RUN mkdir "home/site/wwwroot/"
RUN dir "C:/src/dotnet-function-app"
RUN dotnet publish src/dotnet-function-app/functionsanddockerdemo.csproj --output /home/site/wwwroot
I've tried explicitly specifiying package restore via both of these commands:
RUN dotnet restore src/dotnet-function-app/functionsanddockerdemo.csproj -s https://api.nuget.org/v#3/index.json
RUN dotnet restore src/dotnet-function-app/functionsanddockerdemo.csproj --verbosity diag
However they both give the same result. I initially thought maybe my container didn't have any network connectivity, however I have connectivty confirming via:
RUN ping www.google.co.uk
My docker info:
Server Version: 18.06.1-ce
Storage Driver: windowsfilter
Windows:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics l2bridge l2tunnel nat null overlay transparent
Log: awslogs etwlogs fluentd gelf json-file logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 17134 (17134.1.amd64fre.rs4_release.180410-1804)
Operating System: Windows 10 Pro Version 1803 (OS Build 17134.285)
I am sure I hav missed something basic here!
1. Background
I'm currently working on the following build/deployment pipeline:
Github (https://github.com/devedse/DeveMazeGeneratorCore)
Travis Build (https://travis-ci.org/devedse/DeveMazeGeneratorCore/jobs/196910720)
dotnet restore
dotnet build
dotnet publish
docker create image
docker publish image to hub
Docker image hub (https://hub.docker.com/r/devedse/devemazegeneratorcore/)
Use Azure Web App on Linux to execute deployment (http://devemazegeneratorcoredocker.azurewebsites.net/api/mazes/MazePath/512/512)
.
2. Problem
Whenever I push something to the Github repository, a build is kicked off and step 1-3 are being executed correctly.
However, the website on Azure is unreachable.
I used SCM to browse to the debug console (https://devemazegeneratorcoredocker.scm.azurewebsites.net/DebugConsole/Default.cshtml (for future reference)) and executed the following commands to find the log files that were generated by Docker:
and then used the following commands to read them:
cat docker_128_err.log
cat docker_128_out.log
The out log showed the following results (which seem correct):
Login Succeeded
latest: Pulling from devedse/devemazegeneratorcore
5040bd298390: Already exists
fce5728aad85: Already exists
76610ec20bf5: Already exists
51ee4768b31d: Already exists
4dc55ff439a1: Already exists
9cb727c7d7a0: Already exists
2bea08464ad0: Pulling fs layer
2bea08464ad0: Verifying Checksum
2bea08464ad0: Download complete
2bea08464ad0: Pull complete
Digest: sha256:647f3db3daa3330b7eb109a1c604e5bd403c2c7089b3c18c5e9249a9805d3a4d
Status: Downloaded newer image for devedse/devemazegeneratorcore:latest
Login Succeeded
latest: Pulling from devedse/devemazegeneratorcore
Digest: sha256:647f3db3daa3330b7eb109a1c604e5bd403c2c7089b3c18c5e9249a9805d3a4d
Status: Image is up to date for devedse/devemazegeneratorcore:latest
The error log however, shows the following errors:
2017-01-31T13:11:46.757760723Z No executable found matching command "dotnet-/home/DeveMazeGeneratorCoreWebPublish/DeveMazeGeneratorWeb.dll"
The strange thing is, is that whenever I run the image locally, it all works fine:
docker run -it --rm -p 0.0.0.0:5001:80 devedse/devemazegeneratorcore:latest
Somehow there seems to be a difference in running a Docker image on a Linux machine in Azure, compared to my local Docker installation which runs the Docker images on the default VM that's being installed when you install Docker for Windows.
3. Configuration files used:
.travis.yml: (https://github.com/devedse/DeveMazeGeneratorCore/blob/master/.travis.yml)
Dockerfile: (https://github.com/devedse/DeveMazeGeneratorCore/blob/master/Scripts/Docker/Dockerfile)
4. Summary
So summarizing, it seems that running Docker on Azure is being executed in a different manner then when doing this locally. Does anyone have an idea on what this could be/how to solve it?
Again, (just for easy reference), the error:
2017-01-31T13:11:46.757760723Z No executable found matching command "dotnet-/home/DeveMazeGeneratorCoreWebPublish/DeveMazeGeneratorWeb.dll"
Modify your image to put your application bits somewhere other than /home.
/home is where Azure App Service on Linux bind-mounts the persistent site volume, which is a disk that is shared across instances and is persisted between restarts.
You don't have to use it (you may not have any use for it when running your own image), but anything in your image's /home will disappear at runtime.
I have a little dotnet core application and want to build it on jenkins.
In order to make it happen, ive installed dotnet core on the build slave.
Locally i can restore with the same command successfuly (even on my mac)
dotnet restore --configfile .nuget/NuGet.Config
On the build server the restore fails for one package.
Started by user jenkins
Building remotely on 2c3bff31e594 in workspace /root/workspace/Test
Cloning the remote Git repository
...
+ dotnet restore --configfile .nuget/NuGet.Config
Welcome to .NET Core!
---------------------
...
log : Installing System.Runtime 4.1.0-rc2-24027.
log : Installing System.Diagnostics.Tools 4.0.1-rc2-24027.
log : Installing System.Reflection.Extensions 4.0.1-rc2-24027.
...
log : Restoring packages for /root/workspace/Test/test/Test.DataAccess.Tests/project.json...
log : Failed to download package from 'https://api.nuget.org/v3-flatcontainer/remotion.linq/2.1.1/remotion.linq.2.1.1.nupkg'.
log : Response status code does not indicate success: 404 (Not Found).
The strange thing here is, that if i hit the url
"https://api.nuget.org/v3-flatcontainer/remotion.linq/2.1.1/remotion.linq.2.1.1.nupkg" link from the log, the package is their.
probably a firewall or any other local setting
probably firewall. id install fiddler on the computer and look what is the exact request
add fiddler as nuget porxy like this:
https://docs.nuget.org/consume/nuget-config-settings#proxy-settings
Proxy settings
section: config
keys: http_proxy, http_proxy.user, http_proxy.password and no_proxy.
Allows you to set the proxy settings to be used while connecting to your NuGet feed. More details here.
This key can be added using NuGet.exe Config -Set command.
It can also be set via environment variables http_proxy and no_proxy. http_proxy should be specified in the format http://[username]:[password]#proxy.com whereas no_proxy should be a comma-separated list of domains to bypass the proxy server.
Note
The "http_proxy.password" key value is encrypted before storing in the nuget.config file. Hence it can not be added manually by directly updating the config file.