Lors de la dernière édition de DockerCon, Microsoft a partagé plusieurs améliorations apportées au .NET Core au cours de l'année écoulée, toutes visant à améliorer l'expérience d'utilisation de .NET et de Docker ensemble.
Toutes les améliorations portaient sur .NET Core 3.0. Le changement le plus fondamental a été la réduction de la mémoire utilisée par défaut par le runtime .NET Core (CoreCLR). Le CoreCLR gère l'exécution de tous les programmes .NET Core; la mémoire qu'il utilise par défaut est la quantité de mémoire allouée initialement lorsqu'un programme .NET est exécuté. Réduire l'utilisation de la mémoire CoreCLR par défaut signifie augmenter l'efficacité de l'utilisation de la mémoire du conteneur sans modifier la configuration par défaut de .NET Core.
Avec les récentes modifications, .NET Core 3.0 prend également en charge les limites de ressources Docker (mémoire et CPU). Les limites de ressources permettent de contrôler la quantité de mémoire ou de CPU qu'un conteneur peut utiliser. Ces limites sont décrites en termes de quantité pour la mémoire et le processeur (par exemple, 128 Mo de mémoire ou deux processeurs). Lorsque les limites de mémoire sont définies, .NET Core 3.0 modifie son comportement en conséquence: la taille de segment de mémoire du ramasse-miettes est limitée à 20 Mo ou à 75% de la limite de mémoire. Dans le cas des limites de la CPU, la valeur définie sur Docker est arrondie à la valeur entière suivante. Cette valeur correspond au nombre maximal effectif de cœurs de processeur utilisés par CoreCLR.
Les améliorations ont également affecté la plus grande facilité d'utilisation de .NET dans les conteneurs Docker. Conformément à la demande de la communauté, Microsoft a ajouté PowerShell Core en tant qu'application dans les images Docker du .NET Core SDK disponibles. En outre, les images de conteneur .NET Core sont désormais disponibles via Microsoft Container Registry (MCR). Cela permet d'utiliser Microsoft Azure comme source officielle d'images de conteneurs fournies par Microsoft et comme source de distribution de contenu global via le réseau (CDN) pour fournir des images de conteneur en fonction de l'emplacement géographique de l'utilisateur.
Bien que .NET Core soit pris en charge par plusieurs distributions et versions de plates-formes, la liste des distributions prises en charge pour Docker est beaucoup plus réduite. Pour le moment, seules les versions spécifiques des distributions Alpine, Debian et Ubuntu sont prises en charge, ainsi que toutes les versions de Windows Nano Server. L’équipe .NET Core est en train d’ajouter un support pour ARM64 sur Linux.
Richard Lander, responsable de programme de l'équipe .NET, a déclaré dans son article à propos des améliorations : "Nous sommes investis pour faire de .NET Core un véritable environnement d'exécution de conteneur. Dans les versions précédentes, nous pensions que .NET Core était compatible avec les conteneurs. Nous sommes en train de durcir le runtime afin de le rendre compatible avec les conteneurs et de le faire fonctionner efficacement dans des environnements à faible mémoire."
La communauté .NET a bien reçu les améliorations de performances du framework. En plus de l'article de blog, les conférenciers Microsoft et Docker ont présenté plusieurs sessions à la DockerCon 2019 relatives au développement .NET en utilisant des conteneurs. L’une de ces sessions a été consacrée à la conteneurisation d’applications .NET legacy, thème qui présente un intérêt particulier pour les entreprises ayant une longue tradition de développement utilisant .NET. Cette session, animée par un représentant de Docker, illustre les récents efforts de l’entreprise visant à stimuler l’utilisation des conteneurs par le secteur et à soutenir la communauté des développeurs.
Les efforts de Microsoft semblent s’aligner sur les intentions de Docker, ainsi que sur d’autres initiatives de différentes communautés de développement. D'autres secteurs de produits Microsoft suivent la même tendance : plus tôt ce mois-ci, Microsoft a publié une nouvelle extension de développement à distance (remote) pour VS Code, qui permet un développement transparent à l'aide de conteneurs distants en conjonction avec une instance locale de VS Code.