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

user_3765739 0
Viewed 1170
  • I'm testing the gRPC using Visual Studio 2019 16.7.2 on Windows 10 64bits, creating the gRPC Server with Net Core 3.1 and template 3.1.8 Greeting Service sample.
  • Also creating the client with Net Core 3.1 with Google.Protobuf 3.13.0, Grpc.Net.Client 2.31.0 and Grpc.Tools 2.31.0
  • It run ok on Linux Container using Docker Desktop for Windows 10 64bits.
  • Then I Deployed the container imagen on Azure Container Register, after I created an Azure Container Instance using the same Linux image, adding ports: 443, 5001 as images shows, but it only listening calls on the port 80.

container Properties contaniner Log

  • The Docker file:
    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

azure-container-instances
2 Answers

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://docs.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
user_37657390

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.

user_97739370
Related