Images conteneur .NET

  • Article

.NET fournit différentes images conteneur pour différents scénarios. Cet article décrit les différents types d’images et leur utilisation. Pour plus d’informations sur les images officielles, consultez le référentiel Docker Hub : Microsoft .NET.

Schéma de balisage

À compter de .NET 8, les images conteneur sont plus pragmatiques dans la façon dont elles sont différenciées. Les caractéristiques suivantes sont utilisées pour différencier les images :

  • Le moniker de framework cible (TFM) de l’application.
  • Le système d’exploitation, la version et l’architecture.
  • Le type d’image (par exemple, runtime, aspnet, sdk).
  • La variante d’image (par exemple, *-distroless, *-chiseled).
  • La fonctionnalité d’image (par exemple, *-aot, *-extra).

Images optimisées pour la taille

Les images suivantes se concentrent sur la taille d’image la plus petite possible :

  • Alpine
  • Mariner minimaliste
  • Ubuntu épuré

Ces images sont plus petites, car elles n’incluent pas de dépendances de globalisation telles que ICU ou tzdata. Ces images fonctionnent uniquement avec les applications configurées pour le mode invariant de globalisation. Pour configurer une application en vue d’une globalisation invariante, ajoutez la propriété suivante au fichier projet :

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

Conseil

Les images du Kit de développement logiciel (SDK) ne sont pas produites pour les types d’images *-distroless ou *-chiseled. Les images composites représentent la plus petite offre aspnet pour Core CLR.

Images adaptées à la globalisation

Les applications conteneurisées qui nécessitent la globalisation augmentent la taille de l’image, car elles nécessitent des dépendances de globalisation. ICU et tzdata sont déjà installés dans les images Ubuntu et Debian.

La dépendance tzdata a été ajoutée aux images suivantes :

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

Cette tactique de globalisation est utilisée par les images runtime, aspnetet sdk avec la même balise.

Important

L’ajout de tzdata aux images de bookworm Debian n’a aucun effet pratique, sauf s’il existe une mise à jour de tzdata (qui n’est pas encore incluse dans Debian), auquel cas les images .NET incluraient une nouvelle version de tzdata.

Certains packages sont toujours facultatifs, tels que Kerberos, LDAP et msquic. Ces packages sont uniquement requis dans les scénarios de niche.

Images basées sur des scénarios

Les images runtime-deps ont une valeur significative, en particulier dans la mesure où elles incluent des définitions d’utilisateur et de port standard. Elles sont pratiques à utiliser pour les scénarios AOT autonomes et natifs. Toutefois, la seule fourniture d’images runtime-deps requises par le runtime et les images du Kit de développement logiciel (SDK) n’est pas suffisante pour activer tous les scénarios imaginables ou générer des images optimales.

La nécessité de runtime-deps s’étend également aux types d’images natives AOT, *-distroless et *-chiseled. Pour chaque système d’exploitation, trois variantes d’image sont fournies (toutes en runtime-deps). Considérez l’exemple suivant à l’aide d’images *-chiseled :

  • 8.0-jammy-chiseled : images pour Core CLR, pas tzdata ou ICU.
  • 8.0-jammy-chiseled-aot : images pour AOT natif, pas tzdata, ICU ou stdc++.
  • 8.0-jammy-chiseled-extra : image pour Core CLR et AOT natif, inclut tzdata, ICU et stdc++.

En termes de scénarios :

Les images 8.0-jammy-chiseled servent de base aux images runtime et aspnet de la même balise. Par défaut, les applications AOT natives peuvent utiliser l’image 8.0-jammy-chiseled-aot, car sa taille est optimisée. Les applications AOT natives et les applications Core CLR autonomes/à fichier unique qui nécessitent une fonctionnalité de globalisation peuvent utiliser 8.0-jammy-chiseled-extra.

Les images Alpine et Mariner utilisent le même schéma.

Remarque

Les images runtime-deps Debian et Ubuntu (non épurées) n’ont pas plusieurs variantes.

Images conteneur AOT natives

Les images AOT natives sont publiées dans le référentiel du Kit de développement logiciel (SDK) et étiquetées avec le suffixe -aot. Ces images permettent de créer des applications AOT natives. Elles sont créées pour les distributions dont les images correspondent à runtime-deps:*-aot. Ces images sont volumineuses, généralement deux fois plus volumineuses que les images du Kit de développement logiciel (SDK) standard.

Les images AOT sont publiées pour :

  • Alpine
  • Mariner
  • Ubuntu

Pour plus d’informations, consultez Déploiement AOT natif

Référentiels Docker Hub

Toutes les images Microsoft officielles pour .NET sont publiées dans l’organisation Docker Hub microsoft-dotnet . Tenez compte des référentiels suivants.

Référentiels d’images stables .NET :

Référentiel d’images Image
sdk mcr.microsoft.com/dotnet/sdk
aspnet mcr.microsoft.com/dotnet/aspnet
runtime mcr.microsoft.com/dotnet/runtime
runtime-deps mcr.microsoft.com/dotnet/runtime-deps
monitor mcr.microsoft.com/dotnet/monitor
aspire-dashboard mcr.microsoft.com/dotnet/aspire-dashboard
Exemples mcr.microsoft.com/dotnet/samples

Référentiels d’images nocturnes .NET :

Référentiel d’images Image
nightly-aspnet mcr.microsoft.com/dotnet/nightly/aspnet
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
nightly-aspire-dashboard mcr.microsoft.com/dotnet/nightly/aspire-dashboard

Référentiels d’images .NET Framework :

Référentiel d’images Image
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

Voir aussi