Ça s'en va et ça reviens
J'aime tester de nouvelles technologies sur chacun de mes projets. L'apprentissage de la programmation par la voie scolaire se concentre principalement sur des langages comme C ou Java et passe sous silence l'offre pléthorique de frameworks disponibles pour faciliter la vie du développeur. Ceci explique en partie pourquoi je n'ai découvert Twitter Bootstrap qu'en deuxième année de master alors que mon premier site date du collège. Aujourd'hui, j'ai donc décidé de noter tous les langages, frameworks, ou autres dont j'entends parler et de les essayer quand l'occasion s'en présente. Mais qui dit nouveaux outils dit nouveaux binaires, nouveaux fichiers, etc. qui viennent polluer mon système...
Keep It Simple, Stupid
Prenons un exemple. Pour ce site, j'ai décidé d'utiliser Foundation à la place de Bootstrap que je connaissais déjà et Jekyll - fourni par la plateforme GitHub Pages - au lieu de tout coder en bon vieux XHTML. Avec ces outils vient une quantité impressionnante de dépendances ! J'ai voulu installer Foundation via Sass, ce qui nécessite l'installation de NodeJS, Bower, Grunt, Compass et j'en passe. Mais toutes ces dépendances, il y a de fortes chances que je ne m'en resservent jamais. Au quotidien, j'utilise ArchLinux dont la philosophie est KISS (Keep It Simple, Stupid !), et derrière cela, il y a une distribution configurable à l'extrême où je suis théoriquement sensé connaitre l'ensemble des paquets présents sur mon système. Autant dire que l'installation de dépendances à outrance n'est clairement pas ce que je recherche !
Diviser pour régner
Durant une session de programmation Python, j'ai découvert Virtualenv qui te permet de créer un environnement Python isolé. Un fois Virtualenv lancé, tous les paquets installés via le gestionnaire de paquets Python sont installés dans un dossier local au projet. Ainsi, lorsque j'en ai fini avec le projet, je supprime son dossier, et toutes les dépendances disparaissent du système. C'est une façon propre d'essayer de nouveaux modules python. Ruby propose à peu près la même chose sous le nom RVM que je n'ai jamais utilisé. Ce type d'utilitaires est appelé un environnement virtuel. Mais qu'en est-il pour les autres outils comme Node ou ceux qui n'existent pas encore ?
Qui dit environnement virtuel dit machine virtuelle
La première idée que j'ai eu, ça a été de regarder du côté des machines virtuelles. Pour chaque projet, je pourrais créer une VM dans laquelle j'installerais toutes les dépendances. Une fois le projet "terminé", je supprime l'image et tout est propre ! Le problème c'est que les machines virtuelles, c'est lourd ! Il faut réinstaller un système complet, le configurer correctement, etc. à chaque projet. Une solution consiste à le faire une fois et à repartir toujours de la même image. Mais il y a deux choses qui ne peuvent pas se résoudre comme ça ; la surcharge du système dû à une VM et le temps de démarrage d'une VM.
Docker à la rescousse !
Docker est un outil initialement développé pour simplifier le déploiement de n'importe quelle application sur n'importe quelle plate-forme. Docker utilise la notion d'image, qui contient l'application et toutes ses dépendances. En lançant une image - on dit qu'on exécute un conteneur (container) - toutes les dépendances nécessaires sont disponibles dans la bonne version et avec la bonne configuration sans entrer en collision avec les dépendances des autres conteneurs. Les conteneurs sont comme des VM mais utilisent une nouvelle fonctionnalité du noyau, les LXC, pour limiter leur emprunte sur le système. De plus, Docker est prévu pour qu'il soit facile de partager des fichiers ou d'avoir accès aux ports des applications d'un conteneur.
Docker en action
Malheureusement, ce post commence à devenir un peu long, et j'ai besoin d'un peu de temps pour illustrer Docker dans un joli cas bien propre, et ce sera donc pour un prochain post !
N'hésitez pas à réagir
Via Disqus ...
... ou Facebook