Ce que vous devez savoir sur Docker, système de conteneur Linux

Docker

On ne parle que de lui ! Les CastCodeurs depuis quelques mois (épisode 96), le Paris JUG en mars, tout comme les conférences sur le sujet qui ont été prises d’assaut lors du Devoxx France en avril dernier. Je parle évidement de Docker. Que se cache-t-il derrière le buzzword “hype” du moment ? Découvrons le au travers de cet article !

Histoire

Si on en parle autant, c’est qu’il s’inscrit parfaitement dans l’autre buzzword du moment : DevOps ! Cet outil permet de fabriquer rapidement et simplement des environnements et de s’assurer qu’ils soient tous identiques. On peut le comparer à deux types d’outils: les outils d’industrialisation et les outils de virtualisation.

Industrialisation

On avait déjà Puppet et GetChef pour fluidifier et industrialiser notre infrastructure. Voici la chronologie des créations des produits :

  • 2005 : Puppet
  • 2009 : Chef
  • 2013 : Docker.

Je ne connais pas bien Chef et Puppet mais j’ai assisté à plusieurs présentations dont celles de François le Droff et Romain Pelisse lors du Devoxx France 2014. On décrit via un DSL ce qu’on veut, et ces outils utilisent leur “recettes” pour déployer/installer ce que l’on souhaite. Cette stratégie permet aussi de faire de la mise à niveau.

Virtualisation

Ces outils permettent de faire tourner une image complète d’un système d’exploitation isolé, contrôlé et en lui allouant les ressources souhaitées. On trouve plusieurs types d’outils de virtualisation. Wikipedia l’explique de manière claire. Et on comprend vite l’intérêt de pouvoir limiter les ressources allouées à une sous partie d’un OS pour une ou plusieurs applications.

Il existe plusieurs types d’architecture:

  • Les hyperviseurs de type 1 appelé aussi “bar métal” dont l’hyperviseur dialogue directement avec le hardware sans passer par un OS et ou chaque image à un OS complet.
  • Les hyperviseurs de type 2 : dont l’hyperviseur est une application comme les autres qui tourne sur l’OS et ou chaque image à un OS complet.
  • Les isolateurs appelé aussi conteneur léger qui sont une applications elle aussi mais dont les images ne sont que des espaces de l’OS parent sans OS complet.

Un schéma étant toujours plus parlant, en voici un :

Hyperviseur

Conteneur

By Primalmotion (Own work) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0-2.5-2.0-1.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia CommonsCe n’est pas un OS complet qui est présent dans chaque environnement virtuel mais un “Proxy” vers le système. Cela limite le surcoût lié à la multiplication de couches qui font les mêmes choses. L’OS n’est donc pas dupliqué réellement même si à l’intérieur de l’environnement virtuel, on en a l’impression.

Conteneur léger

Docker est aussi un outil de virtualisation qui nous permet de faire tourner différentes distributions Linux sur le même OS. Comme par exemple une Ubuntu installée dans un docker qui tourne lui même dans une Debian. Mais il utilise les fonctionnalités du noyaux Linux pour cela. De ce fait, il n’inclue pas un deuxième OS complet ce qui le rend beaucoup plus léger.

L’idée de Docker, c’est de partir d’un porte-conteneur avec un socle commun à différentes images où chaque conteneur d’images est isolé. On perd un peu en performance vis à vis d’une machine physique, mais on gagne en ségrégation et réutilisation. Cette stratégie étant plus simple, on perd les lenteurs des VM traditionnelles. Pour faire cela Docker se base sur LXC, un autre gestionnaire de conteneur léger mais il y ajoute une couche de gestion simple à la git et divers fonctionnalité (cache d’actions, …)

L’autre intérêt de Docker, c’est qu’il s’intègre bien dans la mouvance DevOps. Les outils d’Ops ont été fabriqués par et pour des Ops, sans penser aux contraintes du développement. De ce fait, peu de développeurs utilisent Chef ou Puppet pour gérer les environnements de test en local. Docker se base sur la terminologie Git et essaye de garder ses mêmes forces : la rapidité grâce à un cache et un annuaire d’images à la Maven Central ou GitHub.

Installation

CaptureBoot2DockerL’installation de Docker reste complexe, car elle est liée à la spécificité de chaque distribution. Sur Redhat, c’est très simple, mais sur l’installation Ubuntu par exemple, il y a pas mal de cas spécifiques. D’autant que les poste de développement sont aussi souvent sous Linux que sous Windows. Sous Windows, il faut une VM avec Linux pour installer Docker.

Personnellement, j’ai eu quelques problèmes avec la VM conseillé par Docker : VirtualBox. Celle-ci ne voulait pas installer d’OS 64 bits et ne me proposait que les versions 32 bits. Hors Docker ne fonctionne pas sur un système 32 bits sans quelques manipulations complexes. Le problème venait de mon bios : il fallait activer les prise en charge d’instructions spécifiques à VMM (gestion des machines virtuelles). J’ai trouvé cette astuce très difficilement sur un thread qui parlait d’un installation sur Debian.

Une fois ce problème résolu, j’ai lancé l’installation de Boot2docker. La baleine s’affichait, j’étais en bonne voie…. mais nouvelle surprise: Kernel panic. J’ai pas trouvé la solution pour l’instant. J’ai abandonné et l’ai directement installé sur mon Ubuntu. En conclusion : sous Linux, ça marche bien, mais sous Windows, la peinture est encore fraîche !

Prise en main

Avant toute chose, je conseille de suivre le tutoriel en ligne qui permet de comprendre les concepts de base. Pour aller plus loin, je vous recommande l’excellent article du blog de David Gageot.

Les bonnes pratiques / Ce qu’on ne vous dit pas

On trouve déjà des conseils et bonnes pratiques sur Docker mais plusieurs aspects ne sont pas forcément clairs et sont pour moi bloquants pour une utilisation en production :

  • La gestion de la qualité n’est pas encore automatisée, hors le DockerFile est un ensemble de commandes qui doivent être contrôlées/testées automatiquement et, sauf erreur de ma part, il n’existe pas de plugin Sonar pour le moment. Il est toujours possible de lancer Docker dans Maven pour tester son image et ce qui y tourne mais on doit vérifier manuellement le contenu de l’image.
  • La sécurité s’appuie avant tout sur l’aspect VM de Docker. On a pourtant entendu parlé des failles du bac à sable de Java. Il encourage d’ailleurs les utilisateurs – dans la documentation – à proposer leur aide sur ces aspects.
  • Pour ce qui est de la performance : oui, le coût est minime versus des VMs de type 1 ou 2. J’ai entendu 3% dans une conférence versus 10% sur des VM de type 2. Si on souhaite faire de la performance, on perd toujours 3% et ce coût, en regard du service rendu, peut être problématique pour certaines applications en production.
  • En termes de stabilité : l’éditeur conseille d’attendre la version 1.0 pour le mettre en production (elle ne devrait plus tarder).

Use case

Un très bon cas de test est l’utilisation de Graphite qui, il faut bien le dire, est une plaie à installer ! (nombre important d’étapes, problèmes de droits, etc.). Je vous conseille le billet sur le blog de Docker qui montre la facilité à monter ce type d’environnement. Sachez que sous Windows, si le forward de port de Docker est simple, le network bridge  de VirtualBox est quant à lui plus complexe (et puis… je n’aime pas les interfaces graphiques !). De la même manière, il permet d’avoir un environnement identique pour les tests locaux des développeurs et l’usine de build. Par contre, pour la production, l’éditeur conseille d’attendre la 1.0.

Le cas que décrit Nicolas Martignole, soit un développeur qui travaille sur deux stacks techniques complètement différentes, et qui souhaite les ségréguer, est finalement assez banal dans les process de migration de code legacy vers des technologies plus récentes.

Conclusion

L’outil est simple et efficace… mais ça dépend des cas ! Car si on enlève la production et les postes de développement sous Windows, on se limite à l’usine de build/test et poste de développement sous Linux ou MacOsX. C’est déjà énorme ! C’est beaucoup plus rapide que ce que proposaient les VM en perdant un peu de la ségrégation. Bref : Docker est un outil qui a de l’avenir, surtout quand la version 1.0 verra le jour et que des outils de contrôle de qualité sur les “dockerFile” apparaîtront. Des bruits de couloirs racontent que Google compte faire des annonces sur le sujet au Google IO de San Francisco les 25 et 26 juin prochains.

Crédits photos :  By Primalmotion via Wikimedia Commons on license creativecommons

Share
Guillaume DUFOUR

4874

Comments

  1. Dufour Guillaume Says: December 11, 2014 at 5:49 pm

    Update :
    – La version 1+ de docker est sortie
    – Des outils de validation commence à apparaitre : https://github.com/Runnable/validate-dockerfile
    – Des outils de production automatique d’image existe dans Maven : https://github.com/spotify/docker-maven-plugin

Leave a Reply

Your email address will not be published. Required fields are marked *