Acabo de actualizar mi aplicación Web API a .NET core 3.0, todo funciona bien cuando se ejecuta en modo de depuración en IIS Express, pero el contexto no responde cuando se ejecuta en el contenedor de la ventana acoplable, ya sea en el servidor o en la depuración de VS. No se lanza ningún error, simplemente nunca responde.

Intenté implementar una imagen actualizada en el servidor, que es donde noté el problema por primera vez. Luego intenté ejecutar como Docker en vs para depurar. Actualicé todos los paquetes NuGet y configuré marcos en .NET Core 3.0 o .NET Standard 2.1. Inspeccioné la cadena de conexión de contexto en la depuración y parece ser correcta. Volví a una imagen anterior usando .NET core 2.2 y todo funcionó como se esperaba usando los mismos parámetros de inicio. Creé un método de prueba que no usa contexto y devuelve valores correctos en el servidor y en la depuración de VS Docker. Intenté cambiar el método para usar una llamada sincrónica al contexto, pero no hubo cambios en el comportamiento. La base de datos de prueba es muy pequeña, solo se consultan 3 registros en la tabla.

    public async Task<List<SendingSystemInfoResponse>> getSendingSystemInfoList()
    {
        try
        {
            return await _context.EmailSendingSystem.Where(m => !m.Deleted && m.Active == true).Select(m => new SendingSystemInfoResponse
            {
                SystemId = m.EmailSendingSystemId,
                SystemName = m.Title,
                SystemDescription = m.Description

            }).ToListAsync();
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, string.Format("EmailDataAccess: Exception retrieving EmailSendingSystem List"));
            throw;
        }
    }

Si hubiera un error al conectarse al servidor SQL, o si la solicitud de SQL se agotó, esperaría encontrar el código del bloque de captura, pero esto nunca sucede.

Aquí está el contenido del archivo de la ventana acoplable, no estoy seguro de si mis objetivos para las imágenes base y de compilación son correctos. Parece que funcionan, pero podrían ser la causa de mi problema.

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build
WORKDIR /src
COPY ["EmailAutomation.API/EmailAutomation.API.csproj", "EmailAutomation.API/"]
COPY ["EmailAutomation.API/NuGet.Config", "/src"]
RUN dotnet restore "EmailAutomation.API/EmailAutomation.API.csproj"
COPY . .
WORKDIR "/src/EmailAutomation.API"
RUN dotnet build "EmailAutomation.API.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "EmailAutomation.API.csproj" -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "EmailAutomation.API.dll"]

------ Actualización ----- Entonces, he estado trabajando en esto de vez en cuando hoy, y tengo un poco más de información que podría ayudar a alguien a señalarme en la dirección correcta. Creé un proyecto de API web de prueba simple con una conexión EF a SQL Server ejecutándose en mi PC local usando .NET core 3.0 y los últimos paquetes NuGet, y habilité las conexiones TCP / IP a SQL Server ejecutándose localmente. Pude hacer que se conectara a la base de datos y devolviera valores.

A continuación, creé una copia de la base de datos de prueba en mi servidor SQL local. Esto también funcionó, la API web en la pregunta original que se ejecutaba en Docker se conectó y devolvió datos. Luego cambié la cadena de conexión para que apunte al SQL Server de prueba y el proceso se cuelga en el mismo lugar sin errores. A continuación, lo probé con la conexión aún apuntando al SQL Server de prueba pero ejecutándose en IIS Express en lugar de Docker. Nuevamente, todo funcionó como se esperaba.

Luego intenté ejecutar la imagen de la ventana acoplable de la versión anterior que usa .NET Core 2.2, y también devolvió datos del SQL Server de prueba.

¿Cuál podría ser la razón por la que no puedo conectarme a través de IP al SQL Server de prueba usando .NET Core 3.0 en Docker cuando todas las demás combinaciones funcionan bien?

------ Actualización 2 ----- Creé la base de datos necesaria para mi nuevo proyecto de API web de prueba simple en Test SQL Server y cambié la cadena de conexión del proyecto de API web simple. Este nuevo, limpio y simple proyecto de .NET Core 3 tampoco se conectó al Test SQL Server cuando se ejecutaba como Docker, pero funcionaba bien cuando se ejecutaba en IIS Express. También funcionó bien cuando se ejecutaba en Docker pero se conectaba a mi base de datos local por IP.

Algo ha cambiado con .NET Core 3 en Docker que impide que se conecte al servidor de base de datos externo. ¿Alguien tiene alguna idea sobre lo que debo hacer para resolver esto?

- ACTUALIZACIÓN 3 ----- ¡Gracias a MATT! Después de leer la respuesta de Matt, no pude hacer que los comandos RUN funcionaran dentro del archivo de la ventana acoplable, pero cambiar mi imagen base a biónica funcionó. También he estado trabajando con el soporte de Microsoft, que también me indicó el enlace que proporcionó Matt. Tal vez simplemente no coloqué los comandos EJECUTAR en la ubicación correcta, por lo que si alguien puede proporcionar un archivo de la ventana acoplable de muestra utilizando los comandos EJECUTAR para resolver este problema, estaría agradecido. Aquí hay un archivo docker actualizado de un proyecto de prueba simple:

    FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-bionic AS base
    WORKDIR /app
    EXPOSE 80

    FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build
    WORKDIR /src
    COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
    RUN dotnet restore "WebApplication1/WebApplication1.csproj"
    COPY . .
    WORKDIR "/src/WebApplication1"
    RUN dotnet build "WebApplication1.csproj" -c Release -o /app/build

    FROM build AS publish
    RUN dotnet publish "WebApplication1.csproj" -c Release -o /app/publish

    FROM base AS final
    WORKDIR /app
    COPY --from=publish /app/publish .
    ENTRYPOINT ["dotnet", "WebApplication1.dll"]

--- Actualización final -----

Probé de nuevo los comandos EJECUTAR en el archivo de la ventana acoplable, pero esta vez lo hice bien. Aquí está esa versión del archivo de la ventana acoplable.

    FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim AS base
    WORKDIR /app
    RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
    RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /usr/lib/ssl/openssl.cnf
    EXPOSE 80

    FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build
    WORKDIR /src
    COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
    RUN dotnet restore "WebApplication1/WebApplication1.csproj"
    COPY . .
    WORKDIR "/src/WebApplication1"
    RUN dotnet build "WebApplication1.csproj" -c Release -o /app/build

    FROM build AS publish
    RUN dotnet publish "WebApplication1.csproj" -c Release -o /app/publish

    FROM base AS final
    WORKDIR /app
    COPY --from=publish /app/publish .
    ENTRYPOINT ["dotnet", "WebApplication1.dll"]
3
David Violett 2 oct. 2019 a las 18:11

1 respuesta

La mejor respuesta

Creo que el problema con el que se encuentra está documentado aquí: https://github.com/dotnet / SqlClient / issues / 222. Como dijiste, algo cambió con .NET Core 3 porque esas imágenes de Docker se basan en Debian Buster de forma predeterminada. Buster está configurado para usar 1.2 como el protocolo TLS mínimo, un cambio con respecto a la versión anterior (ver https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#openssl-defaults) .

Esto se puede solucionar temporalmente agregando lo siguiente al Dockerfile:

RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /usr/lib/ssl/openssl.cnf

Esta no es una gran solución porque esencialmente está degradando la versión de TLS. La mejor solución a largo plazo es habilitar TLS 1.2 en SQL Server (consulte https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server ).

2
Matt Thalman 23 oct. 2019 a las 21:06