CODEWITHSUNDEEP
azure-container-instances
user3765739
user3765739

Reputation: 66

Net Core 3.1 gRPC Server on Azure Container Instance only listening port 80

container Properties contaniner Log

    FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
    WORKDIR /app
    EXPOSE 80
    EXPOSE 443
    EXPOSE 5001
    
    FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
    WORKDIR /src
    COPY ["GrpcService/GrpcService.csproj", "GrpcService/"]
    RUN dotnet restore "GrpcService/GrpcService.csproj"
    COPY . .
    WORKDIR "/src/GrpcService"
    RUN dotnet build "GrpcService.csproj" -c Release -o /app/build
    
    FROM build AS publish
    RUN dotnet publish "GrpcService.csproj" -c Release -o /app/publish
    
    FROM base AS final
    WORKDIR /app
    COPY --from=publish /app/publish .
    ENTRYPOINT ["dotnet", "GrpcService.dll"]

The Azure Container Status

Upvotes: 2

Views: 1358

Answers (2)

user3765739
user3765739

Reputation: 66

As I have read VS uses a Developer Certificate to enable SSL on localhost, this is the reason why on Docker Desktop ports are opened; but when the Docker image is built for deployment the ASP base image is merged with the gRPC server, since there is no Certificate only port 80 is opened

The solution is to use a Reverse Proxy: https://learn.microsoft.com/en-us/azure/container-instances/container-instances-container-group-ssl

Based on the Nginx gRPC support: https://www.nginx.com/blog/nginx-1-13-10-grpc/ some tweaks are need on the nginx.conf file

server {
    listen [::]:5001 ssl http2;
    listen 5001 ssl http2;

    server_name localhost;

    ssl_protocols              TLSv1.2;

    ssl_ciphers     ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;
    ssl_prefer_server_ciphers  on;

    ssl_session_cache    shared:SSL:10m; 
    ssl_session_timeout  24h;

    keepalive_timeout 300; 

    add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains';

    ssl_certificate      /etc/nginx/ssl.crt;
    ssl_certificate_key  /etc/nginx/ssl.key;

    location / {
        grpc_pass grpc://localhost:80;
    }
}

Also adding an DNS Label on the Deploy YAML is useful, since the ip address may change on container images updates

ipAddress:
dnsNameLabel: mydnslabel
ports:
- port: 5001
  protocol: TCP
type: Public

Upvotes: 1

Charles Xu
Charles Xu

Reputation: 31434

First, all the images should test in your local machine and work well as you expect. Then you can deploy them in Azure.

The second, the logs just show about port 80, because in default, port 80 is used to access from the browser and the logs are set by yourself. It does not mean the application cannot listen to other ports. You need to check the listening ports inside the container instance.

And the third, the Container Instance does not support the port mapping. So you need to expose the ports exposed in the Dockerfile, and the ports should be listened by your application as you set.

Upvotes: 0

Related Questions