Přehled vytváření kontejnerů sady .NET SDK

I když je možné kontejnerizovat aplikace .NET pomocísouboru Dockerfile , existují přesvědčivé důvody pro kontejnerizaci aplikací přímo se sadou .NET SDK. Tento článek obsahuje přehled funkce vytváření kontejnerů sady .NET SDK s podrobnostmi souvisejícími s telemetrií, aspekty publikování, vlastnostmi sestavení a ověřováním v registrech kontejnerů.

Aspekty publikování projektu

Teď, když máte aplikaci .NET, ji můžete publikovat jako kontejner. Než to uděláte, je potřeba vzít v úvahu několik důležitých aspektů. Před verzí 8.0.200 sady .NET SDK jste potřebovali balíček NuGet 📦 Microsoft.NET.Build.Containers. Tento balíček se nevyžaduje pro sadu .NET SDK verze 8.0.200 a novější, protože podpora kontejnerů je ve výchozím nastavení zahrnutá.

K povolení publikování aplikace .NET jako kontejneru se vyžadují následující vlastnosti sestavení:

• IsPublishable: Nastaveno na true. Tato vlastnost je implicitně nastavena na true pro spustitelné typy projektů, jako jsou console, webappa worker.
• EnableSdkContainerSupport: Nastavte true, pokud je typ projektu konzolovou aplikací.

Pokud chcete explicitně povolit podporu kontejneru sady SDK, zvažte následující fragment kódu souboru projektu:

<PropertyGroup>
  <IsPublishable>true</IsPublishable>
  <EnableSdkContainerSupport>true</EnableSdkContainerSupport>
</PropertyGroup>

Zveřejnění přepínačů a vlastností sestavení

Stejně jako u všech příkazů rozhraní příkazového řádku .NET CLI můžete zadat vlastnosti MSBuild na příkazovém řádku. K dispozici je mnoho platných formulářů syntaxe pro poskytování vlastností, například:

• /p:PropertyName=Value
• -p:PropertyName=Value
• -p PropertyName=Value
• --property PropertyName=Value

Je na vás, kterou syntaxi použijete, ale dokumentace uvádí příklady s použitím formátu -p.

Publikování profilů a cílů

Při použití dotnet publishmůže zadání profilu s -p PublishProfile=DefaultContainer nastavit vlastnost, která způsobí, že SDK po procesu publikování aktivuje další cíl. Jedná se o nepřímý způsob dosažení požadovaného výsledku. Na druhou stranu použití dotnet publish /t:PublishContainer přímo vyvolá cíl PublishContainer, aby se dosáhlo stejného výsledku, ale jednodušším způsobem.

Jinými slovy, následující příkaz .NET CLI:

dotnet publish -p PublishProfile=DefaultContainer

Která nastaví vlastnost PublishProfile na DefaultContainer, je ekvivalentní následujícímu příkazu:

dotnet publish /t:PublishContainer

Rozdíl mezi těmito dvěma metodami spočívá v tom, že první používá profil k nastavení vlastnosti, zatímco druhý přímo vyvolá cíl. Důvodem je, že profily jsou funkcí nástroje MSBuild a dají se použít k nastavení vlastností složitějším způsobem, než jen k jejich přímému nastavení.

Jedním z klíčových problémů je, že ne všechny typy projektů podporují profily nebo mají k dispozici stejnou sadu profilů. Kromě toho existuje rozdíl v úrovni podpory profilů mezi různými nástroji, jako je Visual Studio a .NET CLI. Proto je použití cílů obecně jasnější a obecněji podporovanou metodou dosažení stejného výsledku.

Ověřte se v registrech kontejnerů

Interakce s privátními registry kontejnerů vyžaduje ověření s těmito registry.

Docker má s tím vytvořený vzor prostřednictvím příkazu docker login, což je způsob interakce s konfiguračním souborem Dockeru, který obsahuje pravidla pro ověřování v konkrétních registrech. Tento soubor a typy ověřování, které kóduje, podporuje Microsoft.Net.Build.Containers pro ověřování registru. To by mělo zajistit, aby tento balíček bez problémů fungoval s libovolným registrem, ze kterého můžete docker pull a docker push. Tento soubor je obvykle uložen v ~/.docker/config.json, ale lze jej zadat dodatečně prostřednictvím proměnné DOCKER_CONFIG, která odkazuje na adresář obsahující config.json soubor.

Druhy ověřování

Soubor config.json obsahuje tři typy ověřování:

• explicitní uživatelské jméno a heslo
• pomocné programy pro přihlašovací údaje
• systémový řetězec klíčů

Explicitní uživatelské jméno a heslo

Oddíl auths souboru config.json je mapa klíč/hodnota mezi názvy registru a řetězci username:password s kódováním Base64. V běžném scénáři Dockeru spuštění docker login <registry> -u <username> -p <password> vytvoří v této mapě nové položky. Tyto přihlašovací údaje jsou oblíbené v systémech kontinuální integrace (CI), kde se přihlašování provádí pomocí tokenů na začátku spuštění. Jsou ale méně oblíbené pro vývojářské počítače pro koncové uživatele kvůli bezpečnostnímu riziku přítomnosti nezabezpečených přihlašovacích údajů v souboru.

Pomocníci pro přihlašovací údaje

Oddíl credHelpers souboru config.json je mapa klíč/hodnota mezi názvy registru a názvy konkrétních programů, které lze použít k vytvoření a načtení přihlašovacích údajů pro tento registr. To se často používá v případě, že konkrétní registry mají složité požadavky na ověřování. Aby tento typ ověřování fungoval, musíte mít v systému PATHaplikaci s názvem docker-credential-{name} . Tyto typy přihlašovacích údajů jsou obvykle zabezpečené, ale může být obtížné nastavit na počítačích s vývojem nebo CI.

Systémové klíčenky

Oddíl credsStore je jedna řetězcová vlastnost, jejíž hodnotou je název pomocného programu přihlašovacích údajů Dockeru, který ví, jak používat rozhraní se správcem hesel systému. Pro Windows to může být například wincred. Jsou oblíbené u instalačních programů Dockeru pro macOS a Windows.

Ověřování prostřednictvím proměnných prostředí

V některých scénářích standardní autentizační mechanismus Dockeru prostě nestačí. Tento nástroj má další mechanismus pro poskytování přihlašovacích údajů registrům: proměnné prostředí. Pokud se použijí proměnné prostředí, mechanismus poskytnutí přihlašovacích údajů se vůbec nepoužije. Podporovány jsou následující proměnné prostředí:

• DOTNET_CONTAINER_REGISTRY_UNAME: Toto by mělo být uživatelské jméno registru. Pokud je heslo registru tokenem, uživatelské jméno by mělo být "<token>".
• DOTNET_CONTAINER_REGISTRY_PWORD: Mělo by se jednat o heslo nebo token registru.

Tento mechanismus je potenciálně zranitelný vůči úniku přihlašovacích údajů, takže by se měl používat jenom ve scénářích, kdy jiný mechanismus není dostupný. Pokud například používáte nástroje kontejneru sady SDK v samotném kontejneru Dockeru. Kromě toho tento mechanismus není oddělený – snaží se použít stejné přihlašovací údaje pro zdrojový registr (kde se nachází základní obraz) a cílový registr (kam odesíláte finální obraz).

Použití nezabezpečených registrů

Většina přístupu k registru se předpokládá, že je zabezpečená, což znamená, že k interakci s registrem se používá PROTOKOL HTTPS. Ne všechny registry jsou však nakonfigurované s certifikáty TLS – zejména v situacích, jako je privátní podnikový registr za vpn. Nástroje kontejnerů, které podporují tyto případy použití, poskytují způsoby deklarování, že konkrétní registr používá nezabezpečenou komunikaci.

Počínaje verzí .NET 8.0.400 sada SDK rozumí těmto konfiguračním souborům a formátům a automaticky tuto konfiguraci použije k určení, jestli se má použít protokol HTTP nebo HTTPS. Konfigurace registru pro nezabezpečenou komunikaci se liší podle zvoleného nástroje kontejneru.

Docker

Docker ukládá konfiguraci registru v konfiguraci démona . Pokud chcete přidat nové nezabezpečené registry, do vlastnosti pole "insecure-registries" se přidají noví hostitelé:

{
  "insecure-registries": [
    "registry.mycorp.net"
  ]
}

Podman

Podman používá k ukládání informací o připojení registru soubor registries.conf TOML. Tento soubor obvykle žije v /etc/containers/registries.conf. Pokud chcete přidat nové nezabezpečené registry, přidá se oddíl TOML pro uložení nastavení registru a pak musí být možnost insecure nastavena na true.

[[registry]]
location = "registry.mycorp.net"
insecure = true

Proměnné prostředí

Počínaje verzí 9.0.100 sada .NET SDK rozpozná nezabezpečené registry předávané prostřednictvím proměnné prostředí DOTNET_CONTAINER_INSECURE_REGISTRIES. Tato proměnná přebírá čárkami oddělený seznam domén, které se považují za nezabezpečené stejným způsobem jako výše uvedené příklady Dockeru a Podmanu.

$Env:DOTNET_CONTAINER_INSECURE_REGISTRIES=localhost:5000,registry.mycorp.com; dotnet publish -t:PublishContainer -p:ContainerRegistry=registry.mycorp.com -p:ContainerBaseImage=localhost:5000/dotnet/runtime:9.0

DOTNET_CONTAINER_INSECURE_REGISTRIES=localhost:5000,registry.mycorp.com dotnet publish -t:PublishContainer -p:ContainerRegistry=registry.mycorp.com -p:ContainerBaseImage=localhost:5000/dotnet/runtime:9.0

Telemetrie

Když publikujete aplikaci .NET jako kontejner, nástroje pro kontejner .NET SDK shromáždí a posílají telemetrická data o využití, jak se nástroje používají. Shromážděná data jsou kromě telemetrie , která je odesílána prostřednictvím .NET CLI, ale používají stejné mechanismy a důležité je, že dodržují stejné ovládací prvky odhlášení.

Shromážděná telemetrie je určena k zachování obecné povahy a neprozrazení žádných osobních informací – zamýšleným účelem je pomoci měřit:

• Celkové využití funkce kontejnerizace sady .NET SDK
• Míra úspěšnosti a selhání spolu s obecnými informacemi o tom, k jakým druhům selhání dochází nejčastěji.
• Použití konkrétních funkcí technologie, jako je publikování do různých druhů registru nebo způsob vyvolání publikování.

Pokud chcete vyjádřit výslovný nesouhlas s telemetrií, nastavte proměnnou prostředí DOTNET_CLI_TELEMETRY_OPTOUT na true. Další informace najdete v tématu telemetrie rozhraní příkazového řádku .NET CLI.

Inferenční telemetrie

Protokoluje se následující informace o tom, jak došlo k procesu odvození základní image:

Telemetrie vytváření obrázků

Do protokolu se zaprotokolují následující informace o tom, jak došlo k vytvoření a publikování kontejneru:

Kromě toho, pokud během procesu shromažďování dat dochází k různým druhům chyb, o jaký druh chyby se jedná:

Viz také

• Publikování aplikací .NET jako kontejnerů
• Kontejnerizace odkazu na aplikaci .NET