Udostępnij za pośrednictwem

Dostosowywanie kontenerów platformy Docker w programie Visual Studio

  • Artykuł

Obrazy kontenerów można dostosować, edytując plik Dockerfile generowany przez program Visual Studio podczas dodawania obsługi platformy Docker do projektu. Niezależnie od tego, czy tworzysz dostosowany kontener z poziomu środowiska IDE programu Visual Studio, czy konfigurujesz kompilację wiersza polecenia, musisz wiedzieć, jak program Visual Studio używa pliku Dockerfile do kompilowania projektów. Musisz znać takie szczegóły, ponieważ ze względów wydajności program Visual Studio wykonuje specjalny proces tworzenia i uruchamiania konteneryzowanych aplikacji, które nie są oczywiste w pliku Dockerfile.

Załóżmy, że chcesz wprowadzić zmianę w pliku Dockerfile i zobaczyć wyniki zarówno w debugowaniu, jak i w kontenerach produkcyjnych. W takim przypadku można dodać polecenia w pliku Dockerfile, aby zmodyfikować pierwszy etap (zazwyczaj base). Zobacz Zmodyfikuj obraz kontenera w celu debugowania i produkcji. Jeśli jednak chcesz wprowadzić zmianę tylko podczas debugowania, ale nie w środowisku produkcyjnym, należy utworzyć kolejny etap i użyć ustawienia kompilacji DockerfileFastModeStage, aby poinformować program Visual Studio o użyciu tego etapu na potrzeby kompilacji debugowania. Zobacz Modyfikowanie obrazu kontenera tylko na potrzeby debugowania.

W tym artykule opisano szczegółowo proces kompilacji programu Visual Studio dla aplikacji konteneryzowanych, a następnie zawiera informacje na temat modyfikowania pliku Dockerfile w celu wpływu zarówno na kompilacje debugowania, jak i produkcyjne, lub tylko na potrzeby debugowania.

Tworzenie plików Dockerfile w programie Visual Studio

Notatka

W tej sekcji opisano proces kompilacji kontenera używany przez program Visual Studio podczas wybierania typu kompilacji kontenera Dockerfile. Jeśli używasz typu kompilacji zestawu .NET SDK, opcje dostosowywania są inne, a informacje w tej sekcji nie mają zastosowania. Zamiast tego zobacz Konteneryzuj aplikację .NET za pomocą dotnet publish i użyj właściwości opisanych w Dostosowywanie kontenera, aby skonfigurować proces budowy kontenera.

Kompilacja wieloetapowa

Gdy program Visual Studio skompiluje projekt, który nie używa kontenerów platformy Docker, wywołuje program MSBuild na komputerze lokalnym i generuje pliki wyjściowe w folderze (zazwyczaj bin) w folderze rozwiązania lokalnego. W przypadku projektu konteneryzowanego proces kompilacji uwzględnia jednak instrukcje pliku Dockerfile dotyczące kompilowania konteneryzowanej aplikacji. Plik Dockerfile używany przez program Visual Studio jest podzielony na wiele etapów. Ten proces opiera się na funkcji wielostopniowej kompilacji platformy Docker.

Funkcja kompilacji wielostopniowej pomaga uczynić proces budowania kontenerów bardziej efektywnym i zmniejsza rozmiar kontenerów, umożliwiając zawieranie tylko tych elementów, które są potrzebne aplikacji podczas uruchamiania. Kompilacja wieloetapowa jest używana w projektach platformy .NET Core, a nie w projektach .NET Framework.

Kompilacja wieloetapowa umożliwia tworzenie obrazów kontenerów na etapach tworzących obrazy pośrednie. Rozważmy na przykład typowy plik Dockerfile. Pierwszy etap jest nazywany base w pliku Dockerfile generowanym przez program Visual Studio, chociaż narzędzia nie wymagają tej nazwy.

# 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

Wiersze w pliku Dockerfile zaczynają się od obrazu ASP.NET z usługi Microsoft Container Registry (mcr.microsoft.com) i tworzą obraz pośredni base, który uwidacznia porty 80 i 443, a następnie ustawia katalog roboczy na /app.

Następnym etapem jest build, który jest wyświetlany w następujący sposób:

# 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

Widać, że etap build rozpoczyna się od innego oryginalnego obrazu z rejestru (sdk, a nie aspnet), zamiast kontynuować od podstawy. Obraz sdk zawiera wszystkie narzędzia kompilacji i z tego powodu jest o wiele większy niż obraz aspnet, który zawiera tylko składniki środowiska uruchomieniowego. Przyczyna użycia oddzielnego obrazu staje się jasna, gdy przyjrzysz się pozostałej części pliku 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"]

Ostatni etap rozpoczyna się ponownie od basei zawiera COPY --from=publish, aby skopiować opublikowane dane wyjściowe do obrazu końcowego. Ten proces umożliwia dużo mniejszy obraz końcowy, ponieważ nie musi zawierać wszystkich narzędzi kompilacji, które znajdowały się na obrazie sdk.

Poniższa tabela zawiera podsumowanie etapów używanych w typowym pliku Dockerfile utworzonym przez program Visual Studio:

Scena Opis
baza Tworzy podstawowy obraz środowiska uruchomieniowego, w którym opublikowano utworzoną aplikację. Ustawienia, które muszą być dostępne w czasie działania, są tutaj uwzględniane, takie jak porty i zmienne środowiskowe. Ten etap jest używany podczas uruchamiania z programu VS w trybie szybkim (ustawienie domyślne dla konfiguracji debugowania).
budować Projekt jest zbudowany na tym etapie. Obraz podstawowy zestawu SDK platformy .NET jest używany, który zawiera składniki wymagane do skompilowania projektu.
publikować Ten etap pochodzi z etapu kompilacji i publikuje projekt, który zostanie skopiowany do ostatniego etapu.
finał Ten etap umożliwia skonfigurowanie sposobu uruchamiania aplikacji i używania jej w środowisku produkcyjnym lub podczas uruchamiania z programu VS w trybie regularnym (ustawienie domyślne, jeśli nie jest używana konfiguracja debugowania).
aotdebug Ten etap jest używany jako podstawa ostatniego etapu podczas uruchamiania z programu VS w celu obsługi debugowania w trybie regularnym (ustawienie domyślne, jeśli nie jest używana konfiguracja debugowania).

Notatka

Etap aotdebug jest obsługiwany tylko w przypadku kontenerów systemu Linux. Jest ona używana w programie Visual Studio 2022 w wersji 17.11 lub nowszej, jeśli natywnego wdrożenia przed czasem (AOT) jest włączona w projekcie.

Rozgrzewka projektu

Project warmup odnosi się do serii kroków, które wykonywane są po wybraniu profilu Docker dla projektu (czyli po załadowaniu projektu lub dodaniu wsparcia dla Dockera) w celu zwiększenia wydajności kolejnych uruchomień (F5 lub Ctrl+F5). To zachowanie można skonfigurować w Tools>Options>Container Tools. Poniżej przedstawiono zadania uruchamiane w tle:

  • Sprawdź, czy program Docker Desktop jest zainstalowany i uruchomiony.
  • Upewnij się, że program Docker Desktop jest ustawiony na ten sam system operacyjny co projekt.
  • Ściąganie obrazów na pierwszym etapie pliku Dockerfile (etap base w większości plików Dockerfile).
  • Skompiluj plik Dockerfile i uruchom kontener.

Rozgrzewka odbywa się tylko w trybie Fast, więc uruchomiony kontener ma wolumin zamontowany w folderze aplikacji . Oznacza to, że wszelkie zmiany w aplikacji nie unieważniają kontenera. To zachowanie znacznie poprawia wydajność debugowania i zmniejsza czas oczekiwania na długotrwałe zadania, takie jak ściąganie dużych obrazów.

Włącz szczegółowe dzienniki narzędzi kontenera

W celach diagnostycznych można włączyć niektóre dzienniki narzędzi kontenerowych. Te dzienniki można włączyć, ustawiając określone zmienne środowiskowe. W przypadku projektów pojedynczego kontenera zmienna środowiskowa jest MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED, która następnie loguje się w %tmp%\Microsoft.VisualStudio.Containers.Tools. W przypadku projektów Docker Compose jest to MS_VS_DOCKER_TOOLS_LOGGING_ENABLED, po czym następuje logowanie w %tmp%\Microsoft.VisualStudio.DockerCompose.Tools.

Ostrzeżenie

Po włączeniu rejestrowania i używaniu serwera proxy tokenu na potrzeby uwierzytelniania platformy Azure poświadczenia uwierzytelniania mogą być rejestrowane jako zwykły tekst. Zobacz Konfigurowanie uwierzytelniania platformy Azure.

Następne kroki

Dowiedz się, jak używać etapów pliku Dockerfile do dostosowywania obrazów używanych do debugowania i produkcji, na przykład sposobu instalowania narzędzia na obrazie tylko podczas debugowania. Zobacz Konfigurowanie obrazów kontenerów na potrzeby debugowania.

Powiązana zawartość