在Docker容器中运行dotnet发布时出现“ld.so检测到不一致”错误
我正在尝试将我的一个ASP.NET核心项目从.NET核心2.2升级到3.1。该项目使用Docker和一个微软.NET核心Docker镜像来构建.NET应用程序，并使用Node.JS镜像来构建JavaScript。现在我已经将构建基容器从mcr.microsoft.com/dotnet/core/sdk:2.2切换到mcr.microsoft.com/dotnet/core/sdk:3.1，在容器中运行带有任何参数的dotnet publish将返回以下错误：
Inconsistency detected by ld.so: dl-open.c: 689: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!
Service 'web' failed to build: The command '/bin/sh -c dotnet publish -c Release -o out' returned a non-zero code: 127我的Dockerfile看起来像这样：
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build-env
COPY ./src /app/src
FROM node:8.9.3 AS client-build
# do some npm install / node_modules stuff
FROM build-env as publish
COPY --from=client-build . .
WORKDIR /app/src/
RUN dotnet publish -c Release -o out为什么dotnet publish会失败？
回答 1
Stack Overflow用户
发布于 2020-02-26 10:10:43
这里有几个错误导致了这个错误。
首先，在发布步骤中的COPY操作之后设置WORKDIR。因为顺序很重要，所以COPY操作会将node:8.9.3镜像(即debian8)中的所有内容复制到基于dotnet/core/sdk:3.1 (Debian10)的发布镜像的根目录中。这会导致在构建应用程序的Dockerfile时通常不应覆盖的内容被覆盖。
在执行COPY操作之前设置WORKDIR将使COPY的目标相对于它，而不是相对于图像根。然后，将源路径固定为引用client-build映像上输出的JS包所在的位置，大大减少了需要复制的内容。在构建简单的应用程序映像时，最清楚的做法可能是使用绝对路径将源和目标文件夹/文件明确地COPY到COPY，而不是使用相对通配符(如. .
另外，这里使用的节点映像已经明显过时(在撰写本文时，v12.x是LTS )。尽管指定的节点版本足以运行npm install和webpack，Dockerfile文件中的错误意味着不仅仅是输出的JS包在最终图像中结束，这是一个风险。将节点镜像更新到最新的8.x版本，或者基于Debian 9或10的更新的LTS版本隐藏了这个问题，但如果不需要的话，最好不要将内容从一个镜像复制到另一个镜像。“从DebianCore2.2升级到.NET Core3.1”出现这个问题的原因仅仅是在旧的.NET镜像中与Debian8的不同，以及在.NET .NET镜像中从Debian9到10的跳跃。
此处提供了与.NET的Docker镜像相关的其他示例：https://github.com/dotnet/dotnet-docker/blob/master/samples/README.md
https://stackoverflow.com/questions/60405796
复制相似问题
腾讯云开发者
