Tutoriel : Premiers pas de développeur avec Docker, Azure et Visual Studio 1/3

Docker, docker, docker…c’est vraiment le mot à la mode ces temps-ci !Si vous aussi vous souhaitez comprendre l’intérêt de Docker et surtout tester facilement la techno avec vos outils préférés. Si vous aussi vous souhaitez devenir hype et clamer “évidemment que j’ai déjà utilisé Docker”, vous êtes au bon endroit

But du tutoriel

Cet article est un tutoriel qui permet de faire une petite application console et de la déployer d’abord dans un conteneur Linux, puis dans un conteneur Windows, sur Azure. Cela permet de mieux comprendre le fonctionnement de Docker et de voir ce qui change selon que l’on déploie la même application sur un conteneur Linux ou Windows.

Pour démarrer directement le tutoriel, rendez-vous sur la page suivante de l’article

C’est quoi Docker ?

Blague à part, ce n’est pas pour rien qu’il y a tant d’engouement pour Docker : ce n’est pas juste une techno de plus, c’est une techno qui peut (et va) nous simplifier grandement la vie, à nous développeurs, mais qui nous aider aussi à travailler avec les “ops” dans de meilleurs conditions. Et pour cause : la technologie docker simplifie autant la vie aux développeurs qu’aux “ops” en fournissant une technologie de packaging, de déploiement et d’environnement d’exécution inédit.

Le schéma ci-dessous illuste très bien le principe des conteneurs et de docker.

Pour faire ultra simple: une machine serveur fait tourner 1 OS + 1 agent docker appelé docker engine. Le docker engine gère et fait tourner N conteneurs docker sur ce même OS. Cela constitue un docker host.

Il faut voir chaque conteneur comme une unité d’exécution ou une application au sens large du terme, comme par-exemple un service web ou un service de BDD. Le docker host démarre un conteneur à partir d’une image docker décrivant un packaging applicatif. On peut donc voir un conteneur docker comme 1 instance d’exécution d’une image docker.

Docker offre des avantages multiples et très complémentaires grâce à un savant mélange de:

Simplicité et fiabilité en terme de packaging

Les images docker se composent de couches logicielles qui se superposent un peu comme un millefeuille. Par-exemple l’image docker utilisée pour déployer un conteneur ASP.Net sera elle-même basée sur une image d’une distribution Debian de Linux sur laquelle aura été installé le serveur web kestrel. Ainsi si l’on cherche à faire tourner son site web ASP.Net dans un conteneur docker : il suffit de partir directement de l’image docker ASP.Net (mise à disposition par Microsoft). Ensuite y ajouter son propre code/package, puis faire un commit (c’est une commande Docker) pour transformer à votre tour ce résultat en une image docker, que vous – ou d’autres si vous la partagez – pourront réutiliser. On retrouve les images dans des référentiels privés ou publics, comme la Docker library qui est le référentiel public et officiel de Docker.

Le packaging se décrit de manière déclarative par un simple fichier de configuration versionné. Il est donc archivable/historisable facilement et permet ainsi de reproduire un environnement identique sur demande.

Grâce à ce fonctionnement à base d’images, Docker permet de reproduire le même environnement d’exécution à toutes les étapes du cycle de vie logicielle (dev, integ, qa, pre-prod, prod) et facilite ainsi la collaboration Dev & Ops.

Optimisation des ressources et rapidité de démarrage

Tous les conteneurs d’un même docker host partagent l’OS de l’hôte. Cela permet de démarrer un conteneur très rapidement – en comparaison du démarrage d’une VM par-exemple. Par-contre l’isolation est moindre : ce qui peut être vu comme un inconvénient dans certains contextes. Pour répondre à ces situations là, sachez que Microsoft propose des solutions pour améliorer l’isolation via des conteneurs Hyper-V mais cela sort du cadre de cet article .

Souplesse de déploiement

Un agent docker (appelé docker daemon ou docker engine) tourne sur la machine hôte et se charge d’être votre interlocuteur à distance pour les manipulations de maintenance et de déploiement des conteneurs et des images. Depuis un poste client, vous utiliserez un client docker en ligne de commande (ou une des applications plus évoluées qui se base sur les mêmes APIs).

Multi-plateforme et multi-techno

Ce mécanisme est générique et déclinable quelle que soit votre machine cible, votre OS, vos frameworks, vos langages. C’est très intéressant car si vous vous intéressez à Docker, vos compétences pourront être mises à profit quel quel soit le contexte de votre projet : techno orientée open-source ou pas ! Ce qui est indispensable par contre c’est : une machine qui soit capable de faire tourner l’agent Docker et de vous fournir des conteneurs. Ainsi vous pourriez envisager d’utiliser les mêmes commandes et mécanismes de maintenance pour tous vos projets, quel que soit leur contexte technique : c’est pas génial ça ?

Gestion infra avancée et automatisation

On se situe bien à un niveau “infrastructure” pour nos conteneurs ainsi si l’on veut pouvoir piloter une armée de hosts facilement, des outils sont à notre disposition pour nous aider. Par-exemple Swarm se positionne comme un interlocuteur unique permettant de piloter un cluster de hosts docker ; il saura décider tout seul du meilleur endroit où déployer un conteneur. Julien Corioland a rédigé un article sur le déploiement d’un cluster Docker Swarm dans Azure qui vous permettra d’en apprendre plus sur le sujet.

Ca donne envie non ? Bon alors la bonne nouvelle c’est que Docker est supporté par Azure. Et comme Microsoft propose des conteneurs Windows: sur Azure vous aurez le choix d’utiliser des conteneurs Windows ou Linux.

C’est parti pour le tuto !