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

------更新----- 因此，我一直在不停地进行这项工作，并且有更多信息可能会帮助某人向正确的方向指出。我创建了一个简单的测试Web API项目，它使用.NET Core 3.0和最新的NuGet包与运行在本地PC上的SQL Server建立了EF连接，并启用了到本地运行的SQL Server的TCP / IP连接。我能够使它连接到数据库并返回值。

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

然后我尝试运行使用.NET Core 2.2的早期发行版docker映像，并且它还从测试SQL Server返回了数据。

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

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

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

-更新3 ----- 感谢MATT！阅读了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协议，这是对先前版本的更改（请参见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）。

EF上下文在Docker中没有响应

1 个答案: