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 debugowania i kontenerów produkcyjnych. W takim przypadku możesz dodać polecenia w pliku Dockerfile, aby zmodyfikować pierwszy etap (zazwyczaj base). Zobacz Modyfikowanie obrazu kontenera na potrzeby 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ć DockerfileFastModeStage ustawienia kompilacji, aby poinformować program Visual Studio o użyciu tego etapu na potrzeby kompilacji debugowania. Zobacz Modyfikowanie obrazu kontenera tylko do 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.

Kompilacje pliku Dockerfile w programie Visual Studio

Uwaga

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 Containerize a .NET app with dotnet publish (Konteneryzowanie aplikacji .NET za pomocą polecenia dotnet publish ) i użyj właściwości opisanych w temacie Dostosowywanie kontenera w celu skonfigurowania procesu kompilacji kontenera .

Kompilacja wieloestowa

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 kompilacji wieloeeżowej platformy Docker.

Funkcja kompilacji wieloemetrowej pomaga zwiększyć wydajność procesu tworzenia kontenerów i zmniejsza kontenery, umożliwiając im zawieranie tylko bitów potrzebnych przez aplikację w czasie wykonywania. Kompilacja wieloestowa jest używana w projektach platformy .NET Core, a nie w projektach programu .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 wywoływany 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 base pośredni, który uwidacznia porty 80 i 443, a następnie ustawia katalog roboczy na /appwartość .

Następnym etapem jest build, który pojawia się 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 build etap zaczyna się od innego oryginalnego obrazu z rejestru (sdk zamiast ), a nie aspnetod 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 z baseelementu i zawiera element COPY --from=publish , aby skopiować opublikowane dane wyjściowe do końcowego obrazu. 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:

Etap opis
base Tworzy podstawowy obraz środowiska uruchomieniowego, w którym opublikowano utworzoną aplikację. Ustawienia, które muszą być dostępne w czasie wykonywania, przejdź tutaj, 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).
build Projekt jest zbudowany na tym etapie. Obraz podstawowy zestawu SDK platformy .NET jest używany, który zawiera składniki wymagane do skompilowania projektu.
publish Ten etap pochodzi z etapu kompilacji i publikuje projekt, który zostanie skopiowany do ostatniego etapu.
końcowe 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).

Uwaga

Etap aotdebug jest obsługiwany tylko w przypadku kontenerów systemu Linux. Jest on używany w programie Visual Studio 2022 w wersji 17.11 lub nowszej, jeśli natywne wdrożenie AOT (AOT) jest włączone w projekcie.

Rozgrzewka projektu

Rozgrzewka projektu odnosi się do serii kroków, które mają miejsce po wybraniu profilu platformy Docker dla projektu (czyli po załadowaniu projektu lub dodaniu obsługi platformy Docker) w celu zwiększenia wydajności kolejnych przebiegów (F5 lub Ctrl+F5). To zachowanie można skonfigurować w obszarze Narzędzia Opcje>narzędzia Narzędzia.> 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 ( base etap w większości plików Dockerfile).
  • Skompiluj plik Dockerfile i uruchom kontener.

Rozgrzewka odbywa się tylko w trybie szybkim , więc uruchomiony kontener ma zainstalowany wolumin folderu 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łączanie szczegółowych dzienników narzędzi kontenera

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

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ść