Neuerungen an Containern in .NET 8

  • Artikel

In diesem Artikel werden neue Features für Containern in .NET 8 beschrieben.

Containerimages

Die folgenden Änderungen wurden an .NET-Containerimages für .NET 8 vorgenommen:

Nicht-Stammbenutzer

Images umfassen einen non-root-Benutzer. Dieser Benutzer macht die Images non-root-fähig. Um sie als non-root auszuführen, fügen Sie die folgende Zeile am Ende Ihrer Dockerfile (oder eine ähnliche Anweisung in Ihren Kubernetes-Manifesten) hinzu:

USER app

In .NET 8 wird eine Umgebungsvariable für die UID von non-root-Benutzer*innen hinzugefügt, die „64.198“ ist. Diese Umgebungsvariable ist nützlich für den Kubernetes runAsNonRoot-Test, der erfordert, dass der Containerbenutzer über die UID und nicht über den Namen festgelegt werden muss. Diese Dockerfile zeigt ein Beispiel für die Verwendung.

Der Standardport wurde außerdem von Port 80 in 8080 geändert. Um diese Änderung zu unterstützen, ist die neue Umgebungsvariable ASPNETCORE_HTTP_PORTS verfügbar, um den Wechsel von Ports zu erleichtern. Die Variable akzeptiert eine Liste von Ports, was einfacher ist, als das Format, das für ASPNETCORE_URLS erforderlich ist. Wenn Sie den Port mit einer dieser Variablen wieder auf Port 80 zurückändern, können Sie nicht als non-root ausführen.

Weitere Informationen finden Sie unter Änderung des Standard-ASP.NET Core-Ports von 80 in 8080 und Neuer Nicht-Root-Benutzer „App“ in Linux-Images.

Debian 12

Die Containerimages verwenden jetzt Debian 12 (Bookworm). Debian ist die Linux-Standarddistribution in den .NET-Containerimages.

Weitere Informationen finden Sie unter Upgrade von Debian-Containerimages auf Debian 12.

Gezeißelte Ubuntu-Images

„Gemeißelte“ (Schlanke) Ubuntu-Images sind für .NET 8 verfügbar. Gemeißelte Images haben eine verringerte Angriffsfläche, da sie extrem klein sind, keinen Paket-Manager und keine Shell besitzen und non-root sind. Diese Art von Image richtet sich an Entwickler, die den Vorteil des Computings im Appliance-Stil wünschen.

Chiseled-Images unterstützen die Globalisierung standardmäßig nicht. extra-Images werden bereitgestellt. Sie enthalten icu- und tzdata-Pakete.

Weitere Informationen zu Globalisierung und Containern finden Sie unter Test-App für die Globalisierung.

Erstellen von Containerimages für mehrere Plattformen

Docker unterstützt die Verwendung und Erstellung von Images für mehrere Plattformen, die in mehreren Umgebungen funktionieren. .NET 8 führt ein neues Muster ein, mit dem Sie Architekturen mit den von Ihnen erstellten .NET-Images kombinieren und abgleichen können. Wenn Sie beispielsweise macOS verwenden und einen x64-Clouddienst in Azure als Ziel verwenden möchten, können Sie das Image wie folgt mit der Option --platform erstellen:

docker build --pull -t app --platform linux/amd64

Das .NET SDK unterstützt jetzt $TARGETARCH-Werte und das -a-Argument bei der Wiederherstellung. Der folgende Codeausschnitt zeigt ein Beispiel:

RUN dotnet restore -a $TARGETARCH

# Copy everything else and build app.
COPY aspnetapp/. .
RUN dotnet publish -a $TARGETARCH --self-contained false --no-restore -o /app

Weitere Informationen finden Sie im Blogbeitrag ///Verbesserung der Unterstützung von Containern für mehrere Plattformen.

Zusammengesetzte ASP.NET-Images

Im Rahmen der Bemühungen zur Verbesserung der Containerisierungsleistung sind neue ASP.NET-Docker-Images mit einer zusammengesetzten Version der Runtime verfügbar. Diese Zusammensetzung wird erstellt, indem mehrere MSIL-Assemblys in einer einzelnen R2R-Ausgabebinärdatei (Ready-to-Run) kompiliert werden. Da diese Assemblys in ein einzelnes Image eingebettet sind, benötigt das JITting weniger Zeit, und die Startleistung von Apps verbessert sich. Der andere große Vorteil des zusammengesetzten gegenüber dem regulären ASP.NET-Image besteht darin, dass die zusammengesetzten Images auf dem Datenträger kleiner sind.

Es gibt einen zu beachtenden Vorbehalt. Da bei Zusammensetzungen mehrere Assemblys in eine eingebettet sind, weisen sie eine engere Versionskopplung auf. Apps können keine benutzerdefinierten Versionen von Framework- oder ASP.NET-Binärdateien verwenden.

Zusammengesetzte Images sind für die Plattformen Alpine Linux, Ubuntu („Jammy“) Chiseled und Mariner Distroless im Repository mcr.microsoft.com/dotnet/aspnet verfügbar. Die Tags werden auf der ASP.NET Docker-Seite mit dem Suffix -composite aufgeführt.

Containerveröffentlichung

Standardeinstellungen für generierte Bilder

dotnet publish kann Containerimages generieren. Standardmäßig werden non-root-Images generiert, sodass Ihre Apps standardmäßig sicher sind. Ändern Sie diese Standardeinstellung jederzeit, indem Sie die Eigenschaft ContainerUser festlegen, z. B. mit root.

Das standardmäßige Ausgabecontainertag ist jetzt latest. Dieser Standardwert entspricht anderen Tools im Containerbereich und erleichtert die Verwendung von Containern in inneren Entwicklungsschleifen.

Leistung und Kompatibilität

.NET 8 verfügt über eine verbesserte Leistung beim Pushen von Containern an Remoteregistrierungen, insbesondere an Azure-Registrierungen. Die Beschleunigung entsteht durch das Pushen von Ebenen in einem Vorgang und, für Registrierungen, die keine atomaren Uploads unterstützen, durch einen zuverlässigeren Blockerstellungsmechanismus.

Diese Verbesserungen führen auch dazu, dass mehr Registrierungen unterstützt werden: Harbor, Artifactory, Quay.io und Podman.

Authentifizierung

.NET 8 fügt Unterstützung für die OAuth-Tokenaustauschauthentifizierung (Azure Managed Identity) hinzu, wenn Container an Registrierungen übertragen werden. Diese Unterstützung bedeutet, dass Sie jetzt ohne Authentifizierungsfehler an Registrierungen wie Azure Container Registry per Push übertragen können. Die folgenden Befehle zeigen einen beispielhaften Veröffentlichungsfluss:

> az acr login -n <your registry name>
> dotnet publish -r linux-x64 -p PublishProfile=DefaultContainer

Weitere Informationen zum Containern von .NET-Apps finden Sie unter Containerize a .NET-App mit dotnet publish.

Im tar.gz-Archiv veröffentlichen

Ab .NET 8 können Sie einen Container direkt als Tar.gz-Archiv erstellen. Diese Funktion ist nützlich, wenn Ihr Workflow nicht einfach ist und erfordert, dass Sie beispielsweise ein Scantool über Ihre Bilder ausführen, bevor Sie diese pushen. Nachdem das Archiv erstellt wurde, können Sie es verschieben, scannen oder in eine lokale Docker-Toolkette laden.

Um sie in einem Archiv zu veröffentlichen, fügen Sie die ContainerArchiveOutputPath Eigenschaft zu Ihrem dotnet publish-Befehl hinzu, z. B.:

dotnet publish \
  -p PublishProfile=DefaultContainer \
  -p ContainerArchiveOutputPath=./images/sdk-container-demo.tar.gz

Sie können entweder einen Ordnernamen oder einen Pfad mit einem bestimmten Dateinamen angeben.

Siehe auch