I run an ASP.NET Core service in a Docker container on MacOS with Visual Studio.
.NET Core SDK: 2.2.300
Here is the Dockerfile:
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/core/sdk:2.2 AS build
WORKDIR /
COPY src/Services/Service.API/Service.API.csproj src/Services/Service.API/
RUN dotnet restore src/Services/Service.API/Service.API.csproj
COPY . .
WORKDIR /src/Services/Service.API
RUN dotnet build Service.API.csproj -c Release -o /app
FROM build AS publish
RUN dotnet publish Service.API.csproj -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "Service.API.dll"]
Here is how the docker-compose file for the service looks like:
service.api:
build:
context: .
dockerfile: src/Services/Service.API/Dockerfile
environment:
- ASPNETCORE_ENVIRONMENT=Development
- ASPNETCORE_URLS=http://+:80;https://+:443
- ASPNETCORE_HTTPS_PORT=5254
- ASPNETCORE_Kestrel__Certificates__Default__Password=crypticpassword
- ASPNETCORE_Kestrel__Certificates__Default__Path=/https/aspnetapp.pfx
ports:
- "5204:80"
- "5254:443"
volumes:
- ${HOME}/.aspnet/https:/https/
Access API via http://localhost:5204 or https://localhost:5254 via Safari/Chrome/etc.
Site cannot be reached according to browser.
The ports of the running Docker container looks good too:
0.0.0.0:5204->80/tcp, 0.0.0.0:5254->443/tcp
Also in the output in Visual Studio I see following warning:
warn: Microsoft.AspNetCore.Server.Kestrel[0] Unable to bind to https://localhost:5001 on the IPv6 loopback interface: 'Cannot assign requested address'. Microsoft.AspNetCore.Server.Kestrel:Warning: Unable to bind to https://localhost:5001 on the IPv6 loopback interface: 'Cannot assign requested address'. Hosting environment: Development Content root path: /app Now listening on: https://localhost:5001
Why doesn't it take the urls set by the ASPNETCORE_URLS enivronment variable?
docker versionDocker version 18.09.2, build 6247962
docker infoContainers: 31
Running: 29
Paused: 0
Stopped: 2
Images: 46
Server Version: 18.09.2
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
runc version: 09c8266bf2fcf9519a651b04ae54c967b9ab86ec
init version: fec3683
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.125-linuxkit
Operating System: Docker for Mac
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.786GiB
Name: linuxkit-025000000001
ID: OUL7:V6FL:ZLZQ:NHGG:O6U7:YLTY:5F6J:UDZA:AUEN:HT7H:3KYC:Y77T
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 211
Goroutines: 196
System Time: 2019-06-25T00:06:36.6568976Z
EventsListeners: 2
HTTP Proxy: gateway.docker.internal:3128
HTTPS Proxy: gateway.docker.internal:3129
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
@dapalmi - it is difficult to provide much help without seeing your project's source code. Have you walked through the Hosting ASP.NET Core Images with Docker over HTTPS sample? Have you compared how your project is different? That might help pinpoint the issues.
You might have better luck getting a good answer on StackOverflow where the audience is much larger.
Closing at this point as there is no obvious issue with the .NET Core images at this point.
@MichaelSimons It seems like it is an issue with Visual Studio for Mac v8.1 But thanks for checking
@dapalmi I am facing this issue with .NET core 3.1. Were you able to solve the issue?
Read this to fix Database connectivity issue -
https://blog.bajajsumit.com/2020/08/dockerize-dotnet-core-application-with.html
Most helpful comment
@dapalmi I am facing this issue with .NET core 3.1. Were you able to solve the issue?