.NET-containeravbildningar

Artikel
01/29/2025

.NET tillhandahåller olika containeravbildningar för olika scenarier. Den här artikeln beskriver de olika typerna av bilder och hur de används. Mer information om officiella bilder finns i Docker Hub: Microsoft .NET lagringsplats.

Taggningsschema

Från och med .NET 8 är containeravbildningar mer pragmatiska i hur de är differentierade. Följande egenskaper används för att särskilja bilder:

Appens målramverk (TFM).
Operativsystemet, versionen och arkitekturen.
Bildtypen (till exempel runtime, aspnet, sdk).
Bildvarianten (till exempel *-distroless, *-chiseled).
Bildfunktionen (till exempel *-aot, *-extra).

Bilder som är optimerade för storlek

Följande bilder fokuserar på att resultera i minsta möjliga bildstorlek:

Alpin
Mariner utan distribution
Ubuntu mejslad

Dessa bilder är mindre eftersom de inte innehåller globaliseringsberoenden som ICU eller tzdata. Dessa bilder fungerar bara med appar som är konfigurerade för globaliseringsinvariant läge. Om du vill konfigurera en app för invariant globalisering lägger du till följande egenskap i projektfilen:

<PropertyGroup>
  <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

Tips

SDK-avbildningar skapas inte för *-distroless eller *-chiseled bildtyper. Sammansatta avbildningar är det minsta aspnet erbjudandet för Core CLR.

Bilder som är lämpliga för globalisering

Containerbaserade appar som kräver globalisering blåser upp bildstorleken eftersom de kräver globaliseringsberoenden. Ubuntu- och Debianbilder har redan ICU och tzdata installerade.

Beroendet av tzdata lades till i följande bilder:

runtime-deps:8.0-jammy
runtime-deps:8.0-bookworm-slim

Den här globaliseringstaktiken används av runtime, aspnetoch sdk bilder med samma tagg.

Viktig

Att lägga till tzdata i Debians bookworm-bilder har ingen praktisk effekt, såvida det inte sker en uppdatering av tzdata (som ännu inte ingår i Debian), då .NET-bilder skulle innehålla en nyare tzdata.

Vissa paket är fortfarande valfria, till exempel Kerberos, LDAP och msquic. Dessa paket krävs endast i nischscenarier.

Scenariobaserade bilder

runtime-deps-avbildningar har ett betydande värde, särskilt eftersom de innehåller en standardanvändare och portdefinitioner. De är praktiska att använda för fristående och interna AOT-scenarier. Att endast tillhandahålla runtime-deps bilder som behövs av körningsmiljön och sdk bilder räcker dock inte för att aktivera alla tänkbara scenarier eller generera optimala bilder.

Behovet av runtime-deps omfattar även interna AOT-, *-distroless- och *-chiseled-avbildningstyper. För varje operativsystem tillhandahålls tre avbildningsvarianter (alla i runtime-deps). Tänk dig följande exempel med *-chiseled bilder:

8.0-jammy-chiseled: Bilder för Core CLR, utan tzdata eller ICU.
8.0-jammy-chiseled-aot: Bilder för intern AOT, inga tzdata, ICU eller stdc++.
8.0-jammy-chiseled-extra: Bild för både Core CLR och intern AOT, innehåller tzdata, ICU och stdc++.

När det gäller scenarier:

De 8.0-jammy-chiseled bilderna är basen för runtime och aspnet bilder av samma tagg. Som standard kan interna AOT-appar använda 8.0-jammy-chiseled-aot avbildningen, eftersom den är optimerad för storlek. Inhemska AOT-appar och fristående/enfilsapplikationer med Core CLR som kräver globaliseringsfunktion kan använda 8.0-jammy-chiseled-extra.

Alpine- och Mariner-avbildningar använder samma schema.

Not

Debian och Ubuntu (icke-mejslade) runtime-deps-bilder har inga fler varianter.

Ursprungs AOT-containeravbildningar

Interna AOT-avbildningar publiceras till lagringsplatsen sdk och taggas med -aot-suffixet. Dessa avbildningar gör det möjligt att skapa interna AOT-appar. De skapas för distributioner med matchande runtime-deps:*-aot bilder. Dessa bilder är stora, vanligtvis dubbelt så stora som vanliga SDK-avbildningar.

AOT-avbildningar publiceras för:

Alpin
Sjöman
Ubuntu

Mer information finns i intern AOT-distribution.

Docker Hub-lagringsplatser

Alla officiella Microsoft-avbildningar för .NET publiceras till organisationen microsoft-dotnet Docker Hub. Överväg följande lagringsplatser.

.NET-stabila bildlagringsplatser:

Avbildningslagringsplats	Bild
sdk	`mcr.microsoft.com/dotnet/sdk`
aspnet	`mcr.microsoft.com/dotnet/aspnet`
körtid	`mcr.microsoft.com/dotnet/runtime`
runtime-deps	`mcr.microsoft.com/dotnet/runtime-deps`
övervaka	`mcr.microsoft.com/dotnet/monitor`
aspire-dashboard	`mcr.microsoft.com/dotnet/aspire-dashboard`
exempel	`mcr.microsoft.com/dotnet/samples`

.NET-lagringsplatser för nattliga avbildningar:

Avbildningslagringsplats	Bild
nattetid	`mcr.microsoft.com/dotnet/nightly/aspnet`
nattlig-övervakning	`mcr.microsoft.com/dotnet/nightly/monitor`
nattliga drifttidsberoenden	`mcr.microsoft.com/dotnet/nightly/runtime-deps`
nattlig körtid	`mcr.microsoft.com/dotnet/nightly/runtime`
nightly-sdk	`mcr.microsoft.com/dotnet/nightly/sdk`
nightly-aspire-dashboard	`mcr.microsoft.com/dotnet/nightly/aspire-dashboard`

.NET Framework-bildlagringsplatser:

Avbildningslagringsplats	Bild
ramverk	`mcr.microsoft.com/dotnet/framework`
framework-aspnet	`mcr.microsoft.com/dotnet/framework/aspnet`
framework-runtime	`mcr.microsoft.com/dotnet/framework/runtime`
ramverksexempel	`mcr.microsoft.com/dotnet/framework/samples`
framework-sdk	`mcr.microsoft.com/dotnet/framework/sdk`
framework-wcf	`mcr.microsoft.com/dotnet/framework/wcf`

Dela via