Images officielles .NET Docker
Conseil
Ce contenu est un extrait du livre électronique « .NET Microservices Architecture for Containerized .NET Applications », disponible sur .NET Docs ou sous forme de PDF téléchargeable gratuitement et pouvant être lu hors ligne.
Les images officielles .NET Docker sont des images Docker créées et optimisées par Microsoft. Ils sont disponibles publiquement dans le Registre des artefacts Microsoft. Vous pouvez effectuer une recherche dans le catalogue pour trouver tous les référentiels d’images .NET, par exemple le référentiel du kit de développement logiciel (SDK) .NET.
Chaque référentiel peut contenir plusieurs images, en fonction des versions de .NET, du système d’exploitation et de ses versions (Linux Debian, Linux Alpine, Windows Nano Server, Windows Server Core, etc.). Les référentiels d’images fournissent un étiquetage complet, ce qui vous permet de sélectionner non seulement une version de framework spécifique, mais aussi un système d’exploitation (distribution Linux ou version de Windows).
Optimisations d’images .NET et Docker pour le développement et la production
Au moment de créer des images Docker pour développeurs, Microsoft s’est concentré sur les principaux scénarios suivants :
Images utilisées pour développer et générer des applications .NET
Images utilisées pour exécuter des applications .NET
Pourquoi plusieurs images ? En règle générale, vos propriétés varient selon que vous développez, générez ou exécutez des applications en conteneur. En proposant des images différentes en fonction des tâches, Microsoft permet d’optimiser ces processus distincts que sont le développement, la génération et le déploiement d’applications.
En phase de développement et de génération
En phase de développement, il importe d’itérer rapidement les modifications et de pouvoir les déboguer. La taille de l’image est moins importante que la possibilité d’apporter des modifications à votre code et de voir rapidement ces modifications. Certains outils et « conteneurs d’agent de build » utilisent l’image .NET de développement (mcr.microsoft.com/dotnet/sdk:8.0) lors du processus de développement et de génération. Ce qui importe au moment de générer à l’intérieur d’un conteneur Docker, ce sont les éléments nécessaires à la compilation de l’application. Il s’agit notamment du compilateur et des autres dépendances .NET.
Une autre excellente option est celle des conteneurs de développement. Ces conteneurs sont des environnements de développement prédéfinis prêts à l’emploi — vous n’avez pas à vous soucier des dépendances et des configurations. Ils sont également faciles à personnaliser pour inclure des outils ou dépendances supplémentaires. Les conteneurs de développement offrent une configuration cohérente et reproductible qui est facile à partager avec votre équipe. Les conteneurs de développement sont conformes à la Spécification des conteneurs de développement, et de nombreux outils de développement populaires, dont Visual Studio Code et GitHub Codespaces, les prennent en charge. Les conteneurs de développement .NET sont basés sur l’image SDK .NET et incluent le SDK .NET, le runtime, et d’autres outils nécessaires pour développer des applications .NET.
Pourquoi ce type d’image de build est-il important ? Vous ne déployez pas cette image en production. En effet, il s’agit d’une image que vous utilisez pour générer le contenu que vous placez dans une image de production. Cette image est destinée à être utilisée dans votre environnement d’intégration continue (CI) ou votre environnement de génération quand vous utilisez des builds Docker à plusieurs phases.
En production
Ce qui importe en production, c’est la vitesse à laquelle vous pouvez déployer et démarrer vos conteneurs basés sur une image .NET de production. L’image de runtime uniquement basée sur mcr.microsoft.com/dotnet/aspnet:8.0 est donc suffisamment petite pour transiter rapidement sur le réseau à partir de votre registre Docker vers vos hôtes Docker. Le contenu est prêt à s’exécuter, ce qui permet d’écourter au maximum la durée entre le démarrage du conteneur et le traitement des résultats. Dans le modèle Docker, il n’est pas nécessaire de compiler à partir de code C# comme c’est le cas lorsque vous exécutez la commande dotnet build ou dotnet publish en utilisant le conteneur de build.
Dans cette image optimisée, vous placez uniquement les fichiers binaires et le reste du contenu nécessaire à l’exécution de l’application. Par exemple, le contenu créé par la commande dotnet publish contient uniquement les fichiers binaires .NET compilés, des images et des fichiers .js et .css. Au fil du temps, vous verrez des images qui contiennent des packages prétraités avec JIT (la compilation du langage intermédiaire en code natif qui se produit à l’exécution).
Bien qu’il existe plusieurs versions des images .NET et ASP.NET Core, elles partagent toutes une ou plusieurs couches, dont la couche de base. Par conséquent, la quantité d’espace disque nécessaire au stockage d’une image est faible ; elle est uniquement constituée de la différence entre votre image personnalisée et son image de base. De ce fait, l’extraction de l’image de votre registre est très rapide.
En explorant les référentiels d’images .NET dans le Registre des artefacts Microsoft, vous trouverez plusieurs versions d’images classées ou étiquetées. Ces balises permettent d’identifier la version dont vous avez besoin, comme celles présentées dans le tableau suivant :
| Image | Commentaires |
|---|---|
| mcr.microsoft.com/dotnet/aspnet:8.0 | ASP.NET Core, avec le runtime uniquement et les optimisations ASP.NET Core, Linux et Windows (multi-arch) |
| mcr.microsoft.com/dotnet/sdk:8.0 | .NET 8, avec les SDK inclus, sur Linux et Windows (multiarchitecture) |
Vous trouverez toutes les images Docker disponibles dans dotnet-docker. Reportez-vous également aux dernières préversions à l’aide de la build nocturne mcr.microsoft.com/dotnet/nightly/*.
