Name: Docker pour les développeurs .NET
Rating: 5 (1 reviews)

Introduction

Bien que l’écosystème Docker soit majoritairement dominé par Linux, à la suite d’une forte demande de pouvoir conteneuriser des applications Windows, Microsoft a réagi assez rapidement pour adapter son système phare, et ce dans le but de répondre au besoin exprimé.

Le support des conteneurs Windows est disponible sous Windows 10 avec Docker Desktop, et directement au niveau du système depuis Windows Server 2016. La prise en charge a été largement améliorée dans la dernière version de Windows Server (version 2019) pour produire des conteneurs encore plus légers et plus puissants.

Le choix d’utiliser les conteneurs sous Windows plutôt que sous Linux doit être justifié. Il convient de se poser les bonnes questions :

Est-ce que j’utilise une technologie qui n’existe que sous Windows (comme le .NET Framework historique) ?
Est-ce que je préfère payer une licence Windows pour bénéficier du support plutôt que d’acheter le support d’une distribution Linux particulière ?
Est-ce que mon équipe connaît mieux l’administration et l’utilisation de Windows que celle de Linux ?

Bien que cette liste ne soit pas exhaustive, si la réponse à l’une de ces questions est oui, passer aux Windows Containers plutôt qu’utiliser Docker sous Linux peut être envisagé.

Il faut savoir que le changement peut-être quasi indolore (choix d’une image de base différente, changement des chemins pour les volumes et les répertoires de travail), tout comme cela peut s’avérer très compliqué (utilisation d’outils non disponibles sur une plateforme ou l’autre). Il est donc important d’effectuer ce choix en toute connaissance de cause, et d’être conscient qu’il n’est pas évident de faire machine arrière.

1. Fonctionnement de la licence

Bien que ce sujet constitue une problématique surtout pour les gestionnaires de l’infrastructure, il est pertinent que le développeur soit au courant du fonctionnement de la licence des conteneurs Windows.

Pour faire simple, une licence Windows s’applique au niveau de l’hôte, et non au niveau du conteneur...

Spécificités Windows

1. Volumes

Comme on l’a vu dans les chapitres précédents, il est possible d’utiliser des volumes pour sauvegarder les données entre les suppressions et les créations de conteneurs. Cependant, il était nécessaire, à chaque lancement, de spécifier le chemin dans le système hôte, car un driver particulier est utilisé pour simuler un volume avec un chemin Windows pour un conteneur Linux.

Dans le cas présent, étant donné que l’on utilise directement des conteneurs Windows, le driver est natif des deux côtés. De ce fait, on peut utiliser librement les commandes docker volume.

Il est possible de définir un volume de façon globale et de l’utiliser dans le cadre de lancements différents.

Pour cela, il est nécessaire de créer un volume du côté du système hôte en le nommant grâce à la commande docker volume :

docker volume create [NOM_DU_VOLUME]

Ici, pour l’exemple, on lancera la commande suivante :

docker volume create dev-vol

Après l’exécution de cette commande, Docker répond en nous retournant le nom du volume créé, indication que l’opération est un succès.

On peut obtenir confirmation de cette création en demandant la liste des volumes, grâce à la commande suivante :

docker volume ls

Figure 3 : Résultat du listage des volumes

On constate que le volume créé précédemment se trouve dans cette liste...

Outils spécifiques

1. Dépôt local

Lorsqu’on a abordé le chapitre sur l’usine logicielle, on a vu qu’il était possible de disposer d’un dépôt local pour pouvoir y pousser ses images. À la date de rédaction de cet ouvrage, le dépôt officiel Docker n’est pas disponible sous Windows et sonatype/nexus3 n’est pas officiellement supporté sous Windows.

Étant donné que Nexus utilise Java, il est possible de partir d’une image Windows et de configurer le conteneur soi-même. Cependant, comme à chaque fois, le fait qu’il ne s’agisse pas d’une solution officielle fait qu’il peut y avoir des failles ou des manquements, cette solution n’est par conséquent pas recommandée.

De ce fait, pour obtenir la similitude des outils entre les conteneurs Windows et les conteneurs Linux, il est nécessaire d’avoir un dépôt personnalisé. Il faut savoir que même si aucune image n’est publiquement disponible, le dépôt officiel de Docker est cross-platform car écrit dans le langage Go. Ce langage, qui est également celui utilisé par le moteur Docker, permet de produire des binaires natifs selon la plateforme.

À cet effet, il est possible de créer sa propre image qui correspond à la compilation et l’exploitation du dépôt Docker officiel. Le code source de ce dernier...

Déployer une application .NET Framework

Généralement, l’utilisation de conteneurs sous Windows est choisie car on souhaite migrer une application .NET Framework (et non .NET Core) vers ce type d’infrastructure, pour gagner en flexibilité. Il faut savoir qu’il est possible d’héberger une application .NET Framework sous Linux grâce à Mono, mais le fonctionnement peut ne pas être optimal. De même, les seules applications .NET Framework qui peuvent être conteneurisées sont des applications ASP.NET.

Si vous remplissez tous ces critères, nous pouvons voir ensemble comment migrer une application .NET Framework vers les conteneurs Windows.

Nous pouvons créer un Dockerfile qui exécute la totalité des actions, en multistage comme nous l’avons déjà fait avec les images Linux. À cet effet, il faut d’abord partir d’une image du SDK du .NET Framework 4.8 (dernière version disponible), procéder au build, puis copier l’ensemble dans un conteneur où IIS est installé pour la publication.

Nous allons utiliser une application ASP.NET Framework élémentaire afin de pouvoir tester le fonctionnement. À cet effet, nous allons travailler dans le répertoire chap8 du dépôt GitHub disponible à l’adresse suivante : https://github.com/hybrid-technologies-solutions/eni-docker-developper

Afin d’obtenir un résultat probant, nous allons devoir réaliser les étapes suivantes :

Tout d’abord, nous allons partir du SDK .NET Framework 4.8 afin d’effectuer la génération des fichiers binaires ASP.NET exploitable par IIS.

Ensuite, nous allons configurer une image avec IIS pour y créer l’application selon les meilleures pratiques pour y copier nos fichiers binaires et pouvoir travailler.

1. Étape de build

Le SDK .NET Framework est disponible sous l’image suivante :

mcr.microsoft.com/dotnet/framework/sdk:4.8

La première partie de notre Dockerfile se décompose en plusieurs étapes :

Partir de l’image du SDK 4.8.
Travailler dans un répertoire (par exemple src) à la racine de C:.
Étant donné que les projets ASP.NET Framework utilisent la restauration de packages à l’aide du fichier...

Conteneurs Windows