Sdílet prostřednictvím

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í .NET SDK 8.0.200 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ů .NET CLI můžete na příkazovém řádku zadat vlastnosti MSBuild. 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.

Spropitné

Pokud chcete pomoct s řešením potíží, zvažte použití protokolů MSBuid. Pokud chcete vygenerovat soubor binárního protokolu (binlog), přidejte do příkazu -bl přepínač dotnet publish. Soubory binlogu jsou užitečné pro diagnostiku problémů sestavení a lze je otevřít v prohlížeči strukturovaných protokolů nástroje MSBuild. Poskytují podrobné trasování procesu sestavení, které je nezbytné pro analýzu nástroje MSBuild. Další informace naleznete v tématu Řešení potíží a vytváření protokolů pro MSBuild.

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 dále prostřednictvím DOCKER_CONFIG proměnné, která odkazuje na adresář obsahující config.json soubor.

Druhy ověřování

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

Explicitní uživatelské jméno a heslo

Oddíl auths souboru config.json je mapa klíč/hodnota mezi názvy registru a řetězcem 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

Část credHelpers souboru config.json je mapa klíč/hodnota mezi názvy registru a názvy konkrétních programů, které je možné 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 docker-credential-{name}aplikaci s názvem PATH . 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.

Poznámka

Od verze .NET SDK 8.0.400 byly aktualizovány proměnné prostředí pro operace kontejneru. Proměnné SDK_CONTAINER_* jsou nyní opatřeny předponou DOTNET_CONTAINER_*.

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 nemá prostor jmen – pokusí se použít stejné přihlašovací údaje pro zdrojový registr (kde se nachází základní image) i cílový registr (kam odesíláte finální image).

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.

Dokař

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"
  ]
}

Poznámka

Chcete-li použít všechny změny v tomto souboru, je nutné restartovat proces démona Dockeru.

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

Poznámka

Je nutné restartovat Podman, aby se všechny změny v souboru registries.conf projevily .

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

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 odesílaná rozhraním příkazového řádku .NET CLI, ale používají stejné mechanismy a důležité je, že dodržuje 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.

Inferenční telemetrie

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

Datový bod Vysvětlení Ukázková hodnota
InferencePerformed Pokud uživatelé ručně zadávají základní obrazy oproti využívání odvozování. true
TargetFramework Při inferenci základního obrázku se zvolí TargetFramework. net8.0
BaseImage Hodnota zvoleného základního obrazu, ale pouze pokud je tento základní obraz jedním z obrazů vytvořených společností Microsoft. Pokud uživatel na mcr.microsoft.com určí jinou image než image vytvořené Microsoftem, bude tato hodnota null. mcr.microsoft.com/dotnet/aspnet
BaseImageTag Hodnota vybrané značky, ale pouze v případě, že je tato značka určená pro jednu z obrázků vytvořených Microsoftem. Pokud uživatel na mcr.microsoft.com určí jinou image než image vytvořené Microsoftem, bude tato hodnota null. 8.0
ContainerFamily Hodnota vlastnosti ContainerFamily, pokud uživatel použil funkci ContainerFamily k výběru příchutě jedné z našich základních imagí. Tato možnost je nastavená pouze v případě, že uživatel vybral nebo odvozoval jednu z imagí .NET vytvořených Microsoftem z mcr.microsoft.com jammy-chiseled
ProjectType Druh projektu, který se kontejnerizuje. AspNetCore nebo Console
PublishMode Způsob zabalení aplikace Aot, Trimmed, SelfContainednebo FrameworkDependent
IsInvariant Pokud zvolený obrázek vyžaduje invariantní globalizaci nebo se uživatel k němu přihlásil ručně. true
TargetRuntime Identifikátor RID, pro který byla tato aplikace publikovaná. linux-x64

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:

Datový bod Vysvětlení Ukázková hodnota
RemotePullType Pokud základní image pochází ze vzdáleného registru, jaký druh registru byl? Azure, AWS, Google, GitHub, DockerHub, MRC nebo jiné
LocalPullType Pokud základní image pochází z místního zdroje, jako je démon kontejneru nebo tarball. Docker, Podman, Tarball
RemotePushType Pokud se image odeslala do vzdáleného registru, jaký je typ registru? Azure, AWS, Google, GitHub, DockerHub, MRC nebo jiné
LocalPushType Pokud byl obraz přenesen do místního cíle, co přesně to bylo? Docker, Podman, Tarball

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á:

Datový bod Vysvětlení Ukázková hodnota
Error Druh chyby, ke které došlo unknown_repository, credential_failure, rid_mismatch. local_load
Direction Pokud se jedná o chybu credential_failure, bylo to do push nebo pull registru? push
Cílový RID Pokud došlo k chybě rid_mismatch, o jaké identifikátory RID se požádalo. linux-x64
Dostupné identifikátory RID Pokud došlo k chybě rid_mismatch, jaké RID podporoval základní obraz? linux-x64,linux-arm64

Viz také

  • Last updated on