.NET-Containerimages

  • Artikel

.NET stellt verschiedene Containerimages für verschiedene Szenarien bereit. In diesem Artikel werden die verschiedenen Arten von Bildern und deren Verwendung beschrieben. Weitere Informationen zu offiziellen Images finden Sie im Docker Hub: Microsoft .NET-Repository.

Taggingschema

Ab .NET 8 sind Containerimages pragmatischer, wenn sie differenziert werden. Die folgenden Merkmale werden verwendet, um Bilder zu unterscheiden:

  • Der Zielframeworkmoniker (TFM) der Anwendung.
  • Das Betriebssystem, die Version und die Architektur.
  • Der Bildtyp (z. B. runtime, aspnet, sdk).
  • Die Bildvariante (z. B. *-distroless, *-chiseled).
  • Das Bildfeature (z. B. *-aot, *-extra).

Für die Größe optimierte Bilder

Die folgenden Bilder konzentrieren sich auf das Ergebnis der kleinsten möglichen Bildgröße:

  • Alpine
  • Mariner distanzlos
  • Ubuntu gezeißelt

Diese Bilder sind kleiner, da sie keine Globalisierungsabhängigkeiten wie ICU oder tzdata enthalten. Diese Bilder funktionieren nur mit Anwendungen, die für den invarianten Modus der Globalisierung konfiguriert sind. Um eine Anwendung für die invariante Globalisierung zu konfigurieren, fügen Sie der Projektdatei die folgende Eigenschaft hinzu:

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

Tipp

SDK-Images werden nicht für *-distroless oder *-chiseled-Bildtypen erstellt. Zusammengesetzte Bilder sind das kleinste aspnet-Angebot für Core CLR.

Bilder, die für die Globalisierung geeignet sind

Containerisierte Anwendungen, die Globalisierung erfordern, vergrößern die Bildgröße, da sie Globalisierungsabhängigkeiten erfordern. Ubuntu- und Debian-Bilder haben ICU und tzdata bereits installiert.

Die Abhängigkeit von tzdata wurde den folgenden Bildern hinzugefügt:

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

Diese Globalisierungstaktik wird von runtime, aspnet und sdk-Bildern mit demselben Tag verwendet.

Wichtig

Das Hinzufügen von tzdata zu Debian-Bookworm-Images hat keine praktische Wirkung, es sei denn, es gibt ein Update zu tzdata (das noch nicht in Debian enthalten ist), an dem .NET-Bilder einen neueren tzdata enthalten würden.

Einige Pakete sind weiterhin optional, z. B. Kerberos, LDAP und msquic. Diese Pakete sind nur in Nischenszenarien erforderlich.

Szenariobasierte Bilder

Die Runtime-Deps-Images weisen einen erheblichen Wert auf, insbesondere da sie eine Standardbenutzer- und Portdefinition enthalten. Sie sind praktisch für eigenständige und systemeigene AOT-Szenarien zu verwenden. Die ausschließliche Bereitstellung von runtime-deps-Bildern, die von Laufzeit- und sdk-Bildern benötigt werden, reicht jedoch nicht aus, um alle denkbaren Szenarien zu ermöglichen oder optimale Bilder zu generieren.

Die Notwendigkeit runtime-depserstreckt sich auch auf native AOT*-distroless- und *-chiseled-Bildtypen. Für jedes Betriebssystem werden drei Bildvarianten bereitgestellt (alle in runtime-deps). Betrachten Sie das folgende Beispiel mit *-chiseled-Bildern:

  • 8.0-jammy-chiseled: Bilder für Core CLR, keine tzdata oder ICU.
  • 8.0-jammy-chiseled-aot: Bilder für systemeigene AOT, keine tzdata, ICU oder stdc++.
  • 8.0-jammy-chiseled-extra: Bild für Core CLR und native AOT, umfasst tzdata, ICU und stdc++.

Was die Szenarien betrifft:

Die 8.0-jammy-chiseled-Bilder sind die Basis für runtime und aspnet-Bilder desselben Tags. Standardmäßig können systemeigene AOT-Anwendungen das 8.0-jammy-chiseled-aot-Bild verwenden, da es für die Größe optimiert ist. Native AOT-Anwendungen und eigenständige/einzelne Dateianwendungen mit Core CLR, die Globalisierungsfunktionen erfordern, können 8.0-jammy-chiseled-extra verwenden.

Alpine- und Mariner-Bilder verwenden das gleiche Schema.

Hinweis

Debian- und Ubuntu (ohne Chiseled) runtime-deps-Bilder weisen keine mehrere Varianten auf.

Native AOT-Containerimages

Native AOT-Bilder werden im Sdk-Repository veröffentlicht und mit dem -aot-Suffix markiert. Diese Bilder ermöglichen das Erstellen nativer AOT-Anwendungen. Sie werden für Distros mit übereinstimmenden runtime-deps:*-aot-Bildern erstellt. Diese Bilder sind groß, häufig doppelt so groß wie normale SDK-Bilder.

AOT-Bilder werden veröffentlicht für:

  • Alpine
  • Mariner
  • Ubuntu

Weitere Informationen finden Sie unter Bereitstellung von nativem AOT

Docker-Hubrepositorys

Alle offiziellen Microsoft-Images für .NET werden in der Microsoft-dotnet Docker Hub-Organisation veröffentlicht. Betrachten Sie die folgenden Repositorys.

.NET Stable Image Repositorys:

Image-Repository Abbildung
aspnet mcr.microsoft.com/dotnet/aspnet
monitor 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
Beispiele mcr.microsoft.com/dotnet/samples
SDK mcr.microsoft.com/dotnet/sdk

.NET Nightly Image Repositorys:

Image-Repository Abbildung
nightly mcr.microsoft.com/dotnet/nightly
nightly-aspnet mcr.microsoft.com/dotnet/nightly/aspnet
nightly-monitor-base mcr.microsoft.com/dotnet/nightly/monitor/base
nightly-monitor 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-Imagerepositorys:

Image-Repository Abbildung
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

Siehe auch