Débuter avec les conteneurs Linux, Windows, Docker, Azure - partie 2 - Introduction à Docker
Ce billet fait suite à une introduction sur les conteneurs disponible ici : https://blogs.technet.com/b/stanislas/archive/2015/09/22/d-233-buter-avec-les-conteneurs-linux-windows-docker-azure-partie-1-introduction.aspx
L’objectif de cet article est de faire une vue d’ensemble simplifiée de Docker et des services proposés.
Conteneurs Linux et Docker
Docker facilite la mise en œuvre de conteneurs exécutés de manière isolée, via une API de haut-niveau. Pour cela, il s’appuie sur des mécanismes de Linux (LXC, CGroups, Namespaces, Layer FS…).
Un container Docker, à l'opposé de machines virtuelles traditionnelles, ne requiert aucun système d'exploitation séparé et n'en fournit aucun. Il s'appuie plutôt sur les fonctionnalités du noyau du système d’exploitation sous-jacent (Linux) et utilise de l'isolation de ressources (CPU, mémoire, I/O, connexions réseau etc.).
Enfin, un conteneur contient une application, des bibliothèques et l’ensemble des dépendances ou liens vers ses dépendances. Normalement un conteneur n’est pas censé contenir des gros volumes de données car cela va à l’encontre de sa philosophie en terme de légèreté et rapidité de (re)déploiement.
Docker Host, Client Docker
Docker fonctionne sur un modèle d’architecture de type client / serveur avec :
- Un client Docker
- Un moteur Docker
L’ensemble des communications client / serveur se fait avec des appels en REST protégé ou pas avec TLS (avec c’est mieux)
Le Docker Client propose un ensemble de commandes (une quarantaine) pour :
- Décrire l’image d’une application à déployer dans un conteneur
- Publier l’image dans un repository (public ou privé)
- Interroger un repository
- Gérer les versions des images dans un repository (appelé Registry)
- Déployer des images…
Le client Docker (ligne de commande) est disponible sur Mac, Linux et Windows.
Le moteur Docker (Docker Host) est disponible sur les distributions Linux (CoreOS, Ubuntu, RedHat...) mais également sur Windows Server 2016 (en version préliminaire à l'heure de l'écriture de cet article). La machine exécutant le Daemon Docker host peut être une machine physique ou virtuelle sur Azure, Hyper-V, VMware, Amazon Web Service...
Point important à retenir : un conteneur Docker Linux ne peut être exécuté que sur un Docker Host Linux. Idem, un conteneur Docker Windows ne peut être exécuté que sur un Docker Host Windows.
Conteneurs, images Docker
Les conteneurs sont des images en cours d’exécution.
Chaque image commence par une image de base (ex: Debian) ou plus « avancée » comme NodeJS installé sur Ubuntu.
Chaque image est ensuite constituée d'une série de couches baptisées « layers »
Docker File
Un Docker file est un fichier contenant l’ensemble des commandes pour construire une image. Ce fichier descriptif permet de construire automatiquement des images.
Registry, Docker Hub et Docker Trusted Registry
L’énorme avantage à utiliser des conteneurs c’est de pouvoir publier et centraliser des images prêtes à la réutilisation. Une “Registry” dans le vocabulaire Docker est un dépôt d’images qui serviront à instancier des conteneurs.
Docker propose d’ailleurs une “Registry” publique avec Docker Hub
Docker Hub est constitué par :
- La « Registry » : le système de stockage pour les images de conteneurs
- Le « public index » : un référencement des images publiques avec système d’évaluation / classement
- « automated builds » pour lier un dépôt de code GitHub ou Bitbucket et créer automatiquement des images Docker à chaque commit de code par un développeur
Par défaut, les dépôts sur Docker Hub sont publiques (ce qui encourage le partage d’images de systèmes ou d’applications Open Source par la Communauté.
Pour les développeurs / organisations souhaitant un dépôt privé (pour des raison évidentes de confidentialité, pour des applications métiers…), il est possible d’utiliser une Docker Trusted Registry Docker Compose
Les conteneurs étant idéaux pour des applications basées sur des micro services, il devient évident que rapidement on doit faire fasse à l’interconnexion de plusieurs conteneurs et à la gestion de multi-conteneurs. C’est ici que Docker Compose intervient…
(Source de l’image : Docker)
Docker Swarm
Quand le nombre de conteneurs commence à vraiment augmenter (c’est à dire dès qu’on passe d’une phase de développement & tests à une phase de mise en production), deux contraintes fortes font leur apparition : la montée en charge (“scalabilité” horizontale) et la disponibilité des conteneurs.
Ces deux aspects impliquent forcément la multiplication des conteneurs et des Docker Host. Aussi, il devient très difficile de gérer de manière simple via le client Docker tous ces éléments. C’est ici qu’intervient Docker Swarm qui va permettre aux administrateurs / DevOps d’orchestrer simplement l’ensemble des opérations.
Docker Swarm va exposer un ensemble de Docker Hosts comme un serveur virtuel auprès duquel l’administrateur enverra des commandes à orchestrer
(Source de l’image : Docker)
Comme je l’avais indiqué dans le premier article de cette série, un véritable écosystème s’est créé autour des technologies de conteneurs de Docker. Parmi les solutions d’orchestration alternatives ou complémentaires à Docker Swarm, certaines ont commencé à émerger : Kubernetes (par Google), Mesos…
Voilà, j’espère que ce bref tour d’horizon des composants principaux de Docker vous aura éclairer sur ces solutions vouées à un bel avenir.
Prochains articles de cette série : le déploiement de Docker Host dans Azure, l’administration de ces Docker Host depuis Windows, les conteneurs dans Windows Server 2016…
Vous êtes professionnel et légitimement vous vous posez des questions sur le Cloud, Microsoft Azure, Hyper-V, Windows Server, l’évolution du datacenter vers un cloud privé ou hybride… N’hésitez pas à suivre les sessions gratuites de formation de la Microsoft Virtual Academy : https://aka.ms/mvafr