Dockerfile

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

Principes et syntaxe

Vous êtes maintenant armés pour pouvoir manipuler Docker grâce au CLI. Cependant, vous avez jusqu’à présent utilisé uniquement des images officielles publiées sur le Docker Hub.

Pour pouvoir créer ces images, ceux qui les ont publiées ont dû les construire au préalable. Ainsi, pour avoir la possibilité d’exploiter vos créations à l’aide de Docker vous allez devoir, à votre tour, créer vos propres images Docker. Ceci est possible grâce à un fichier appelé Dockerfile.

Dans la logique, il faut voir le Dockerfile comme étant une succession d’instructions ordonnées, analogue à une recette de cuisine, nécessaire pour créer l’image. Ce fichier, sans extension, se comporte comme un fichier texte (il peut être édité simplement avec un bloc-notes). Pour suivre l’exercice, il est conseillé de se placer dans un dossier vide individuel et d’y créer un fichier nommé "Dockerfile" sans extension.

Appeler le fichier "Dockerfile" est une convention et n’est pas forcément nécessaire. On peut très bien l’appeler autrement et renseigner ce nom lors des instructions de génération de l’image. L’avantage de suivre cette convention est que l’on va éviter l’obligation d’ajouter un argument supplémentaire à notre ligne de commande. Il est recommandé de la suivre s’il n’y a qu’un seul fichier Dockerfile dans le dossier.

Explorons les différentes instructions nécessaires pour construire un Dockerfile.

1. Instructions FROM et WORKDIR

Par convention, les instructions du Dockerfile s’écrivent en majuscule. Il s’agit uniquement d’une convention et ce n’est pas obligatoire. Cependant, adopter cette pratique améliorera à la lisibilité de votre fichier.

Pour commencer, il est souhaitable de partir d’une image existante pour pouvoir construire le Dockerfile. Il faut savoir qu’il est possible de partir d’un très bas niveau, auquel cas il faudra choisir une image correspondant à un système Linux, comme Debian ou Alpine. Cependant, en tant que développeur...

Concepts avancés

1. Cache

Vous l’avez peut-être remarqué au cours des exercices précédents, Docker utilise de façon assez intensive un cache pour accélérer ses processus de build. Mais comment cela se passe-t-il ?

Il faut savoir que chaque instruction d’un Dockerfile génère un conteneur temporaire sur lequel votre instruction est exécutée, qui sert de base à l’instruction suivante. C’est pour cela que le type d’information suivant apparaît assez souvent lorsque vous lancez un build :

Step 1/6 : FROM mcr.microsoft.com/dotnet/core/sdk:3.1 
---> cef7866e800b 
Step 2/6 : WORKDIR testproject_mvc 
---> Running in 2a815b7e0465 
Removing intermediate container 2a815b7e0465 
---> 2bd5c1a09222

Docker indique explicitement qu’il supprime le conteneur intermédiaire (dont l’ID est 2a815b7e0465 dans les lignes précédentes) et en créé un nouveau (ce qui est symbolisé par une flèche suivie d’un nouvel ID, 2bd5c1a09222 dans les lignes précédentes). Si on exécute ce build une seconde fois, Docker indique de façon claire qu’il utilise le cache :

Step 1/6 : FROM mcr.microsoft.com/dotnet/core/sdk:3.1 
---> cef7866e800b 
Step 2/6 : WORKDIR testproject_mvc 
---> Using cache 
---> 2bd5c1a09222

On notera la similitude d’ID entre la dernière ligne de la première exécution et celle de la seconde. Une fois que Docker a fini de traiter votre instruction dans un conteneur intermédiaire, il crée une couche de cache avec un ID. Cette couche de cache est réutilisée dans les builds suivants, sous réserve que les couches précédentes n’aient pas été modifiées, ni que le contenu de l’instruction du Dockerfile ait subi de modifications, auquel cas le cache serait devenu invalide. C’est pour cette raison que le build initial d’une image est toujours plus lent que les suivants, qui sont souvent plus rapides.

Dès lors que l’on a compris ce concept, il est judicieux de se servir du cache à notre avantage. Par exemple, pour un projet .NET Core, il existe une étape de restauration des packages NuGet qui peut être assez longue, dépendant...

Exercice

Maintenant que vous avez réalisé un tour d’horizon sur la façon de créer, construire et exploiter vos propres images à l’aide d’un fichier Dockerfile, il est temps de mettre cela en pratique.

1. Énoncé

Pour cet exercice, on va créer un fichier Dockerfile permettant de faire fonctionner un site ASP.NET Core. Ce site, très simple, affichera sur la page d’accueil "Bonjour NOM", où NOM correspond à un paramètre récupéré depuis les variables d’environnement. Ce paramètre doit pouvoir être défini à la construction de l’image. On lui donnera la valeur par défaut "Inconnu" pour permettre une construction sans avoir besoin de le préciser.

Pour éviter que vous n’ayez à connaître le fonctionnement de la lecture des variables d’environnement, il est possible de récupérer le code source du site ASP.NET Core depuis votre compte ENI. L’image de destination devra être la plus petite possible et le nom devra être paramétrable.

2. Corrigé

En partant du principe que le site ASP.NET Core s’appelle ex-site (celui qui a été récupéré depuis votre compte ENI), la structure du Dockerfile pour répondre à cet énoncé doit être la suivante :...