#docker #.net-core #dockerfile #asp.net5
Вопрос:
В настоящее время я создаю файл dockerfile для гибридного приложения vue mvc .net 5. Для этого мне нужно установить NodeJS, пакеты nuget, а также установить webpack. Каждый раз, когда я пытаюсь создать изображение, это занимает около 30 минут. Я изучил, как я могу сократить это время сборки, затем я понял, что новая функция Docker Buildkit обеспечивает монтирование кэша. Но я не нашел много примеров или документации по работе с пакетами nuget специально.
Пожалуйста, может ли кто-нибудь помочь мне в предоставлении любого примера файла dockerfile, в котором реализован —mount=тип=кэш для пакетов nuget.
Ответ №1:
Ключ использует один и тот же --mount=type=cache
аргумент во всех командах dockerfile RUN
, которым требуется доступ к одному и тому же кэшу пакетов (например docker restore
, docker build
, docker publish
).
Вот краткий пример файла dockerfile, показывающий то же --mount=type=cache
самое с одинаковым id
разбросом по отдельным dotnet restore/build/publish
вызовам. Разделение вызовов не всегда необходимо, как build
это будет restore
по умолчанию, и publish
будет выполняться и то, и другое, но этот способ показывает совместное использование одного и того же кэша несколькими командами. Объявления о монтировании кэша отображаются только в самом файле dockerfile и не требуют ввода аргументов docker build
.
В примере также показано, как вы можете использовать --mount=type=secret
аргумент BuildKit для передачи NuGet.Конфигурационный файл, который может быть настроен для доступа, например, к частному каналу nuget. По умолчанию секретные файлы, переданные таким образом , отображаются /run/secrets/<secret-id>
, но вы можете изменить их расположение с помощью target
атрибута в docker build
команде. Они существуют только во время RUN
вызова и не остаются в конечном изображении.
# syntax=docker/dockerfile:1.2
FROM my-dotnet-sdk-image as builder
WORKDIR "/src"
COPY "path/to/project/src" .
RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages
--mount=type=secret,id=nugetconfig
dotnet restore "MyProject.csproj"
--configfile /run/secrets/nugetconfig
--runtime linux-x64
RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages
dotnet build "MyProject.csproj"
--no-restore
--configuration Release
--framework netcoreapp3.1
--runtime linux-x64
RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages
dotnet publish "MyProject.csproj"
--no-restore
--no-build
-p:PublishReadyToRun=true
-p:PublishReadyToRunShowWarnings=true
-p:TieredCompilation=false
-p:TieredCompilationQuickJit=false
--configuration Release
--framework netcoreapp3.1
--runtime linux-x64
Пример docker build
команды для передачи в nugetconfig
файле для частного канала может быть:
docker build --secret id=nugetconfig,src=path/to/nuget.config -t my-dotnet-image .
Для этой команды DOCKER_BUILDKIT=1
необходимо задать переменную среды.
В качестве альтернативы вы можете использовать buildx
:
docker buildx build --secret id=nugetconfig,src=path/to/nuget.config -t my-dotnet-image .
Комментарии:
1. Спасибо rob3c за ответ. У меня есть еще один вопрос, ограничен ли этот кэш только для этой сборки или его можно повторно использовать для каждой сборки этого файла dockerfile? если нет, пожалуйста, предложите этот подход, так как у меня много пакетов nuget и каждый раз, когда я создаю файл docker, требуется много времени на сборку.
2. Путь в
--mount=type=cache,id=nuget,target=/root/.nuget/packages
предполагает, что хост основан на linux. Что делать, если хост-это Windows? Можно ли использовать эту функцию на кросс-платформе?3. @SKK Кэш используется во всех сборках, в которых используется одно и то же
id
значение. Это может сделать локальные сборки очень быстрыми, но сборки CI/CD со свежими средами принесут пользу только в одном файле dockerfile.4. @MuhammadRehanSaeed В настоящее время я работаю на хосте Windows, использующем контейнеры Linux. Это
target
значение указывает, где кэш будет смонтирован в контейнере. Docker сам управляет тем, где он хранится локально на хосте, и это недоступно непосредственно для нас.5. спасибо @rob3c Я реализовал то же самое и мониторинг с различными запусками сборки, чтобы проверить, не отражает ли этот кэш какие-либо новые функции. Кроме того, просто хочу знать, на случай, если я захочу очистить этот кэш, например, у меня есть новые пакеты, введенные в мою логику. В таком случае, как я могу двигаться вперед, либо buildkit, либо mount позаботятся о новых изменениях? или мне нужно вручную очистить кэш (в этом случае, пожалуйста, дайте мне знать, как я могу очистить эти данные кэша).