Docker, pour builder, tester sur différentes plateformes, ça a l’air vraiment puissant.
C’était l’un de nos projets de l’année 2019 : commencer à travailler avec Docker.
Avant de commencer à mettre les mains dans le cambouis, regardons ce que nous avons sur notre machine :
Nous voyons que nous avons un packet d’images déjà prêtes sur notre pc !
Suivons le tutorial proposé par docker pour bien comprendre ce qu’est docker.
En résumé :
source: docker site
Docker nous invite à tester docker en lançant le fameux Hello world, et là, c’est lancer un container qui va afficher “Hello from Docker !”
docker run hello-world|
1 |
Mais, vous allez me dire, nous n’avons pas d’HelloWorld venant de Docker sur notre machine, n’est-ce pas ?
Ce qui est vraiment puissant, c’est que Docker va aller chercher l’image, avant de la lancer en local sur notre machine.
Et c’est là que nous trouvons une première notion très importante : le pull, la récupération des images en local sur notre machine.
Et docker nous donne envie d’en apprendre plus :
Et si nous suivions ce que propose docker ? A savoir lancer un unbuntu sur notre machine, et nous y connecter ?
Ainsi si vous n’avez pas, sur votre machine, l’image souhaitée, Docker va aller le chercher sur le Docker Hub.
Ici, dans la commande que nous avons lancée, le –it va permettre de connecter un terminal au container qui va être créé.
Dans Visual Studio, lorsque l’on souhaite créer un nouveau projet, nous pouvons décider d’activer le support de Docker.
Cela va créer un projet docker-compose.
De plus, ce projet, dans votre solution, va permettre de paramétrer le container qui sera lancé.
Le DockerFile est l’arbitre qui va lancer toutes les commandes pour préparer votre image.
En résumé, pour cette première présentation de Docker, vous avez trois étapes pour configurer le container que vous allez créé :
Vous avez donc besoin de deux images de docker :
Le projet docker compose, dédié pour Visual Studio 2017 est un moyen d’exécuter et de lancer les commandes du docker compose proposées par Docker.
Le plus important ici est l’existence d’un fichier yaml : docker-compose.yml.
C’est un fichier qui permet de :
C’est très pratique par exemple, lorsqu’on a plusieurs environnements (donc containers) à lancer.
Ici, pour notre application asp.net core, le docker compose va permettre :
En exécutant le projet docker-compose, sous Visual Studio, nous allons lancer le container, et donc lancer l’application asp.net core, dans le container.
Pour récupérer une image avec dotnet configurée, lancer un pull.
https://hub.docker.com/_/microsoft-dotnet-core-runtime/
Attention : Les images docker changent de repository :
Elles passent :
Quand on n’a qu’un seul projet asp.net core, et qu’on ne change rien au DockerFile initial, aucun problème.
L’aventure commence quand on veut :
Ce problème arrive quand l’image que nous avons récupérée n’a pas le bon runtime dotnet.
Il s’avère que certaines versions d’images docker venant de Microsoft ne sont pas bien paramétrées.
FROM microsoft/dotnet:2.2-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
On y a passé du temps à tout configurer de notre côté, et c’est ce runtime, en le forçant à le récupérer de nouveau qui nous a sauvé :
Plusieurs solutions peuvent vous aider ici :
Les exemples que l’on trouve sur Internet pour travailler avec Docker et asp.net core, et Visual Studio 2017 présentent toujours qu’un seul projet.
Or, nous avons l’habitude chez DevToBeCurious d’organiser nos projets (Domain Driven Design, Archi N Tiers, Injection de dépendances, …), en projets dédiés par Responsabilité.
Et donc, on se retrouve avec un projet asp.net core qui référence plusieurs sous projets.
Comment faire alors pour avoir un DockerFile qui prend en compte tous ces projets ?
Le mieux c’est de regénérer, une fois vos projets référencés, votre DockerFile depuis Visual Studio, depuis votre projet (clic droit sur le projet => Ajouter => Prise en charge Docker) :
Il vous créera le bon fichier, tout bien préparé !