Запуск do tnet publi sh в Docker контейнере выдает ошибку "Обнаружена несогласованность ld.so"

Question

Я пытаюсь обновить один из моих ASP. NET Core проектов с. NET Core 2.2 до 3.1. В проекте используются Docker и один из образов Microsoft. NET Core 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 не работает?

Answer 1

Есть несколько неправильных вещей, которые привели к этой ошибке.

Во-первых, WORKDIR устанавливается после операции COPY на этапе publi sh. Поскольку порядок важен, операция COPY приводит к копированию всего в образе node:8.9.3 (который является Debian 8) в root изображения publi sh, основанного на dotnet/core/sdk:3.1 (Debian 10). Это приводит к перезаписи вещей, которые обычно не должны перезаписываться при создании Dockerfile приложения.

Установка WORKDIR до выполнение операции COPY сделает назначение COPY относительно этого, а не относительно изображения root. Затем, исправив исходный путь к ссылке, где выходные JS пакеты были расположены на client-build изображении, значительно сократилось то, что нужно было скопировать. При построении простого образа приложения может быть более понятным указывать исходные и целевые папки / файлы в COPY с абсолютными путями, а не использовать относительные символы подстановки, такие как . .

Отдельно, изображение узла используемый здесь был значительно устаревшим (v12.x является LTS на момент написания этой статьи). Несмотря на то, что указанной версии узла было достаточно для запуска npm install и webpack, ошибка в Dockerfile означала, что в конечном образе оказались не только выходные пакеты JS, что является риском. Обновление образа узла до последней версии 8.x или более поздней версии LTS на основе Debian 9 или 10 скрыло проблему, но все же лучше не копировать объекты из одного изображения в другое, если они не требуются. Причина, по которой «обновление с. NET Core 2.2 до. NET Core 3.1», по-видимому, стала причиной этой проблемы, заключается просто в отличии от Debian 8 в старом образе Node и в переходе с Debian 9 на 10 в. NET SDK images.

Дополнительные примеры, относящиеся к Docker изображениям для. NET доступны здесь: https://github.com/dotnet/dotnet-docker/blob/master/samples/README.md