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!
Related
I'm trying to debug a Linux container that runs a C#/.NET 6.0 console application from Visual Studio 2019 (version 16.11.10).
When I use Debug / Attach to Process... to connect to my running container and attach to my process, I get the error:
Failed to launch debug adapter. Additional information may be available in the output window.
Unable to find debugger script at '/home/dockeruser/.vs-debugger'
For company security purposes, I'm running my container workloads as user dockeruser, but I can reproduce this when I adjust my Dockerfile to run as user root. The error message changes into
Unable to find debugger script at '/root/.vs-debugger'
Output shows
Unable to find debugger script at '/home/dockeruser/.vs-debugger'.
Initialization log:
Determining user folder on remote system...
Checking for existing installation of debugging tools...
Downloading debugger launcher...
Creating debugger installation folder: /home/dockeruser/.vs-debugger
Copying debugger launcher to /home/dockeruser/.vs-debugger/GetVsDbg.sh
Failed: Failed to copy files.
Unable to find debugger script at '/home/dockeruser/.vs-debugger'.
Failed: Unable to find debugger script at '/home/dockeruser/.vs-debugger'.
The program '[1] dotnet' has exited with code -1 (0xffffffff).
I can work around this by docker exec'ing a bash session on my container and running GetDbgVs.sh as detailed in https://stackoverflow.com/a/68950674/17273131, but its a pain to do - it feels like something is misconfigured.
I've already verified that my windows identity is a member of the windows docker-users group.
While not the answer I wanted, I've got a 1-liner shell workaround that I execute on my container when I want to debug attach with VS2019, once I know my <CONTAINER_NAME>. This may be useful to others with this problem.
docker exec -u root <CONTAINER_NAME> sh -c "apt-get update && apt-get install wget -y"; docker exec <CONTAINER_NAME> sh -c "mkdir -p ~/.vs-debugger; wget https://aka.ms/getvsdbgsh -O ~/.vs-debugger/GetVsDbg.sh; chmod a+x ~/.vs-debugger/GetVsDbg.sh"
The first command installs wget as root
The second command downloads GetVsDbg.sh to ~/.vs-debugger
I am referencing this article on Microsoft's documentation:
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-apache?view=aspnetcore-3.1
Has anyone tried to accomplish these steps in Docker container?
I have been at this for a couple of days and I can't get the kestrel-helloapp.service file to start my application automatically when I run the container.
After running the container I am able to manually go into it and start my application with dotnet WebApplication3.dll.
I am under the impression that this should happen automatically after enabling the service file.
The only way I am able to get it to work is by adding this to the Dockerfile:
ENTRYPOINT ["dotnet" ,"WebApplication3.dll"]
But when I do this it causes the Apache server to not start up automatically.
Here is my Dockerfile:
FROM centos:7
# install sudo and dotnet sdk
RUN yum install sudo -y
RUN sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm
RUN yum install epel-release -y
RUN yum install dnf -y
RUN sudo dnf install dotnet-sdk-3.1 -y
# copy app files over
COPY ["./publish/", "/var/www/helloapp/publish/"]
# install apache and enable it
RUN sudo yum -y install httpd mod_ssl
RUN systemctl enable httpd.service
RUN yum install initscripts -y
RUN sudo service httpd configtest
# copy and enable service file
COPY ["./kestrel-helloapp.service", "/etc/systemd/system/"]
RUN sudo systemctl enable kestrel-helloapp.service
# start apache
CMD ["-D", "FOREGROUND"]
ENTRYPOINT ["/usr/sbin/httpd"]
EXPOSE 80
docker run command:
docker run -v "C:\Users\Nick\source\repos\docker-testing\version1\helloapp.conf:/etc/httpd/conf.d/helloapp.conf" -e "ASPNETCORE_URLS=http://+:8080" -p 80:80 -p 8080:8080 -t version1
helloapp.conf file:
<VirtualHost *:*>
RequestHeader set "X-Forwarded-Proto" expr="http"
</VirtualHost>
<VirtualHost *:8080>
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:5000/
ProxyPassReverse / http://127.0.0.1:5000/
ServerName www.example.com
ServerAlias *.example.com
ErrorLog /var/log/httpd/helloapp-error.log
CustomLog /var/log/httpd/helloapp-access.log common
</VirtualHost>
kesterl-helloapp.service file:
[Unit]
Description=Example .NET Web MVC App running on CentOS 7
[Service]
WorkingDirectory=/var/www/helloapp/publish
ExecStart=/usr/local/bin/dotnet /var/www/helloapp/publish/WebApplication3.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=apache
Environment=ASPNETCORE_ENVIRONMENT=Production
[Install]
WantedBy=multi-user.target
I know the configuration is correct because everything works fine when I start the application manually. The service file just seems to be not starting the application on boot.
Any help would be greatly appreciated. Thanks!
I've run into a similar problem (just with an ubuntu base image). The problem that you are likely experiencing is related to the fact that there is one process launched from the docker container on entry point and that is not the system daemon (init, systemd, not sure which one centos is using). As a result, your services are actually not started as you described, because they would be launched on system run level change, by that exact same system daemon.
In my opinion, not launching the system daemon is a good thing as you want to minimize services running inside of your container.
On the other hand, you might actually want multiple services inside of the container. An actual solution to your problem is to write an entry point shell script and launch the services that you want to run in parallel of your main application. In my case, I wanted a customized Jenkins image, which has an entry point of /usr/local/bin/jenkins.sh. You can find this in the Dockerfile of the base image that you are using.
I've replaced the original entry point:
ENTRYPOINT ["/bin/tini", "--", "/usr/local/bin/jenkins.sh"]
with:
ENTRYPOINT ["/bin/tini", "--", "/docker-entrypoint.sh"]
Where the content of /docker-entrypoint.sh is:
#! /bin/bash
/usr/bin/cron & # This is the additional service I wanted in the background
/usr/local/bin/jenkins.sh
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 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>
Windows 10 version 1607
Docker for Windows: Version 17.06.1-ce-win24 (13025)
I'm trying to build a asp .net 4.6 container using the provided docs and its not working.
I'm using this provided dockerfile. I copied it to the root of one of my asp .net solutions.
And the I ran this command:
$ docker build -t aspnet-site --build-arg site_root=/
This is the output
PS> docker build -t aspnet-site . --build-arg 'site_root=/'
Sending build context to Docker daemon 326.1MB
Step 1/6 : FROM microsoft/dotnet-framework:4.6.2
4.6.2: Pulling from microsoft/dotnet-framework
3889bb8d808b: Pull complete
9f5eeabe6154: Pull complete
Digest: sha256:c281f2c09c9446f1896806933013a350f19db8f5a009e633ebd9701c470de35b
Status: Downloaded newer image for microsoft/dotnet-framework:4.6.2
---> be84290c2315
Step 2/6 : SHELL powershell -Command $ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';
---> Running in 1fd036b1b56e
---> 413164f1a97c
Removing intermediate container 1fd036b1b56e
Step 3/6 : RUN Add-WindowsFeature Web-Server; Add-WindowsFeature NET-Framework-45-ASPNET; Add-WindowsFeature Web-Asp-Net45; Remove-Item -Recurse C:\inetpub\wwwroot\*
---> Running in 4b0e5751281b
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Common HTTP Features, Default Documen...
True No Success {ASP.NET 4.6}
True No Success {Application Development, ASP.NET 4.6,...
---> 9afab6bfa836
Removing intermediate container 4b0e5751281b
Step 4/6 : ADD ServiceMonitor.exe /
ADD failed: GetFileAttributesEx \\?\C:\WINDOWS\TEMP\docker-builder455754487\ServiceMonitor.exe: The system cannot find the file specified.
So it does say this in the docs (so I tried commenting out the servicemonitor stuff and it worked):
There is no need to specify an ENTRYPOINT in your Dockerfile since the
microsoft/aspnet base image already includes an entrypoint application
that monitors the status of the IIS World Wide Web Publishing Service
(W3SVC).
Try with this dockerfile instead. It will use the aspnet image:
FROM microsoft/aspnet
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop';"]
EXPOSE 80
RUN Remove-WebSite -Name 'Default Web Site'
RUN New-Website -Name 'YourSiteName' -Port 80 -PhysicalPath 'C:\YourFolderName' -ApplicationPool '.NET v4.5'
ADD "LocalFolderPath" /YourFolderName