Přizpůsobení kontejnerů Dockeru v sadě Visual Studio

Image kontejneru můžete přizpůsobit úpravou souboru Dockerfile, který Visual Studio vygeneruje, když do projektu přidáte podporu Dockeru. Bez ohledu na to, jestli vytváříte přizpůsobený kontejner z integrovaného vývojového prostředí sady Visual Studio nebo nastavujete sestavení příkazového řádku, musíte vědět, jak Visual Studio používá k sestavení projektů soubor Dockerfile. Tyto podrobnosti potřebujete znát, protože visual Studio z důvodů výkonu se řídí speciálním procesem sestavování a spouštění kontejnerizovaných aplikací, které nejsou zřejmé ze souboru Dockerfile.

Předpokládejme, že chcete provést změnu v souboru Dockerfile a zobrazit výsledky v ladění i v produkčních kontejnerech. V takovém případě můžete do souboru Dockerfile přidat příkazy, které upraví první fázi (obvykle base). Viz Úprava image kontejneru pro ladění a produkci. Pokud ale chcete provést změnu pouze při ladění, ale ne v produkčním prostředí, měli byste vytvořit další fázi a pomocí DockerfileFastModeStage nastavení sestavení sdělit sadě Visual Studio, aby tuto fázi používala pro sestavení ladění. Viz Úprava image kontejneru pouze pro ladění.

Tento článek podrobně vysvětluje proces sestavení sady Visual Studio pro kontejnerizované aplikace a pak obsahuje informace o tom, jak upravit soubor Dockerfile tak, aby ovlivnil ladění i produkční sestavení, nebo pouze pro ladění.

Sestavení souboru Dockerfile v sadě Visual Studio

Poznámka:

Tato část popisuje proces sestavení kontejneru, který Sada Visual Studio používá při výběru typu sestavení kontejneru Dockerfile. Pokud používáte typ sestavení sady .NET SDK, možnosti přizpůsobení se liší a informace v této části se nepoužijí. Místo toho si přečtěte téma Kontejnerizace aplikace .NET s publikováním dotnet a použití vlastností popsaných v tématu Přizpůsobení kontejneru ke konfiguraci procesu sestavení kontejneru.

Sestavení s více fázemi

Když Visual Studio sestaví projekt, který nepoužívá kontejnery Dockeru, vyvolá nástroj MSBuild na místním počítači a vygeneruje výstupní soubory ve složce (obvykle bin) ve složce místního řešení. U kontejnerizovaného projektu ale proces sestavení bere v úvahu pokyny souboru Dockerfile pro sestavení kontejnerizované aplikace. Soubor Dockerfile, který Visual Studio používá, je rozdělený do několika fází. Tento proces spoléhá na funkci sestavení Dockeru s více fázemi.

Funkce sestavení s více fázemi pomáhá zefektivnit proces sestavování kontejnerů a zmenšuje kontejnery tím, že jim umožní obsahovat pouze bity, které vaše aplikace potřebuje za běhu. Sestavení s více fázemi se používá pro projekty .NET Core, nikoli pro projekty .NET Framework.

Sestavení s více fázemi umožňuje vytváření imagí kontejnerů ve fázích, které vytvářejí zprostředkující image. Jako příklad zvažte typický soubor Dockerfile. První fáze se volá base v souboru Dockerfile, který Sada Visual Studio generuje, i když nástroje tento název nevyžadují.

FROM mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

Řádky v souboru Dockerfile začínají ASP.NET image ze služby Microsoft Container Registry (mcr.microsoft.com) a vytvoří zprostředkující image base , která zpřístupňuje porty 80 a 443 a nastaví pracovní adresář na /app.

Další fáze je build, která se zobrazí takto:

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

Můžete vidět, že build fáze začíná z jiné původní image z registru (sdk místo ), a nikoli aspnetod základu. Image sdk má všechny nástroje sestavení a z tohoto důvodu je mnohem větší než image aspnet, která obsahuje pouze komponenty modulu runtime. Když se podíváte na zbytek souboru Dockerfile, je důvod použití samostatné image jasný:

FROM build AS publish
RUN dotnet publish "WebApplication43.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication43.dll"]

Poslední fáze začíná znovu od basea zahrnuje COPY --from=publish zkopírování publikovaného výstupu do konečného obrázku. Tento proces umožňuje, aby konečná image byla mnohem menší, protože nemusí obsahovat všechny nástroje sestavení, které byly v imagi sdk .

MSBuild

Poznámka:

Tato část popisuje, jak můžete kontejnery Dockeru přizpůsobit, když zvolíte typ sestavení kontejneru Dockerfile. Pokud používáte typ sestavení sady .NET SDK, možnosti přizpůsobení se liší a informace v tomto článku se nepoužijí. Místo toho si přečtěte téma Kontejnerizace aplikace .NET s publikováním dotnet.

Soubory Dockerfile vytvořené v sadě Visual Studio pro projekty .NET Framework (a pro projekty .NET Core vytvořené pomocí verzí sady Visual Studio před sadou Visual Studio 2017 Update 4) nejsou soubory Dockerfile s více fázemi. Kroky v těchtosouborch Místo toho sada Visual Studio sestaví soubor Dockerfile rozhraní .NET Framework, nejprve zkompiluje projekt pomocí nástroje MSBuild. Když se to podaří, Visual Studio pak sestaví soubor Dockerfile, který jednoduše zkopíruje výstup sestavení z NÁSTROJE MSBuild do výsledné image Dockeru. Protože kroky ke kompilaci kódu nejsou součástí souboru Dockerfile, nemůžete vytvářet soubory Dockerfile rozhraní .NET Framework pomocí docker build příkazového řádku. K sestavení těchto projektů byste měli použít nástroj MSBuild.

Pokud chcete vytvořit image pro jeden projekt kontejneru Dockeru, můžete použít MSBuild s /t:ContainerBuild možností příkazu. Tento příkaz říká nástroji MSBuild, aby místo výchozího cíle sestavil cíl ContainerBuildBuild. Příklad:

MSBuild MyProject.csproj /t:ContainerBuild /p:Configuration=Release

Při sestavování řešení z integrovaného vývojového prostředí sady Visual Studio uvidíte výstup podobný výstupu v okně Výstup . Vždy používejte /p:Configuration=Release, protože v případech, kdy Visual Studio používá optimalizaci sestavení s více fázemi, nemusí být výsledky při sestavování konfigurace ladění podle očekávání. Viz Ladění.

Pokud používáte projekt Docker Compose, pomocí tohoto příkazu sestavte image:

msbuild /p:SolutionPath=<solution-name>.sln /p:Configuration=Release docker-compose.dcproj

Ladění

Poznámka:

Tato část popisuje, jak můžete kontejnery Dockeru přizpůsobit, když zvolíte typ sestavení kontejneru Dockerfile. Pokud používáte typ sestavení sady .NET SDK, možnosti přizpůsobení se liší a většina informací v této části se nedá použít. Místo toho si přečtěte téma Kontejnerizace aplikace .NET s publikováním dotnet.

Při sestavování v konfiguraci ladění existuje několik optimalizací, které Sada Visual Studio pomáhá s výkonem procesu sestavení pro kontejnerizované projekty. Proces sestavení pro kontejnerizované aplikace není tak jednoduchý, jako když jednoduše postupujete podle kroků uvedených v souboru Dockerfile. Sestavování v kontejneru je pomalejší než sestavování na místním počítači. Když tedy sestavíte konfiguraci ladění , Visual Studio ve skutečnosti sestaví projekty na místním počítači a pak sdílí výstupní složku do kontejneru pomocí připojení svazku. Sestavení s touto povolenou optimalizací se nazývá sestavení rychlého režimu.

V režimu Rychlé volání docker build sady Visual Studio s argumentem, který Dockeru říká, že sestaví pouze první fázi v souboru Dockerfile (obvykle fázi base ). To můžete změnit nastavením MSBuild vlastnost , DockerfileFastModeStagepopsané v Kontejner Tools MSBuild vlastnosti. Visual Studio zpracovává zbytek procesu bez ohledu na obsah souboru Dockerfile. Při úpravě souboru Dockerfile, například přizpůsobení prostředí kontejneru nebo instalaci dalších závislostí, byste měli změny vložit do první fáze. Všechny vlastní kroky umístěné v souboru Dockerfile buildpublishnebo final dílčí fáze se nespustí.

K této optimalizaci výkonu dochází pouze v případě, že sestavíte konfiguraci ladění . V konfiguraci vydané verze se sestavení vyskytuje v kontejneru, jak je uvedeno v souboru Dockerfile.

Pokud chcete zakázat optimalizaci výkonu a sestavení podle dockerfile určuje, pak nastavte ContainerDevelopmentMode vlastnost Regular v souboru projektu následujícím způsobem:

<PropertyGroup>
   <ContainerDevelopmentMode>Regular</ContainerDevelopmentMode>
</PropertyGroup>

Pokud chcete obnovit optimalizaci výkonu, odeberte vlastnost ze souboru projektu.

Při spuštění ladění (F5) se dříve spuštěný kontejner znovu použije, pokud je to možné. Pokud nechcete předchozí kontejner znovu použít, můžete v sadě Visual Studio použít příkazy Znovu sestavit nebo vyčistit a vynutit tak, aby visual Studio používalo nový kontejner.

Proces spuštění ladicího programu závisí na typu projektu a kontejnerového operačního systému:

Scénář	Proces ladicího programu
Aplikace .NET Core (kontejnery Linuxu)	Visual Studio ho stáhne vsdbg a namapuje na kontejner, pak se zavolá pomocí programu a argumentů (tj dotnet webapp.dll. ) a pak se ladicí program připojí k procesu.
Aplikace .NET Core (kontejnery Windows)	Visual Studio ho používá onecoremsvsmon a mapuje na kontejner, spustí ho jako vstupní bod a pak se k němu Visual Studio připojí a připojí se k programu. Podobá se tomu, jak byste normálně nastavili vzdálené ladění na jiném počítači nebo virtuálním počítači.
Aplikace .NET Framework	Visual Studio ho používá msvsmon a mapuje na kontejner, spouští ho jako součást vstupního bodu, kde se k němu Visual Studio může připojit a připojí se k programu.

Informace najdete vsdbg.exev tématu Offroad ladění .NET Core v Linuxu a OS X ze sady Visual Studio.

Úprava image kontejneru pro ladění a produkční prostředí

Pokud chcete upravit image kontejneru pro ladění i produkční prostředí, upravte base fázi. Přidejte vlastní nastavení do souboru Dockerfile v oddílu základní fáze, obvykle první oddíl souboru Dockerfile. Informace o příkazech Dockerfile najdete v referenční dokumentaci k souboru Dockerfile.

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
# <add your commands here>

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["WebApplication3/WebApplication3.csproj", "WebApplication3/"]
RUN dotnet restore "WebApplication3/WebApplication3.csproj"
COPY . .
WORKDIR "/src/WebApplication3"
RUN dotnet build "WebApplication3.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "WebApplication3.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication3.dll"]

Úprava image kontejneru pouze pro ladění

Tento scénář platí, když chcete s kontejnery něco udělat, aby vám pomohl v procesu ladění, například instalaci něčeho pro účely diagnostiky, ale nechcete, aby se tato instalace nainstalovala v produkčních buildech.

Pokud chcete upravit kontejner pouze pro ladění, vytvořte fázi a pak pomocí vlastnosti DockerfileFastModeStage MSBuild dejte sadě Visual Studio vědět, aby při ladění používala přizpůsobenou fázi. Informace o příkazech Dockerfile najdete v referenční dokumentaci k souboru Dockerfile.

V následujícím příkladu nainstalujeme balíček procps-ng, ale pouze v režimu ladění. Tento balíček poskytuje příkaz pidof, který Sada Visual Studio vyžaduje, ale není na obrázku Mariner použitém tady. Fáze, která používáme pro rychlé ladění režimu, je debugvlastní fáze definovaná zde. Fáze rychlého režimu nemusí dědit z build fáze nebo publish fáze, protože base Visual Studio připojí svazek, který obsahuje vše potřebné ke spuštění aplikace, jak je popsáno výše v tomto článku.

#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:6.0-cbl-mariner2.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM base AS debug
RUN tdnf install procps-ng -y

FROM mcr.microsoft.com/dotnet/sdk:6.0-cbl-mariner2.0 AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

Do souboru projektu přidejte toto nastavení, abyste sadě Visual Studio řekli, aby při ladění používala vaši vlastní fázi debug .

  <PropertyGroup>
     <!-- other property settings -->
     <DockerfileFastModeStage>debug</DockerfileFastModeStage>
  </PropertyGroup>

Další části obsahují informace, které můžou být užitečné v určitých případech, například když chcete zadat jiný vstupní bod nebo pokud je vaše aplikace povolená protokolem SSL a měníte něco, co by mohlo mít vliv na způsob zpracování certifikátů SSL.

Sestavení z příkazového řádku

Pokud chcete vytvořit projekt kontejneru s souborem Dockerfile mimo Visual Studio, můžete použít docker buildpříkaz , MSBuild, dotnet buildnebo dotnet publish sestavit z příkazového řádku.

Pokud používáte typ sestavení sady .NET SDK, nemáte soubor Dockerfile, takže ho nemůžete použít docker build. Místo toho použijte MSBuilddotnet build nebo dotnet publish sestavte na příkazovém řádku.

Použití sestavení Dockeru

K sestavení kontejnerizovaného řešení z příkazového řádku můžete obvykle použít příkaz docker build <context> pro každý projekt v řešení. Zadáte kontextový argument sestavení . Kontext sestavení pro soubor Dockerfile je složka na místním počítači, který se používá jako pracovní složka k vygenerování image. Jedná se například o složku, ze které kopírujete soubory při kopírování do kontejneru. V projektech .NET Core použijte složku, která obsahuje soubor řešení (.sln). Vyjádřeno jako relativní cesta, tento argument je obvykle "." pro soubor Dockerfile ve složce projektu a soubor řešení ve své nadřazené složce. Pro projekty rozhraní .NET Framework je kontext sestavení složka projektu, nikoli složka řešení.

docker build -f Dockerfile ..

Project warmup

Project warmup odkazuje na řadu kroků, ke kterým dojde, když je pro projekt vybraný profil Dockeru (to znamená, že při načtení projektu nebo přidání podpory Dockeru), aby se zlepšil výkon následných spuštění (F5 nebo Ctrl+F5). Toto chování je konfigurovatelné v části Nástroje>Možnosti>kontejneru Nástrojů. Tady jsou úlohy, které běží na pozadí:

• Zkontrolujte, jestli je nainstalovaná a spuštěná aplikace Docker Desktop.
• Ujistěte se, že je Docker Desktop nastavený na stejný operační systém jako projekt.
• Stáhněte image v první fázi souboru Dockerfile ( base fáze ve většině souborů Dockerfile).
• Sestavte soubor Dockerfile a spusťte kontejner.

K zahřátí dochází pouze v režimu Fast , takže spuštěný kontejner má svazek připojené složky aplikace . To znamená, že jakékoli změny aplikace neoplatní kontejner. Toto chování výrazně zlepšuje výkon ladění a snižuje dobu čekání na dlouhotrvající úlohy, jako je například vyžádání velkých imagí.

Mapování svazků

Aby ladění fungovalo v kontejnerech, Visual Studio používá mapování svazků k mapování ladicího programu a složek NuGet z hostitelského počítače. Mapování svazků je popsané v dokumentaci k Dockeru. Mapování svazků pro kontejner můžete zobrazit pomocí okna Kontejnery v sadě Visual Studio.

Tady jsou svazky, které jsou připojené v kontejneru. To, co vidíte v kontejnerech, se může lišit v závislosti na podverzi sady Visual Studio 2022, kterou používáte.

Objem	Popis
Složka aplikace	Obsahuje složku projektu, ve které se nachází soubor Dockerfile.
HotReloadAgent	Obsahuje soubory pro agenta opětovného načítání za provozu.
HotReloadProxy	Obsahuje soubory potřebné ke spuštění služby, která umožňuje agentu opětovného načítání hostitele komunikovat se sadou Visual Studio na hostiteli.
Složky balíčků NuGet	Obsahuje balíčky NuGet a záložní složky, které se čtou z souboru obj{project}.csproj.nuget.g.props v projektu.
Vzdálený ladicí program	Obsahuje bity potřebné ke spuštění ladicího programu v kontejneru v závislosti na typu projektu. Toto je podrobněji vysvětleno v části Ladění .
Zdrojová složka	Obsahuje kontext sestavení, který se předává příkazům Dockeru.
TokenService.Proxy	Obsahuje soubory potřebné ke spuštění služby, které umožňuje visualStudioCredential komunikovat se sadou Visual Studio na hostiteli.

V případě .NET 8 můžou být k dispozici i další přípojné body v kořenovém adresáři a pro uživatele aplikace, který obsahuje tajné kódy uživatele a certifikát HTTPS. A v sadě Visual Studio 17.10 ve verzi Preview jsou svazky služby Opětovné načítání za provozu a tokenů společně s další komponentou, pomocný pomocník pro distribuci, sloučeny pod jedním přípojným bodem /VSTools.

Poznámka:

Visual Studio 17.10 Preview Pokud používáte Modul Dockeru v Subsystém Windows pro Linux (WSL) bez Docker Desktopu, nastavte proměnnou VSCT_WslDaemon=1 prostředí tak, aby visual Studio při vytváření připojení svazků používalo cesty WSL. Vyžaduje se také balíček NuGet Microsoft.VisualStudio.Azure.Containers.Tools.Targets 1.20.0-Preview 1 .

U ASP.NET základních webových aplikací můžou existovat dvě další složky pro certifikát SSL a tajné kódy uživatelů, které jsou podrobněji vysvětleny v další části.

Povolení podrobných protokolů nástrojů kontejneru

Pro účely diagnostiky můžete povolit určité protokoly nástroje kontejneru. Tyto protokoly můžete povolit nastavením určitých proměnných prostředí. Pro projekty s jedním kontejnerem je MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLEDproměnná prostředí , která se pak přihlásí %tmp%\Microsoft.VisualStudio.Containers.Tools. Pro projekty Docker Compose je to MS_VS_DOCKER_TOOLS_LOGGING_ENABLED, který se pak přihlásí %tmp%\Microsoft.VisualStudio.DockerCompose.Tools.

Upozornění

Pokud je protokolování povolené a pro ověřování Azure používáte proxy tokenů, přihlašovací údaje pro ověřování se můžou protokolovat jako prostý text. Viz Konfigurace ověřování Azure.

Vstupní bod kontejneru

Visual Studio používá vlastní vstupní bod kontejneru v závislosti na typu projektu a operačním systému kontejneru. Tady jsou různé kombinace:

Typ kontejneru	Vstupní bod
Kontejnery Linuxu	Vstupní bod je tail -f /dev/null, což je nekonečné čekání, aby kontejner běžel. Když se aplikace spustí prostřednictvím ladicího programu, je to ladicí program, který zodpovídá za spuštění aplikace (to znamená dotnet webapp.dll). Pokud se spustí bez ladění, nástroj spustí docker exec -i {containerId} dotnet webapp.dll aplikaci.
Kontejnery Windows	Vstupní bod je něco jako C:\remote_debugger\x64\msvsmon.exe /noauth /anyuser /silent /nostatus spuštění ladicího programu, takže naslouchá připojením. Tato metoda se použije, když ladicí program spustí aplikaci. Při spuštění bez ladění docker exec se použije příkaz. U webových aplikací rozhraní .NET Framework se vstupní bod mírně liší tím, kde ServiceMonitor se přidá do příkazu.

Vstupní bod kontejneru lze upravovat pouze v projektech Docker Compose, nikoli v projektech s jedním kontejnerem.

Aplikace s povoleným protokolem SSL ASP.NET Core

Nástroje pro kontejnery v sadě Visual Studio podporují ladění základní aplikace s povoleným protokolem SSL ASP.NET certifikátem pro vývoj, stejně jako byste očekávali, že bude fungovat bez kontejnerů. Aby k tomu došlo, Visual Studio přidá několik dalších kroků k exportu certifikátu a zpřístupnění kontejneru. Tady je tok, který sada Visual Studio zpracovává za vás při ladění v kontejneru:

1. Zajišťuje, že je místní vývojový certifikát přítomný a důvěryhodný na hostitelském počítači prostřednictvím dev-certs tohoto nástroje.

2. Exportuje certifikát do %APPDATA%\ASP.NET\Https zabezpečeného hesla uloženého v úložišti tajných kódů uživatele pro tuto konkrétní aplikaci.

3. Svazky připojí následující adresáře:

   • *%APPDATA%\Microsoft\UserSecrets
   • *%APPDATA%\ASP.NET\Https

ASP.NET Core hledá certifikát, který odpovídá názvu sestavení ve složce Https , a proto je namapovaný na kontejner v této cestě. Cestu k certifikátu a heslo je možné také definovat pomocí proměnných prostředí (to znamená ASPNETCORE_Kestrel__Certificates__Default__Path a ASPNETCORE_Kestrel__Certificates__Default__Password) nebo v souboru JSON tajných kódů uživatele, například:

{
  "Kestrel": {
    "Certificates": {
      "Default": {
        "Path": "c:\\app\\mycert.pfx",
        "Password": "strongpassword"
      }
    }
  }
}

Pokud vaše konfigurace podporuje kontejnerizované i nekonte kontejnerizované sestavení, měli byste použít proměnné prostředí, protože cesty jsou specifické pro prostředí kontejneru.

Další informace o používání SSL s aplikacemi ASP.NET Core v kontejnerech najdete v tématu Hostování imagí ASP.NET Core pomocí Dockeru přes HTTPS.

Ukázka kódu, která demonstruje vytvoření vlastních certifikátů pro aplikaci s více službami, která je na hostiteli a v kontejnerech pro komunikaci mezi službami HTTPS, najdete v tématu CertExample.

Související obsah

• Vlastnosti nástroje MSBuild pro projekty kontejnerů
• MSBuild
• Dockerfile ve Windows
• Kontejnery Linuxu ve Windows