Dela via

.NET-containeravbildningar

  • Artikel

.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 avbildningar finns i Docker Hub: Microsoft .NET-lagringsplatsen .

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:

  • Målramverkets moniker (TFM) för appen.
  • 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:

  • Alpine
  • Mariner distroless
  • Ubuntu mejslad

De här bilderna är mindre eftersom de inte innehåller globaliseringsberoenden som ICU eller tzdata. Dessa bilder fungerar bara med appar som är konfigurerade för globalisering i variant 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>

Dricks

SDK-avbildningar produceras inte för *-distroless eller *-chiseled avbildningstyper. 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.

Viktigt!

Att lägga till tzdata i Debians bokmaskbilder har ingen praktisk effekt, såvida det inte finns en uppdatering av tzdata (som ännu inte ingår i Debian), då .NET-avbildningar 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-avbildningarna 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 avbildningar som behövs av körnings- och sdk-avbildningarna räcker dock inte för att aktivera alla tänkbara scenarier eller generera optimala avbildningar.

Behovet av runtime-deps utökas även till interna AOT *-distroless- och *-chiseled bildtyper. För varje operativsystem tillhandahålls tre avbildningsvarianter (alla i runtime-deps). Överväg följande exempel med hjälp av *-chiseled bilder:

  • 8.0-jammy-chiseled: Bilder för Core CLR, inga 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:

Bilderna 8.0-jammy-chiseled är bas för runtime och aspnet bilder av samma tagg. Som standard kan interna AOT-appar använda avbildningen eftersom den 8.0-jammy-chiseled-aot är optimerad för storlek. Interna AOT-appar och core CLR-fristående/enfilsappar som kräver globaliseringsfunktioner kan använda 8.0-jammy-chiseled-extra.

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

Kommentar

Debian- och Ubuntu-bilder (icke-mejslade) runtime-deps har inte flera varianter.

Interna AOT-containeravbildningar

Interna AOT-avbildningar publiceras till sdk-lagringsplatsen och taggas med suffixet -aot . 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:

  • Alpine
  • Mariner
  • Ubuntu

Mer information finns i Intern AOT-distribution

Docker Hub-lagringsplatser

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

.NET-stabila avbildningsdatabaser:

Avbildningslagringsplats Bild
Aspnet mcr.microsoft.com/dotnet/aspnet
Övervaka mcr.microsoft.com/dotnet/monitor
monitor-base mcr.microsoft.com/dotnet/monitor/base
runtime-deps mcr.microsoft.com/dotnet/runtime-deps
Runtime mcr.microsoft.com/dotnet/runtime
Prover mcr.microsoft.com/dotnet/samples
Sdk mcr.microsoft.com/dotnet/sdk

.NET-lagringsplatser för nattliga avbildningar:

Avbildningslagringsplats Bild
Nattliga mcr.microsoft.com/dotnet/nightly
nightly-aspnet mcr.microsoft.com/dotnet/nightly/aspnet
nightly-monitor-base mcr.microsoft.com/dotnet/nightly/monitor/base
nattövervakare mcr.microsoft.com/dotnet/nightly/monitor
nightly-runtime-deps mcr.microsoft.com/dotnet/nightly/runtime-deps
nightly-runtime mcr.microsoft.com/dotnet/nightly/runtime
nightly-sdk mcr.microsoft.com/dotnet/nightly/sdk

.NET Framework-avbildningsdatabaser:

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

Se även