20 janvier 2020 admin

Publication des applications ASP.NET Core pour Linux

Lorsque Microsoft a publié l’implémentation open source multi-plateformes du ASP.NET Core fin 2014, l’un des changements stratégiques clés a été le support Linux récemment acquis. Pour de nombreuses organisations, la possibilité d’exécuter des applications Microsoft .NET (et en particulier des web services ASP.NET) sous Linux constitue une excellente occasion de consolidation vers un OS de production unique. La possibilité d’utiliser des outils de développement familiers sous Windows, puis d’héberger l’application résultante sous Linux en respectant les exigences IT, va permettre une réduction importante des coûts. En règle générale, on utilise Windows comme OS de développement car il prend en charge toutes les fonctionnalités de Visual Studio pour développer des applications ASP.NET Core et IIS pour héberger les applications résultantes.

La version open-source du .NET Core est multi-plateformes et prend en charge plusieurs OS en tant que cible de production, y compris diverses versions de Windows (Windows Server, Windows Nano Server) et de nombreuses distributions Linux (Ubuntu, Debian, Red Hat Enterprise Linux, Alpine, etc.). Le .NET Core prend également en charge de nombreuses architectures de processeurs, notamment Intel x86-64 (utilisé par la plupart des serveurs) et ARM (utilisé par les périphériques IoT et les téléphones mobiles).

Choisir le bon OS pour toutes les applications et tous les services d’une entreprise peut s’avérer très rentable, en particulier si vous pouvez consolider vos environnements de production en un seul OS et en une architecture de processeurs unique. Certaines des raisons pour choisir Linux comme système d’exploitation incluent :

  • Un impact sur la mémoire et sur le disque beaucoup plus faible dans les déploiements, aussi les virtualisations et les conteneurs (dans certains cas d’un facteur supérieur à 10).
  • Un support idéal pour d’autres plates-formes et langages de programmation, tels que Java, Python, PHP et Go. Windows peut ne pas prendre en charge certaines de ces langues.
  • Environnement familier pour de nombreux administrateurs système.

Le choix de Linux comme plateforme de production va vous permettre d’utiliser le pipeline de la build, de publication et de déploiement de bout en bout à partir de votre environnement de développement Visual Studio 2017. D’ailleurs, il faut savoir qu’il existe deux manières de publier une application .Net Core :  La publication dépendante du framework et la publication autonome

Publication dépendante du framework

Pour ce genre de publication, la sortie finale du build de l’application contient les fichiers DLL de l’application et toutes ses dépendances tierces, telles que les packages NuGet et les références de projet. Toutefois, les bibliothèques .NET Core et le runtime .NET Core, qui comprend le compilateur JIT (Just-In-Time), Garbage Collector et l’outil Dotnet, ne sont pas fournis avec l’application. L’installation partagée de ces composants doit être présente sur la machine cible. On peut utiliser les commandes suivantes pour restaurer les packages NuGet, compiler votre application, la publier en tant que package dépendant du framework, puis l’exécuter à partir du répertoire de sortie.

dotnet restore

dotnet build -c Release

dotnet publish -c Release -o out

dotnet out/myapp.dll

Bien que vous deviez installer les bibliothèques .NET Core et les composants d’exécution sur la machine cible, la publication dépendante du framework présente un avantage majeur. Le package produit est totalement indépendant de la plateforme et peut être exécuté sans modification sur toute plateforme prenant en charge .NET Core, quel que soit le système d’exploitation ou l’architecture du processeur.

Publication autonome

Lorsque vous utilisez la publication autonome, le package du build final de votre application contient les DLL, les dépendances de tiers, une copie complète des bibliothèques .NET Core gérées de votre application et des composants natifs, tels que le compilateur JIT et le garbage collector.

Certains de ces composants étant dépendants de la plateforme lorsque vous utilisez la publication autonome, vous devrez spécifier l’identificateur d’exécution d’une plateforme spécifique. Le package résultant ne s’exécutera que sur un système d’exploitation spécifique et selon une architecture de processeur spécifiée par l’identificateur d’exécution. Voici quelques exemples d’identificateurs d’exécution.

  • Linux-x64 : Cet identifiant d’exécution cible toute distribution Linux pour processeurs x86-64, à l’exception d’Alpine Linux. Des exemples de distributions Linux prises en charge incluent Debian, Ubuntu Linux, Red Hat Enterprise Linux et Fedora.
  • 3.6-x64 : Cet identifiant d’exécution cible la distribution Alpine Linux pour les processeurs x86-64. Alpine Linux est une distribution Linux légère, qui fonctionne bien dans les environnements de conteneur en raison de sa petite taille.
  • Win-x64 : Cet identifiant d’exécution cible toutes les versions de Windows pour les processeurs x86-64, y compris Windows Server 2008 R2, Windows Server 2016 et autres.
  • Win10-arm64 : Cet identifiant d’exécution cible les versions de Windows 10 ou Windows Server 2016 s’exécutant sur des processeurs ARM 64 bits.

Quand on utilise des conteneurs pour le déploiement, Microsoft fournit des images officielles sur Docker Hub, qui contiennent les dépendances natives de base requises par une application .NET Core autonome. Ces images sont étiquetées avec différentes balises runtime-deps, dont la taille est beaucoup plus petite que les balises runtime correspondantes. Par exemple, microsoft/dotnet:2.1-runtime-deps-alpine est une image de conteneur contenant uniquement l’image de base Alpine Linux et les dépendances natives, telles que libzlib et libcurl, requises par .NET Core sous Alpine Linux.

Comment choisir le type de publication ?

Pour décider si vous devez utiliser une publication dépendante du framework ou autonome, vous pouvez envisager les éléments suivants :

Taille finale de l’image

Avec la publication autonome, la taille finale de l’application packagée est souvent plus grande car elle inclut les assemblys d’exécution .NET Core et d’infrastructure, en plus des assemblys de votre application.

Partage d’exécution

Si vous déployez plusieurs applications .NET Core sur le même ordinateur ou si vous exécutez plusieurs conteneurs basés sur les images de conteneur .NET Core, utilisez une publication dépendante du framework pour que toutes les instances d’application partagent les mêmes fichiers d’exécution .NET Core et assemblys sur le disque.

Flexibilité de la plateforme

Avec la publication autonome, vous devez choisir une plateforme cible sur laquelle votre application sera exécutée. Vous ne pouvez pas créer l’application pour les systèmes d’exploitation Linux sur un processeur Intel 64 bits, puis l’exécuter sur un système d’exploitation Windows ou sur un système d’exploitation doté d’un processeur ARM. D’autre part, lors de l’utilisation d’une publication dépendant du framework, le build résultant peut être exécutée à l’aide du helper dotnet sur toute plateforme sur laquelle la version appropriée de .NET Core sera installée.

Dépendances minimales

Avec une publication autonome, vous minimisez les dépendances d’exécution requises pour l’hébergement de votre application.

Contrôle de la version et du service .NET Core

Quand vous utilisez la publication autonome, vous contrôlez la version exacte de .NET Core qui sera utilisée pour exécuter votre application.

Mohamed S.

Contact

N’hésitez pas à nous solliciter pour vos projets ou pour en savoir plus sur nos expertises, nos offres et nos domaines de compétences.