Блог

Главная - Вопросы по программированию - сбой сборки dotnet внутри контейнера

сбой сборки dotnet внутри контейнера

#.net #.net-core #containers #rhel #dotnet-build

Вопрос:

Я столкнулся с действительно раздражающей проблемой при попытке выполнить сборки dotnet в контейнере для стандартного потока CI/CD. Проблемы, похоже, возникают «случайным образом» (в среднем около 4/10 сборок выходят из строя при запуске из Дженкинса без каких-либо изменений, внесенных в код или конфигурацию между ними). Проблемы, которые я получаю (кажется немного случайным, что происходит, когда — stacktrace ниже):

  1. MSB4018: неожиданно не удалось выполнить задачу CreateAppHost — чаще всего встречается
 /opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error MSB4018: The "CreateAppHost" task failed unexpectedly. [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error MSB4018: System.IO.IOException: The process cannot access the file '/opt/app-root/<project_path>/Pse.Spr.Reports.Web/obj/Release/netcoreapp3.1/Pse.Spr.Reports.Web' because it is being used by another process. [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error MSB4018:    at System.IO.FileStream.Init(FileMode mode, FileShare share, String originalPath) in /_/src/System.Private.CoreLib/shared/System/IO/FileStream.Unix.cs:line 120 [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error MSB4018:    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options) in /_/src/System.Private.CoreLib/shared/System/IO/FileStream.cs:line 252 [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error MSB4018:    at System.IO.FileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite) in /_/src/System.IO.FileSystem/src/System/IO/FileSystem.Unix.cs:line 29 [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error MSB4018:    at Microsoft.NET.HostModel.AppHost.BinaryUtils.CopyFile(String sourcePath, String destinationPath) [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error MSB4018:    at Microsoft.NET.HostModel.AppHost.HostWriter.CreateAppHost(String appHostSourceFilePath, String appHostDestinationFilePath, String appBinaryFilePath, Boolean windowsGraphicalUserInterface, String assemblyToCopyResorcesFrom) [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error MSB4018:    at Microsoft.NET.Build.Tasks.CreateAppHost.ExecuteCore() [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute() [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [/opt/app-root/<project_path>/<project_csproj>]
  1. MSB4018: неожиданно не удалось выполнить задачу создания файла
 /opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(192,5): error MSB4018: The "GenerateDepsFile" task failed unexpectedly. [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(192,5): error MSB4018: System.IO.IOException: The process cannot access the file '/opt/app-root/<project_release_path><*.deps.json>' because it is being used by another process. [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(192,5): error MSB4018:    at System.IO.FileStream.Init(FileMode mode, FileShare share, String originalPath) in /_/src/System.Private.CoreLib/shared/System/IO/FileStream.Unix.cs:line 120 [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(192,5): error MSB4018:    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options) in /_/src/System.Private.CoreLib/shared/System/IO/FileStream.cs:line 252 [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(192,5): error MSB4018:    at Microsoft.NET.Build.Tasks.GenerateDepsFile.WriteDepsFile(String depsFilePath) [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(192,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute() [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(192,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/opt/app-root/<project_path>/<project_csproj>]
/opt/rh/rh-dotnet31/root/usr/lib64/dotnet/sdk/3.1.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(192,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)
  1. NETSDK1029: Не удается использовать …/apphost в качестве исполняемого файла хоста приложения, так как он не содержит ожидаемой последовательности байтов — заполнителей-мой личный фаворит 🙂
 /usr/lib64/dotnet/sdk/3.1.117/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(393,5): error NETSDK1029: Unable to use '/usr/lib64/dotnet/packs/Microsoft.NETCore.App.Host.rhel.8-x64/3.1.17/runtimes/rhel.8-x64/native/apphost' as application host executable as it does not contain the expected placeholder byte sequence '63-33-61-62-38-66-66-31-33-37-32-30-65-38-61-64-39-30-34-37-64-64-33-39-34-36-36-62-33-63-38-39-37-34-65-35-39-32-63-32-66-61-33-38-33-64-34-61-33-39-36-30-37-31-34-63-61-65-66-30-63-34-66-32' that would mark where the application name would be written. [/opt/app-root/<project_csproj>]

Примерно сейчас я думаю, что просмотрел все результаты поиска, и до сих пор ни один из ответов не помог — так что, возможно, здесь мне повезет (и, надеюсь, я помогу кому-то в этом процессе).

Технические данные:

Агент Дженкинса
Работает на RHEL 8.4 с Podman v. 3.2.3

Данные контейнера
OS — RHEL7.9 и RHEL8.4 (я пробовал оба) Запускаются с подключенным томом из агента Дженкинса (каталог с исходным кодом из клонированного репозитория). Базовая настройка Dockerfile, в которой я использую базовый образ RHEL8 из нашего внутреннего репозитория — RHEL7 модифицирован путем установки scl-utils и тому подобного, но общая идея та же

 ARG rhel_version=7.9
ARG build_version=1.0.0
 
FROM <baseRHELimage>
 
ENV HOME=/opt/app-root/ 
    DOTNET_APP_PATH=/opt/app-root/
    #DOTNET_RUNNING_IN_CONTAINER=true
 
# Don't download/extract docs for nuget packages
ENV NUGET_XMLDOC_MODE=skip
 
RUN <setup yum repos>
    dnf install -y dotnet-sdk-3.1 amp;amp;
    dnf update -y; dnf clean all

Данные .NET
Использование SDK dotnet core 3.1

Проблемы возникают, когда я пытаюсь запустить сборку dotnet. Файл Jenkins сначала удаляет все каталоги bin/ и obj/ на первом этапе, а затем вызывает сборку для приложения.

Самые многообещающие вещи, которые я пробовал:

  • Некоторые люди предположили, что папки bin/ и obj/ необходимо полностью удалить — это происходит на первом этапе перед запуском
  • Я попытался разделить команду публикации dotnet на:
     dotnet restore 
    dotnet build --no-restore
    dotnet publish --no-build

… продолжает выбрасывать одну из этих 3 ошибок случайным образом между сборками непосредственно в сборке dotnet

Я попытался вызвать эту сборку dotnet с различными флагами, такими как «непараллельность», думая, что, возможно, потоки каким-то образом являются основной причиной (я получаю много предупреждений «процесс не может получить доступ к файлу, потому что он используется другим процессом», но это происходит и для успешных сборок — похоже, что повторные попытки dotnet по умолчанию обрабатывают эти предупреждения

Кто-нибудь знает, чего мне может не хватать? Конвейер CI/CD ранее выполнялся непосредственно на агенте RHEL7.7 (контейнеры не использовались). Теперь мы хотим перейти на контейнерные сборки с более новыми версиями RedHat, но эти случайно повторяющиеся проблемы блокируют меня, поэтому, если у кого — то есть какие — либо предложения-очень признателен 😉

Комментарии:

1. Может быть, что-то строится параллельно, и два проекта пытаются построить один и тот же зависимый проект? У многоцелевых проектов может быть одна и та же «параллельная» проблема.

2. @LukaszSzczygielek — разве флаг «без параллели» для сборки dotnet не должен обрабатывать это? Я попытался просмотреть проект, и некоторые проекты имеют общие зависимости от общей библиотеки. Эта библиотека dll создана первой, поэтому она не должна создавать так много проблем. И поскольку некоторые сборки проходят успешно, я бы хотел избежать внесения изменений в проект, поскольку для этого требуется привлечение целой другой команды и т. Д. (Сложная инфраструктура компании) — если возможно, я хотел бы решить проблему, используя только инструменты CI/CD

3. Это звучит так, как будто это может быть где-то ошибка. Не могли бы вы сообщить о проблеме в нашем трекере? Мы можем попытаться работать над этим: github.com/redhat-developer/s2i-dotnetcore

4. Вы устанавливаете объемный код в контейнер? Может ли быть так, что несколько процессов или несколько контейнеров пытаются создать один и тот же набор файлов на диске, что приводит к проблемам параллелизма?

5. @omajid Я зарегистрировал проблему в трекере. Что касается процессов — мы все еще находимся в фазе POC для контейнерных сборок, поэтому я использую отдельную машину агента Дженкинса только с одним запущенным контейнером, поэтому не должно быть никакого доступа к подключенному тому от других процессов

Метки: