Проблема довгого часу виконання команди dotnet restore у конвеєрі збірки OpenShift

4 Березня 2024 в 14:37 30

Під час виконання нашого конвеєра збірки на платформі OpenShift ми стикаємося зі значним затримкою, зокрема з командою dotnet restore у Dockerfile. Ця затримка значно уповільнює весь процес збірки.


#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 8080
EXPOSE 8081
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG BUILD_CONFIGURATION=Release
ARG HTTP_PROXY="<my-url-local-proxy>"
ENV DOTNET_NUGET_SIGNATURE_VERIFICATION=false
WORKDIR /src
COPY ["My.API/My.API.csproj", "My.API/"]
COPY ["My.Application/My.Application.csproj", "My.Application/"]
COPY ["My.Infrastructure/My.Infrastructure.csproj", "My.Infrastructure/"]
COPY "My.API/nuget.config" .
RUN dotnet restore -v diag "./My.API/./My.API.csproj"
COPY .
WORKDIR "/src/My.API"
RUN dotnet build "./My.API.csproj" -c $BUILD_CONFIGURATION -o /app/build
FROM build AS publish
RUN dotnet publish "./My.API.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "My.API.dll"]

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base

WORKDIR /app

EXPOSE 8080

EXPOSE 8081

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build

ARG BUILD_CONFIGURATION=Release

ARG HTTP_PROXY="<my-url-local-proxy>"

ENV DOTNET_NUGET_SIGNATURE_VERIFICATION=false

WORKDIR /src

COPY ["My.API/My.API.csproj", "My.API/"]

COPY ["My.Application/My.Application.csproj", "My.Application/"]

COPY ["My.Infrastructure/My.Infrastructure.csproj", "My.Infrastructure/"]

COPY "My.API/nuget.config" .

RUN dotnet restore -v diag "./My.API/./My.API.csproj"

COPY .

WORKDIR "/src/My.API"

RUN dotnet build "./My.API.csproj" -c $BUILD_CONFIGURATION -o /app/build

FROM build AS publish

RUN dotnet publish "./My.API.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

FROM base AS final

WORKDIR /app

COPY --from=publish /app/publish .

ENTRYPOINT ["dotnet", "My.API.dll"]

Мій файл nugget.config


<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
</configuration>

<?xml version="1.0" encoding="utf-8"?>

</packageSources>

</configuration>

Використана версія: Я використовую версію OpenShift 4.

Поточний результат: Локальний результат: я можу працювати належним чином з моїм Dockerfile на моєму локальному комп’ютері. Результат на OpenShift: Операція dotnet restore відбувається стабільно протягом 1 години і, схоже, перевищує таймаут під час MSBuild у нашому конвеєрі збірки OpenShift.

Додаткова інформація: Я побачив розумну інформацію про перевірку підпису пакунків NuGet тут і додатковий параметр ENV DOTNET_NUGET_SIGNATURE_VERIFICATION=false у Dockerfile. Але це поки що не вирішило проблему. Вам також потрібно для отримання додаткової інформації: тут. У моєму Dockerfile я також додав змінну проксі та використовую файл nuget.config. Ви можете подивитися це вище. Я намагався створити інший образ простої програми Node. Але він також застряг на кроці npm install. Я думаю, те саме поняття із командою dotnet restore. Я завжди стежу за своєю квотою ресурсів. Я не бачу, щоб обмеження досягло CPU, пам’яті,… Я також пробував змінити aspnet:8.0 на aspnet:7.0. Це також не принесло успіху.

Будь-які думки або поради будуть вдячно прийняті. Дякуємо за вашу увагу до цього питання.