Docker en quelques mots
Docker est l’idée qui va définitivement changer la façon de développer et de livrer vos applications. En quelques mots, Docker est une solution qui permet de standardiser la façon dont une application est packagée, puis s’exécute, dans n’importe quel environnement.
De même que les conteneurs de bateaux font tous la même taille, ce qui permet de les empiler et de les déplacer quelque soit leur contenu, Docker propose un système simple de conteneur. Un conteneur, c’est donc une boîte dans laquelle vous allez exécuter de façon isolée, vos applications. Ces boîtes peuvent ensuite être exécutées sur une machine virtuelle, sur un serveur ou dans un environnement de production. L’intérêt de Docker est de standardiser l’enveloppe. Et le génie, c’est que les ressources sont isolées ET partagées. Un même serveur ou une même VM peut donc exécuter plusieurs conteneurs Docker, comme autant de serveurs isolés les uns des autres. Par rapport à de la virtualisation, il n’y a donc pas de coûts supplémentaires de ressources. Docker se place au dessus des VMs, et permet d’exécuter de façon isolée et standard vos applications.
Qui est derrière Docker
Cocorico, le projet est d’origine française. Solomon Hykes est passé par l’Epitech en 2006, et a créé dotCloud, un PaaS en 2010, avec d’autres anciens d’Epitech. Docker est un projet open-source, initialement développé pour dotCloud. Cependant en un an, le projet a connu un tel succès, que la société dotCloud s’est renommée Docker. Plus de 400 000 téléchargements, le projet a plus de 11 000 stars sur Github et c’est l’un des projets open-source dont on parle le plus en ce moment. La société a levé au total 26 millions de dollar. Basée maintenant à San Francisco, elle compte 4-5 personnes de l’Epitech, mentorées par des personnes de la Valley, comme Ben Golub, l’actuel CEO. Voir l’article de Marion Moreau sur Frenchweb.
Pourquoi faut-il s’y intéresser ?
Prenons un exemple concret. Aujourd’hui je travaille pour 2 clients. Pour le premier, je développe avec une base MySQL, du Java et un blog WordPress en PHP. Pour le deuxième, je fais du Scala avec Play2, une base Redis et une autre base MySQL. Lorsque je travaille sur ma machine de développeur, il faut donc que j’ai l’ensemble de ces environnements correctement installés. En plus, lorsque je ferai ma mise en production, il faut que ma cible de déploiement soit identique et à jour. Même version de MySQL et de PHP pour WordPress. Version 7 de Java pour le premier, et une autre version pour le deuxième…
Le souci ici c’est que la cohabitation de ces environnement est un problème sur ma machine de développement, qui ne doit pas impacter ma production. De plus, lorsque je livrerai, il faudrait que je package aussi et prépare l’installation de mes dépendances, avant même de livrer mon code. Et j’ai un scoop pour vous : la prod n’a plus à décider de votre environnement et des versions des logiciels utilisés. Vous allez voir qu’avec Docker, vous allez faire fermer le clapet du grand chef de la prod, qui par un beau matin pensait pouvoir décider de votre architecture, de vos logiciels et des applications à installer.
Le développeur doit être responsable de A à Z, capable de livrer et de packager l’ensemble de ses applications.
Version sans Docker, avec un paquet d’applications à gérer
Alors qu’apporte Docker ?
Docker offre un environnement d’exécution au sein d’un Linux (ou d’une VM, comme VirtualBox sur Mac) afin d’exécuter différents conteneurs.
Version avec Docker. Chaque application est isolée dans un conteneur Docker
Docker, un github-like de conteneurs ?
Docker reprend aussi quelques idées de Github. Vous n’avez pas à démarrer de zéro lorsque vous souhaitez créer un conteneur. Vous pouvez très bien partir d’un conteneur déjà configuré, avec par exemple Apache et PHP, pour ajouter uniquement un WordPress. Pour cela, index.docker.io/ propose un annuaire de conteneurs Docker. Vous pouvez ainsi récupérer et installer un environnement complet avec Java + une base MySQL, ou un serveur Node avec un Mongo correctement configuré.
Si vous souhaitez ensuite modifier l’image d’un conteneur, sachez qu’il est possible de sauvegarder vos modifications… avec un docker push. Toute ressemblance avec git est fait exprès. Docker a repris l’idée de Git. Vous pouvez donc pusher, commiter et sauvegarder vos modifications… ou pas.
Lorsque vous utilisez une base de données, il sera cependant indispensable de monter un volume externe au sein de votre conteneur, afin de pouvoir conserver de manière persistence vos changements. Sinon, vous perdriez tout dès lors que le conteneur est arrêté.
Voyons comment utiliser Docker maintenant…
A lire aussi : How Docker was born
0 no like
Fermer la bouche du chef de la production … un doux rêve.
Pour ma part, j’utilise LXC depuis maintenant un an et demi et avec les templates, c’est franchement facile de faire un container pour chaque application développée. Je vois Docker comme la version très organisée de tout ça et j’ai hâte de jouer avec.
Je ne peux plus envisager de développer ou déployer ailleurs que dans un container (sous Python, j’utilise virtualenv pour les containers). Ca prend 5 minutes à mettre en place, et ça te sauve des semaines en configuration.
Hello,
Article intéressant.
Est ce que le fait d’utiliser des container docker nécessite des ressources supplémentaires sur la machine de dev par rapport à une installation direct des composants techniques sur la machine?
Fabrice
Hello,
Effectivement, Docker est super intéressant !
J’aimerai pouvoir l’utiliser chez mon client mais je me heurte à divers problème.
Comment l’utiliser dans une entreprise qui bloque tout avec des proxy ( et donc sans accès direct à l’index docker.io )…
Il me manque un proxy à la nexus. Il y a bien le registry, mais si je ne me trompe pas, il permet de stocker des images « custom », mais pas proxy de l’index?
Au pire, je veux bien récupérer uniquement les images de base ( ubuntu ), et les mettres manuellement dans un registre. Mais comment récupérer les images ?
docker permet d’exporter des containers, mais je n’ai pas les images.
Bon, après je peux toujours tenter 200 réunions pour ouvrir index.docker.io mais bon 🙂
J’ai été médisant, y a docker save .
Faudra que je teste ! 🙂
@fabszn
C’est du container à la LXC, tu ne perds rien en performance car tu utilises les ressources disponibles de la machine hôte directement. C’est juste que tes applications sont cloisonnées sur une sorte de chroot avec une zone mémoire non partagée avec les autres containers.
Une des très bonnes choses avec LXC et Docker, c’est que le meilleur environnement pour les utiliser en développement est … Linux.
Et d’amener à une meilleure connaissance de l’OS et donc à des applications de mieux en mieux conçues pour lui 🙂
J’aime bien Docker, ansi que l’enthousiasme technique qui va avec.
Docker challenge bien des choses, et pas seulement « le grand chef de la prod » dont on veut fermer le clapet.
Docker challenge également l’esprit Devops, en s’inscrivant régulièrement dans la mouvance noops (d’ailleurs ce post tient des propos qui sont bien loin de ceux de la culture du partage mise en avant par le mouvement Devops).
C’est encore un peu difficile de faire entendre un avis mitigé concernant Docker, on est encore en plein hype.
Docker est fait pour le cloud, pour les startup ou les organisations du type « you build, it you run it !» (le « A à Z » quand on livre du container, c’est aussi la partie « you run it !»).
Le container, cet objet sympathique porté à dos de Baleine, animal sympathique, peut avoir une image moins réjouissante.
Celle de l’opacité, celle de la non maintenabilité et de la non évolutivité.
L’empilage des commits peut être comparé avec de l’héritage en cascade, et on sait ce que cela vaut en termes de maintenance/évolutivité/curation (always always favor composition over inheritance !).
L’opacité du container en tant qu’objet de livraison m’effraie un peu. Pas en tant que telle, mais simplement parce que l’homme est mauvais par nature (c’est toujours le capitaine Haddock diabolique qui l’emporte sur son alter ego angélique), et qu’un « paquet » pour les empaqueter tous permettra de bypasser nombre de bonnes pratiques de développement ou de production.
Bref, je pense que Docker avec l’esprit « Noops /Developper pride » risque de produire des bombes à retardement en production d’entreprise.
A moins que tout le monde (dev et prod) fasse partie de la même équipe. Dans ce cas « you build it you run it’ » et tout va bien.
Mais tout le monde ne travaille pas dans une startup qui vit dans les nuages … et à mon humble avis, ca serait mieux de collaborer avec « le grand chef de la prod » pour rendre les containers transparents pour tout le monde, et en particulier partager les décisions techniques.
Sous peine de renvoyer les containers « sous-optimaux » à leur créateur « le développeur, responsable de A à Z » !
Amicalement
Impatient de lire la suite !
Merci
J’utilise docker dans le cadre des tests lancé par Jenkins. Via un plugin maven, je liste un ensemble images docker nécessaire à l’exécution de mes tests (container postgresql correctement configuré avec les users et bases de tests, un container cassandra etc..) et celui ci se charge de lancer les containers avant de lancer les tests (pre-integration-test). Ca me permet d’éviter de mocker les briques systèmes et d’avoir un environnement bien défini. Qu’en pensez vous ?
Dans ton exemple tu aurais du considéré de mettre chaque « brique » dans un Dockerfile séparé et d’utiliser les « LINK » docker, c’est alors encore plus flexible
Construire et tester ses container sur le poste de dev puis déployer les mêmes containers en production c’est un rêve qui devient réalité. Perso je suis devenu fan.