Přehled vytváření kontejnerů sady .NET SDK
I když je možné
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 natrue
. Tato vlastnost je implicitně nastavena natrue
pro spustitelné typy projektů, jako jsouconsole
,webapp
aworker
. -
EnableSdkContainerSupport
: Nastavtetrue
, 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
.
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 dotnet publish
přepínač -bl
. Soubory binlogu jsou užitečné pro diagnostiku problémů sestavení a lze je otevřít v PROHLÍŽEČ strukturovaného protokolu 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 nástroj MSBuild.
Publikování profilů a cílů
Při použití dotnet publish
můž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 PATH
aplikaci 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.
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 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"
]
}
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 změny projevily v souboru registries.conf.
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 , 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:
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 , SelfContained nebo 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 |