Depuis l'introduction de l’EC2 Container Service lors de l’AWS Re:invent 2014, le service en lui-même et la technologie de conteneurs en général ont suscité une vague d'intérêt. Docker est sur toutes les lèvres et les conteneurs sont bel et bien là et partis pour rester.
La technologie de virtualisation des conteneurs, également connue sous le nom de virtualisation au niveau des systèmes d'exploitation, n'est pas nouvelle. Son support existe depuis des années, pratiquement depuis ses débuts, sous la forme de chroot ou de jails sous FreeBSD.
En plus des solutions professionnelles, l'écosystème Linux voit l’incorporation du système d'espace de noms et du LXC dans le kernel et chaque distribution inclut ses propres versions des bibliothèques qui supportent cette technologie, mais ne sont pas toujours compatibles entre elles.
Avant la version 1.0, Docker avait déjà créé sa propre bibliothèque : libcontainer. Elle avait pour but de standardiser la définition de « conteneur » et d'assurer la compatibilité entre les différentes distributions de Linux.
Aujourd'hui, mettre en place un système de conteneurs est aussi facile qu'installer un paquet à l'aide de notre outil habituel. Il est également possible de transférer libcontainer vers d'autres systèmes d'exploitation et Microsoft a déjà annoncé qu'il intègrera un support natif de Docker sur Windows Server.
Mais l'élément le plus attractif de Docker est peut-être l'introduction du concept d'images. Il s'agit de conteneurs tout prêts qui peuvent servir de base à de nouvelles images ou à un lancement direct de services. Et, cerise sur le gâteau, Docker possède sa propre bibliothèque d'images, Docker Hub, où les créateurs de composants logiciels largement utilisés et les utilisateurs finaux peuvent publier leurs images. Avec Docker Hub, mettre en marche un serveur Nginx se limite à exécuter une seule action sur toute la ligne de commande.
Le concept de conteneur
Pour faire simple, un conteneur est un processus pour le système d'exploitation qui contient l'application que vous voulez lancer ainsi que toutes ses dépendances. L'application ne voit que le système de fichiers virtuel du conteneur et utilise indirectement le kernel du système d'exploitation pour s'exécuter.
Il existe une certaine similitude entre le conteneur et une machine virtuelle : il s'agit de deux systèmes autonomes qui, en réalité, utilisent un système supérieur pour réaliser leurs tâches. Cependant, la principale différence entre les deux est qu'une machine virtuelle doit contenir en elle tout un système d'exploitation alors qu'un conteneur se contente d'utiliser le système d'exploitation sur lequel il s'exécute.
Par exemple, pour virtualiser une base de données sur une machine virtuelle, il faut :
1. une machine physique qui fournit la partie hardware
2. un système d'exploitation hôte sur cette machine physique
3. un système de virtualisation ou hyperviseur pour gérer les requêtes entrantes sur le hardware virtuel et les exécuter sur le hardware réel
4. un système d'exploitation invité sur l'hyperviseur. Ce système doit être complet étant donné qu'il n'est pas en mesure d'obtenir des ressources du kernel de son hôte.
5. installer le gestionnaire de base de données et ses dépendances sur le système invité.
À l'inverse, pour virtualiser la même base de données sur Docker, il faut :
1. une machine physique ou virtuelle
2. un système d'exploitation installé sur la machine
3. le gestionnaire de Docker installé sur la machine
4. un conteneur basé sur une image contenant le gestionnaire de base de données et toutes ses dépendances.
Les principales différences sont :
1. le système de conteneurs ne nécessite pas une machine physique, alors qu'installer un hyperviseur sur une machine virtuelle n'a pas de sens (ses performances en seraient grandement pénalisées). Ainsi, avec Docker, nous gagnons en versatilité.
2. chaque machine virtuelle contient tout un système d'exploitation. Dans l'exemple ci-dessus, lancer une deuxième base de données comme réplique impliquerait une plus forte sollicitation des ressources de l'hôte physique (ou l'ajouter d’un second hôte) afin de lancer un second système d'exploitation. À l'inverse, avec Docker, il suffit de lancer un second conteneur plus léger : ainsi nous optimisons les ressources.
3. lancer un conteneur est aussi long que démarrer un processus dans le système. Cependant, lancer une machine virtuelle, implique de patienter jusqu'au démarrage du système d'exploitation sous-jacent. Ainsi, avec Docker, nous gagnons en agilité.
La taille d'image que nous pouvons atteindre mérite également d'être soulignée : l'image officielle de Debian 7.7 occupe 85,1 Mo sur Docker Hub. Celle de Nginx, 91,4 Mo. Combien d'espace les images Virtualbox correspondantes occuperaient-elles ? Cela nous permet de nous faire une idée de l'agilité requise pour réaliser toute opération d'approvisionnement ou de transfert de conteneurs.
Pour renforcer le point 2, nous pouvons exécuter le script suivant. Il montre que l'espace occupé sur la mémoire par 10 processus sous une image Debian est infime, comparé à ce qu'il faudrait pour démarrer 10 machines virtuelles :
Il est facile de comprendre pourquoi nous (ainsi que pratiquement toute la communauté Internet) croyons que la technologie de conteneurs va transformer la manière dont les services sont déployés dans les infrastructures. L'association de conteneurs et de plateformes Cloud aura d'importantes répercussions sur la disponibilité, la scalabilité et les coûts des projets que nous déploierons à l'avenir. Elle nous aidera également à réduire le temps nécessaire au lancement de nouvelles fonctionnalités. À partir de maintenant, les développeurs, les bêta-testeurs et les services de QA travailleront directement sur le conteneur qui sera finalement produit et son déploiement consistera à effectuer une simple opération de copie dans l'environnement de production.
La progression de Docker
Les entreprises ont commencé à adopter les technologies de containers telles que Docker depuis quelques années. Elles les aident à normaliser et rationaliser le déploiement et le conditionnement de leurs applications. Le cabinet Rightscale a réalisé début 2016 une étude démontrant un engouement sans précédent pour le couple Docker - DevOps. Le taux de pénétration Docker est passé de 13 à 27 % dans les entreprises. Ce succès est à associer avec l’adoption des approches DevOps. En effet, de nombreuses organisations choisissent de mettre en œuvre des outils de gestion de configuration qui leur permettent de standardiser et d’automatiser, en bref, d’industrialiser, le déploiement et la configuration des applications.
Nous avons ainsi officiellement pénétré dans l'ère des conteneurs et des microservices. AWS aussi, et nous savons que nous ne sommes certainement pas les seuls.
Sources :
http://blog.celingest.com/en/2015/02/17/docker-and-the-era-of-the-contai...
AWS EC2 Container Service: https://aws.amazon.com/ecs/
Docker: https://www.docker.com/
Docker Hub: https://hub.docker.com/
https://www.silicon.fr/sponsor/devops-et-microservices-dans-lecosysteme-...