I just created a dummy azure function with default flavor. Here is my Dockerfile default from VS.
FROM mcr.microsoft.com/azure-functions/dotnet:4 AS base
WORKDIR /home/site/wwwroot
EXPOSE 80
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["FunctionApp1/FunctionApp1.csproj", "FunctionApp1/"]
RUN dotnet restore "FunctionApp1/FunctionApp1.csproj"
COPY . .
WORKDIR "/src/FunctionApp1"
RUN dotnet build "FunctionApp1.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "FunctionApp1.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /home/site/wwwroot
COPY --from=publish /app/publish .
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
AzureFunctionsJobHost__Logging__Console__IsEnabled=true
SO I executed these 2 lines of code to create the docker file which works perfectly fine for API project but not for Azure Function project.
docker build -t function1 -f FunctionApp1/Dockerfile .
docker run -it --rm -p 8080:80 --name FunctionApp1_sample function1:latest
It keeps throwing error below
The listener for function 'Function1' was unable to start.
Microsoft.Azure.WebJobs.Host.Listeners.FunctionListenerException: The listener for function 'Function1' was unable to start.
---> System.InvalidOperationException: Could not create BlobContainerClient for ScheduleMonitor
at Microsoft.Azure.WebJobs.Extensions.Timers.StorageScheduleMonitor.get_ContainerClient() in C:\azure-webjobs-sdk-extensions\src\WebJobs.Extensions.Timers.Storage\StorageScheduleMonitor.cs:line 83
at Microsoft.Azure.WebJobs.Extensions.Timers.StorageScheduleMonitor.GetStatusBlobClient(String timerName, Boolean createContainerIfNotExists) in C:\azure-webjobs-sdk-extensions\src\WebJobs.Extensions.Timers.Storage\StorageScheduleMonitor.cs:line 155
at Microsoft.Azure.WebJobs.Extensions.Timers.StorageScheduleMonitor.GetStatusAsync(String timerName) in C:\azure-webjobs-sdk-extensions\src\WebJobs.Extensions.Timers.Storage\StorageScheduleMonitor.cs:line 94
I also have tried to set the following environment variable explicitly in the Docker file and still not working. any Suggestions? Thanks.
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
AzureFunctionsJobHost__Logging__Console__IsEnabled=true \
AzureWebJobsStorage="UseDevelopmentStorage=true" \
FUNCTIONS_WORKER_RUNTIME=dotnet
By following the MS Doc given by #peinearydevelopment, I have built the function app with the docker file and published to docker container and then to Azure Function App. Also, enabled the continuous deployment along with SSH Connection.
docker run --rm -it -p 8080:80 harikr572/azurefunctionsimage:v1.0.0
Docker File:
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS installer-env
# Build requires 3.1 SDK
COPY --from=mcr.microsoft.com/dotnet/core/sdk:3.1 /usr/share/dotnet /usr/share/dotnet
FROM mcr.microsoft.com/azure-functions/dotnet:3.0-appservice
COPY . /src/dotnet-function-app
RUN cd /src/dotnet-function-app && \
mkdir -p /home/site/wwwroot && \
dotnet publish *.csproj --output /home/site/wwwroot
FROM mcr.microsoft.com/azure-functions/dotnet:4
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
AzureFunctionsJobHost__Logging__Console__IsEnabled=true
COPY --from=installer-env ["/home/site/wwwroot", "/home/site/wwwroot"]
Related
I have a docker image with a simple .net core API built in it, it works fine when I push it to heroku, but I am having troubles setting it to run in my localhost to test it locally.
I have this line in my Dockerfile
CMD ASPNETCORE_URLS=http://*:$PORT dotnet test-api.dll
But I can't make it run in "localhost:7050"
I am running the image with the following command
docker run -e PORT=7050 --rm --name api-container test-api
The problem is, it runs fine, but in a strange location, it says Now listening on: http://[::]:80
And I can't access that URL.
Of course, I can just do a simple dotnet run, and test it in the port configured, but I would like to test running a container in my computer, if that makes any sense.
The full Dockerfile is bellow, if it helps
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS base
WORKDIR /app
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY . .
RUN dotnet restore
RUN dotnet build --no-restore -c Release -o /app
FROM build AS publish
RUN dotnet publish --no-restore -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
# Padrão de container ASP.NET
# ENTRYPOINT ["dotnet", "CarterAPI.dll"]
# Opção utilizada pelo Heroku
CMD ASPNETCORE_URLS=http://*:$PORT dotnet testeApi.dll
I am trying to dockerize my .Net API and I cannot seem to get access to it after I create a container with it. I attempt to send a request using postman but I get a "Socket Hang Up" error. I believe this has to do with the ports I am using although I am not sure how to fix it. Below is all the information I could gather.
Dockerfile:
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /app
COPY WebAPI.csproj .
RUN dotnet restore "WebAPI.csproj"
COPY . ./
RUN dotnet publish "WebAPI.csproj" -c Release -o /publish
RUN dotnet build
FROM build AS final
WORKDIR /app
COPY --from=build /publish .
EXPOSE 5000
ENTRYPOINT ["dotnet", "WebAPI.dll"]
Commands:
docker build -t webapi:latest .
docker run -p 5000:5000 webapi:latest
Postman Proxy:
127.0.0.1:5000
P.S I have tried changing the ports in multiple ways, changing proxy settings for postman and nothing seems to work
Microsoft has set the environment variable ASPNETCORE_URLS to http://+:80/ in the aspnet image, which makes your application listen on port 80.
So your run command should map port 80 like this
docker run -p 5000:80 webapi:latest
Then your API will be available on http://localhost:5000/
Note that Swagger is only available when your application runs in Development mode and the Docker environment is not considered development. So by default, Swagger won't be available.
Update: Since I don't have your program source code, I've created the following Dockerfile that runs dotnet new to create a fresh template webapi project.
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
RUN dotnet new webapi -n WebAPI -o .
RUN dotnet publish -c Release -o /publish
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from=build /publish .
CMD ["dotnet", "WebAPI.dll"]
I then run the following commands to build, run and test the container
docker build -t test .
docker run --rm -d -p 5000:80 test
curl http://localhost:5000/WeatherForecast
and I get the expected result from the API.
I have following Dockerfile in my .NET Core 2.2 console application.
FROM mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim AS base
WORKDIR /app
FROM mcr.microsoft.com/dotnet/core/sdk:2.2-stretch AS build
WORKDIR /src
COPY ["TaikunBillerPoller.csproj", ""]
RUN dotnet restore "TaikunBillerPoller.csproj"
COPY . .
WORKDIR "/src/"
RUN dotnet build "TaikunBillerPoller.csproj" -c Release -o /app
FROM build AS publish
RUN dotnet publish "TaikunBillerPoller.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "TaikunBillerPoller.dll"]
My .dockerignore file looks like
**/.dockerignore
**/.env
**/.git
**/.gitignore
**/.vs
**/.vscode
**/*.*proj.user
**/azds.yaml
**/charts
**/bin
**/obj
**/Dockerfile
**/Dockerfile.develop
**/docker-compose.yml
**/docker-compose.*.yml
**/*.dbmdl
**/*.jfm
**/secrets.dev.yaml
**/values.dev.yaml
**/.toolstarget
We are using GitLab and Kaniko for building gitlab-ci.yml file.
This console application takes 7 minutes to build, but another application written in the Go language takes 40 seconds.
How might I reduce the build time for this application?
Your first FROM line is completely unused. Instead change your FROM base line to FROM mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim
This issue may be due to the fact that Kaniko **/someDir .dockerignore patterns are not properly observed. I'm noticing that /obj, /bin, .idea (rider) and .git folders are all being copied.
https://github.com/GoogleContainerTools/kaniko/issues/1396
You are also not using the alpine based sdk and runtime images.
In the dotnet restore command you can use the --no-cache flag because docker layer cacheing will take care of that.
dotnet publish does a build so you can skip calling dotnet build. If you want to perform testing you can call dotnet test then
You are explicitly calling dotnet restore so in all subsequent dotnet commands you can use the --no-restore option.
FROM mcr.microsoft.com/dotnet/core/sdk:2.2-alpine AS base
#Add whatever tools you need to the base image
RUN apk add --update --no-cache git bash curl zip; \
export PATH="$PATH:/root/.dotnet/tools"; \
dotnet tool install --global dotnet-xunit-to-junit --version 1.0.2
FROM base AS restore
WORKDIR /src
COPY ["TaikunBillerPoller.csproj", ""]
RUN dotnet restore --no-cache "TaikunBillerPoller.csproj"
COPY . .
FROM restore as publish
ARG VERSION="0.0.0"
RUN dotnet test "TaikunBillerPoller.csproj" --configuration Release --no-restore
RUN dotnet publish "TaikunBillerPoller.csproj" --output /app --configuration Release --no-restore /p:Version=$VERSION
FROM mcr.microsoft.com/dotnet/core/runtime:2.2-alpine AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "TaikunBillerPoller.dll"]
On a 2015 Mac I have an asp.net microservice that builds, tests, publishes and creates a beanstalk_bundle zip using a normal docker build with the following times:
51s No cache
22s Code change
<1s No code change (pipeline yml change)
Kaniko adds overhead because layer caching is done remotely to some repository (typically).
This time is going to depend a lot on how you have your Kaniko cache and mounted volumes configured. Here is something I use on my local machine for debugging.
#!/bin/bash
# Assuming this is either not an ephemeral machine, or the ephemeral machine
# maps the cache directory to permanent volume.
# We cache images into the local machine
# so that the Kaniko container, which is ephemeral, does not have to pull them each time.
docker run -v $(pwd):/workspace gcr.io/kaniko-project/warmer:latest \
--cache-dir=/workspace/cache \
--image=mcr.microsoft.com/dotnet/core/sdk:2.2-alpine \
--image=mcr.microsoft.com/dotnet/core/aspnet:2.2-alpine
docker run -it --rm \
-v `pwd`:/workspace \
-v `pwd`/kaniko-config.json:/kaniko/.docker/config.json:ro \
-v `pwd`/reports:/reports \
-v `pwd`/beanstalk_bundle:/beanstalk_bundle \
gcr.io/kaniko-project/executor:latest \
--dockerfile "buildTestPublish.Dockerfile" \
--destination "registry.gitlab.com/somePath/theImageName:theVersion" \
--skip-unused-stages \
--cache \
--cache-dir=/workspace/cache \
--verbosity=trace
Recently I've created an aspnetcore-2.2 project from a react template, which, as i noticed, doesn't have docker support out of the box.
So I added dockerfile which was generated by VS'17:
FROM microsoft/dotnet:2.2-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM microsoft/dotnet:2.2-sdk AS build
COPY ["SpaProj.WebUI/SpaProj.WebUI.csproj", "SpaProj.WebUI/"]
COPY ["SpaProj.Application/SpaProj.Application.csproj", "SpaProj.Application/"]
COPY ["SpaProj.Domain/SpaProj.Domain.csproj", "SpaProj.Domain/"]
COPY ["SpaProj.Persistence/SpaProj.Persistence.csproj", "SpaProj.Persistence/"]
RUN dotnet restore "SpaProj.WebUI/SpaProj.WebUI.csproj"
COPY . .
WORKDIR "/src/SpaProj.WebUI"
RUN dotnet build "SpaProj.WebUI.csproj" -c Release -o
FROM build AS publish
RUN dotnet publish "SpaProj.WebUI.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "SpaProj.WebUI.dll"]
As far as my research goes, the latest dotnet images don't have nodejs pre-installed so the outcome was a foregone conclusion:
System.AggregateException: One or more errors occurred. (One or more errors occurred. (Failed to start 'npm'. To resolve this:.
[1] Ensure that 'npm' is installed and can be found in one of the PATH directories.
Current PATH enviroment variable is: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Make sure the executable is in one of those directories, or update your PATH.
[2] See the InnerException for further details of the cause.)) ---> System.AggregateException: One or more errors occurred. (Failed to start 'npm'. To resolve this:.
And so on.
After that, I was browsing web for like two complete days to resolve the issue, and after some research added few lines (which, as i thought, would help me to install/launch nodejs) into my dockerfile:
FROM microsoft/dotnet:2.2-aspnetcore-runtime AS Base
WORKDIR /app
EXPOSE 80 443
FROM microsoft/dotnet:2.2-sdk AS build
# install node and npm
ENV NODE_VERSION 10.16.0
ENV NODE_DOWNLOAD_SHA 2e2cddf805112bd0b5769290bf2d1bc4bdd55ee44327e826fa94c459835a9d9a
ENV NODE_DOWNLOAD_URL https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.gz
RUN wget "$NODE_DOWNLOAD_URL" -O nodejs.tar.gz \
&& echo "$NODE_DOWNLOAD_SHA nodejs.tar.gz" | sha256sum -c - \
&& tar -xzf "nodejs.tar.gz" -C /usr/local --strip-components=1 \
&& rm nodejs.tar.gz \
&& ln -s /usr/local/bin/node /usr/local/bin/nodejs
RUN curl -sL https://deb.nodesource.com/setup_10.x | bash -
RUN apt-get install -y nodejs
# install npm packages first, this is slow so we want to minimise the number of un-cached runs
WORKDIR /src/SpaProj.WebUI/ClientApp/
COPY SpaProj.WebUI/ClientApp/package.json .
COPY SpaProj.WebUI/ClientApp/package-lock.json .
RUN npm install
RUN npm audit fix
# restore dotnet before build to allow it sit to cache
WORKDIR /
COPY ["SpaProj.Application/SpaProj.Application.csproj", "src/SpaProj.Application/"]
COPY ["SpaProj.Domain/SpaProj.Domain.csproj", "src/SpaProj.Domain/"]
COPY ["SpaProj.Persistence/SpaProj.Persistence.csproj", "src/SpaProj.Persistence/"]
COPY ["SpaProj.WebUI/SpaProj.WebUI.csproj", "src/SpaProj.WebUI/"]
RUN dotnet restore src/SpaProj.WebUI/SpaProj.WebUI.csproj
# copy source files and build
COPY . /src
RUN dotnet build /src/SpaProj.WebUI/SpaProj.WebUI.csproj --no-restore -c Release
RUN dotnet publish /src/SpaProj.WebUI/SpaProj.WebUI.csproj --no-restore -c Release -o /app
# Copy compiled app to runtime container
FROM base AS final
COPY --from=build /app .
CMD ["dotnet", "SpaProj.WebUI.dll"]
But it didnt help at all.
I also tried multistage build to gather dependencies from node image like this:
FROM 10.16.1-jessie as node-build
WORKDIR /src
COPY SpaProj.WebUI/ClientApp .
RUN npm install
RUN npm run build
The app was still throwing the same exception.
Did anyone had the same issue? Is there another was to dockerize this kind of app?
My object is to debug the Docker container using vsdbg. This container contains an ASP.NET Core API application.
To do this, I created a Docker image using a Docker file, and then ran the container.
And to start remote debugging, I used the below command:
docker exec -i a05a0439540b "/app/vsdbg"
Then I got the below error message:
OCI runtime exec failed: exec failed: container_linux.go:344: starting
container process caused "exec: "/app/vsdbg": permission denied": unknown
Please find below the Docker file content:
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2-stretch-slim AS base
WORKDIR /app
EXPOSE 80
#EXPOSE 443
#RUN Invoke-WebRequest -OutFile c:\vs_remotetools.exe -Uri
http://download.microsoft.com/download/1/2/2/1225c23d-3599-48c9-a314-f7d631f43241/vs_remotetools.exe;
#RUN &amp; 'c:\rtools_setup_x64.exe' /install /quiet
#RUN & 'c:\vs_remotetools.exe' /install /quiet
EXPOSE 4024
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
unzip \
&& curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l ./vsdbg \
&& rm -rf /var/lib/apt/lists/*
#RUN chmod 700 -R /app/vsdbg
RUN /bin/bash -c 'ls -la; chmod 777 /app/vsdbg; ls -la'
FROM mcr.microsoft.com/dotnet/core/sdk:2.2-stretch AS build
WORKDIR /src
COPY ["testDockerCore.csproj", ""]
RUN dotnet restore "testDockerCore.csproj"
COPY . .
WORKDIR "/src/"
RUN dotnet build "testDockerCore.csproj" -c Release -o /app
FROM build AS publish
RUN dotnet publish "testDockerCore.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "testDockerCore.dll"]
But I am still facing the same error.
Using the below command to start the Docker image:
docker run -it -p 4200:4024 testdockercore:dev
How can I resolve this problem?
I ran into this same issue today - the error message is a little confusing. There are no execute permissions on the /vsdbg directory; instead of "/app/vsdbg" you're launch.json needs to read:
"debuggerPath": "/app/vsdbg/vsdbg",
I have the same issue running chmod 777 -R /root/vsdbg/vsdbg
For me the vsdbg is under the root folder.