c# - EF 上下文在 docker 中没有响应

Question

我刚刚将我的 Web API 应用程序升级到 .NET core 3.0，在 IIS Express 中以 Debug模式运行时一切正常，但在服务器上或 VS 调试中的 docker 容器中运行时上下文没有响应。没有抛出错误，只是从不响应。

我尝试将更新的镜像部署到服务器，这是我第一次注意到该问题的地方。然后我尝试在 vs 中以 docker 身份运行来调试。 我已更新所有 NuGet 包并将框架设置为 .NET Core 3.0 或 .NET Standard 2.1。 我已经检查了调试中的上下文连接字符串，它似乎是正确的。我使用 .NET core 2.2 回滚到早期的镜像，并且使用相同的启动参数按预期工作。 我创建了一个不使用上下文的测试方法，它在服务器和 VS docker 调试中返回正确的值。 我尝试更改方法以使用同步调用上下文，但行为没有变化。 测试数据库很小，只查询表中的3条记录。

    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;
        }
    }

如果连接到 SQL Server 时出现错误，或者 SQL 请求超时，我会期望命中 catch block 代码，但这种情况永远不会发生。

这是 docker 文件的内容，我不确定我的基本和构建镜像的目标是否正确。它们似乎有效，但可能是我的问题的原因。

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"]

------更新----- 所以，我今天一直在断断续续地研究这个问题，并获得了更多信息，可能会帮助有人为我指明正确的方向。 我使用 .NET core 3.0 和最新的 NuGet 包创建了一个简单的测试 Web API 项目，其中包含与本地 PC 上运行的 SQL Server 的 EF 连接，并启用了与本地运行的 SQL Server 的 TCP/IP 连接。我能够让它连接到数据库并返回值。

接下来，我在本地 SQL Server 上创建了测试数据库的副本。这也起作用了，在 Docker 中运行的原始问题中的 Web API 连接并返回了数据。 然后，我更改了连接字符串以指向测试 SQL Server，并且该进程卡在同一位置，没有错误。 接下来，我测试了它，连接仍然指向测试 SQL Server，但在 IIS Express 而不是 Docker 中运行。再次，一切都按预期进行。

然后，我尝试运行使用 .NET Core 2.2 的先前版本的 docker 镜像，它还从测试 SQL Server 返回了数据。

当所有其他组合都工作正常时，我无法使用 Docker 中的 .NET Core 3.0 通过 IP 连接到测试 SQL Server，这可能是什么原因。

------更新2----- 我在测试 SQL Server 上为新的简单测试 Web API 项目创建了必要的数据库，并更改了简单 Web API 项目连接字符串。这个新的、干净、简单的 .NET Core 3 项目在作为 Docker 运行时也没有连接到测试 SQL Server，但在 IIS Express 上运行时工作正常。当在 Docker 中运行但通过 IP 连接到我的本地数据库时，它也工作得很好。

Docker 中的 .NET Core 3 发生了一些变化，导致其无法连接到外部数据库服务器。有人知道我需要做什么来解决这个问题吗？

--更新3----- 感谢马特!阅读 Matt 的回复后，我无法让 RUN 命令在 docker 文件中工作，但将我的基本镜像更改为 Bionic 确实有效。我还一直在与 Microsoft 支持人员合作，他们也向我指出了 Matt 提供的链接。 也许我只是没有将 RUN 命令放在正确的位置，所以如果有人可以提供使用 RUN 命令解决此问题的示例 docker 文件，我将不胜感激。 以下是来自简单测试项目的更新后的 docker 文件:

    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"]

---最终更新-----

我再次尝试了 docker 文件中的 RUN 命令，但这次正确了。这是该版本的 docker 文件。

    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"]

Answer 1

我相信您遇到的问题已记录在此处:https://github.com/dotnet/SqlClient/issues/222 。正如您所说，.NET Core 3 确实发生了一些变化，因为这些 Docker 镜像默认基于 Debian Buster。 Buster 配置为使用 1.2 作为最低 TLS 协议(protocol)，这是对先前版本的更改(请参阅 https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#openssl-defaults)。

可以通过将以下内容添加到 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

这不是一个很好的解决方案，因为它本质上是降级 TLS 的版本。更好的长期解决方案是在 SQL Server 上启用 TLS 1.2(请参阅 https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server)。