EF上下文在docker中没有响应

Question

我刚刚将我的 Web API 应用程序升级到 .NET core 3.0，在 IIS Express 中以调试模式运行时一切正常，但在服务器或 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 块代码，但这永远不会发生。

这是 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 返回数据。

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

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

Docker 中的 .NET Core 3 发生了一些变化，阻止了它连接到外部数据库服务器。有人对我需要做些什么来解决这个问题有任何想法吗？

--更新 3 ----- 感谢马特！在阅读了马特的回复后，我无法让 RUN 命令在 docker 文件中工作，但是将我的基本映像更改为仿生确实有效。我也一直在与 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 协议，与之前的版本相比有所变化（请参阅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）。