Настройка контейнеров Docker в Visual Studio
Вы можете настроить образы контейнеров, отредактировав файл Dockerfile, который Visual Studio создает при включении поддержки Docker в проекте. Независимо от того, выполняете ли вы сборку настраиваемого контейнера из интегрированной среды разработки Visual Studio или настраиваете сборку из командной строки, необходимо знать, как в Visual Studio используется файл Dockerfile для сборки проектов. Вам необходимо это знать, так как по соображениям производительности Visual Studio следует специальному процессу создания и запуска контейнерных приложений, который не очевиден из Dockerfile.
Предположим, вы хотите внести изменения в Dockerfile и увидеть результаты отладки и рабочих контейнеров. В этом случае можно добавить команды в Dockerfile, чтобы изменить первый этап (обычно base). См. раздел Изменение образа контейнера для среды отладки и рабочей среды. Но если вы хотите внести изменения только для среды отладки, но не рабочей среды, вам следует создать еще один этап и использовать параметр сборки DockerfileFastModeStage, чтобы указать Visual Studio использовать этот этап для отладочных сборок. См. раздел Изменение образа контейнера только для среды отладки.
В этой статье подробно описан процесс сборки Visual Studio для контейнерных приложений, а также показано, как изменить файл Dockerfile, чтобы он повлиял как на сборки отладки, так и на рабочие сборки, или только на сборки отладки.
Сборки Dockerfile в Visual Studio
Примечание.
В этом разделе описывается процесс сборки контейнера, который Visual Studio использует при выборе типа сборки контейнера Dockerfile. Если вы используете тип сборки пакета SDK для .NET, параметры настройки отличаются, а сведения в этом разделе не применимы. Вместо этого см. раздел "Контейнеризация приложения .NET с помощью dotnet publish " и использование свойств, описанных в статье "Настройка контейнера" для настройки процесса сборки контейнера .
Многоэтапная сборка
Когда в Visual Studio выполняется сборка проекта, который не использует контейнеры Docker, на локальном компьютере вызывается MSBuild и создаются выходные файлы в папке (обычно bin), вложенной в локальную папку решения. Однако для контейнерного проекта в процессе сборки учитываются инструкции из файла Dockerfile. Сборка с помощью Dockerfile в Visual Studio делится на несколько этапов. При этом применяется функция многоэтапной сборки Docker.
Функция многоэтапной сборки повышает эффективность сборки контейнеров и позволяет уменьшить их размер, так как они содержат только тот код, который требуется приложению во время выполнения. Многоэтапная сборка применяется для проектов .NET Core, но не для проектов .NET Framework.
При многоэтапной сборке образы контейнеров создаются в несколько шагов, на каждом из которых формируются промежуточные образы. В качестве примера рассмотрим обычный объект Dockerfile. Первый этап называется base в файле Dockerfile, создаваемом Visual Studio, хотя для инструментов это имя не требуется.
# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
Сначала в Dockerfile используется образ ASP.NET из реестра контейнеров Майкрософт (mcr.microsoft.com) для создания промежуточного образа base, для которого открываются порты 80 и 443, и определения рабочей папки /app.
Следующий этап — build. Выглядит он так:
# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:3.1-buster-slim AS build
WORKDIR /src
COPY ["WebApplication43/WebApplication43.csproj", "WebApplication43/"]
RUN dotnet restore "WebApplication43/WebApplication43.csproj"
COPY . .
WORKDIR "/src/WebApplication43"
RUN dotnet build "WebApplication43.csproj" -c Release -o /app/build
Как вы видите, на этапе build вместо продолжения работы с образом base берется другой исходный образ из реестра (sdk, а не aspnet). Образ sdk содержит все средства сборки и поэтому гораздо больше, чем образ aspnet, который содержит только компоненты времени выполнения. Причина использования отдельного образа становится очевидной, если посмотреть на остальную часть файла Dockerfile:
# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication43.csproj" -c Release -o /app/publish
# This stage is used in production or when running from VS in regular mode (Default when not using the Debug configuration)
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication43.dll"]
Последний этап снова начинается с образа base и включает в себя команду COPY --from=publish, которая копирует опубликованные выходные данные в итоговый образ. Это позволяет значительно уменьшить итоговый образ, так как в него не нужно включать все средства сборки, которые имелись в образе sdk.
В следующей таблице приведены этапы, используемые в типичном файле Dockerfile, созданном Visual Studio:
| Этап | Description |
|---|---|
| base | Создает базовый образ среды выполнения, в котором публикуется встроенное приложение. Параметры, которые должны быть доступны во время выполнения, см. здесь, например порты и переменные среды. Этот этап используется при запуске из VS в быстром режиме (по умолчанию для конфигурации отладки). |
| сборка | Проект построен на этом этапе. Используется базовый образ пакета SDK для .NET, который содержит компоненты, необходимые для сборки проекта. |
| публикация | Этот этап является производным от этапа сборки и публикует проект, который будет скопирован на последний этап. |
| final | Этот этап настраивает запуск приложения и используется в рабочей среде или при запуске из VS в обычном режиме (по умолчанию при использовании конфигурации отладки). |
| aotdebug | Этот этап используется в качестве основы для конечного этапа при запуске из VS для поддержки отладки в обычном режиме (по умолчанию при использовании конфигурации отладки). |
Примечание.
Этап aotdebug поддерживается только для контейнеров Linux. Он используется в Visual Studio 2022 17.11 и более поздних версий, если в проекте включено собственное развертывание с заранеего времени (AOT).
Прогрев проекта
Под прогревом проекта понимается последовательность действий, которая выполняется при выборе профиля Docker для проекта (то есть при загрузке проекта или добавлении поддержки Docker) с целью оптимизировать его производительность при последующих запусках (F5 или CTRL+F5). Это поведение можно настроить в разделе "Средства> параметров>контейнера". Ниже описываются задачи, которые выполняются в фоновом режиме:
- Проверка установки и запуска Docker Desktop.
- Проверка того, что для Docker Desktop и проекта задана одна и та же операционная система.
- Извлечение образа на первом этапе файла Dockerfile (этап
baseв большинстве файлов Dockerfile). - Создание файла Dockerfile и запуск контейнера.
Прогревание происходит только в быстром режиме, поэтому запущенный контейнер подключен к папке приложения . Это означает, что любые изменения в приложении не делают контейнер недействительным. Это поведение значительно повышает производительность отладки и уменьшает время ожидания длительных задач, таких как извлечение больших образов.
Включение подробных журналов средств контейнера
В целях диагностики можно включить определенные журналы средств контейнеров. Эти журналы можно включить, задав определенные переменные среды. Для проектов одного контейнера переменная среды — это MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLEDпеременная среды, которая затем входит в %tmp%\Microsoft.VisualStudio.Containers.Toolsсистему. Для проектов %tmp%\Microsoft.VisualStudio.DockerCompose.ToolsDocker Compose это MS_VS_DOCKER_TOOLS_LOGGING_ENABLEDзначит, что затем выполняет вход.
Предупреждение
Если ведение журнала включено и вы используете прокси-сервер маркера для проверки подлинности Azure, учетные данные проверки подлинности могут быть записаны как обычный текст. См. статью "Настройка проверки подлинности Azure".
Следующие шаги
Узнайте, как использовать этапы Dockerfile для настройки образов, используемых для отладки и рабочей среды, например, как установить средство на образе только при отладке. Сведения о настройке образов контейнеров для отладки.