Le rapport entre Docker et ZooKeeper ou etcd ? L'éco-système, docker est la brique de base qui te permet de faire de l'isolation mais dès que tu veux faire du déploiement multi machine tu as d'autre besoin que juste l'isolation tels que le load balancing, la haute dispo, la découverte automatique de service etc... Et ça Mesos peut l'apporter. Mais le coeur de Mesos repose sur l'algo à consensus Zookeeper qui n'est pas celui choisi par d'autre projet gravitant autour de Docker. Kubernetes de google utilise etcd et coreOS aussi. Y a un port en cours pour intégrer Kubernetes avec Mesos. Et avoir zookeeper et etcd en parallèle c'est un peu bancal comme architecture. Donc y a un travail en cours pour avoir un backend etcd à Mesos. Y a aussi un travail en cours pour intégrer l'api de Docker Swarm.
Et pour faire tourner du Hadoop, Spark et Storm sur le meme cluster tu as besoin d'isolation, avant Mesos proposait sa propre implémentation (toujours à base de cgroups) mais depuis la version 0.20 docker est devenue une brique "1st citizen". Il se repose dessus pour fournir leur isolation. L'ancienne implémentation reste disponible, tout ceci est configurable a travers la ligne de commande qui lance le mesos-slave. Mais meme si tu fait tourner du Storm et du Spark tu as tout de meme besoin d'isolation entre ses framework et tu peux utiliser docker comme conteneur.
Docker n'est pas un framework Mesos de plus, c'est pas au même niveau dans la "stack Mesos", tu as tout en haut les frameworks (Storm,Hadoop,ElasticSearch,Jenkins,MPI,Aurora,Marathon...) et en bas, au niveau des executeurs, (sur les slave mesos) tu as le conteneur (soit l'implémentation mesos de base, soit depuis la 0.20 docker). Donc je me permet d'insister, au vue de développement en cours (le jira mesos est public), il y de plus en plus de développement qui sont fait pour s'intégrer avec l'eco-système Docker (Docker Swarm,Kubernete,support etcd) et Docker est maintenant une brique de base de la stack Mesos (Elle n'est pas irremplaçable puisque l'ancienne implémentation reste disponible mais c'est tout de même une brique de base).
Concernant LXC, oui Docker était une surcouche à LXC et ils ont implémenté libcontaineur parce qu'il en avait marre de gérer les api breaks et les X versions différentes de LXC. J'ai la flemme de me replonger dans les mailings list docker mais ça transpire même dans l'annonce officiel : http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
This drastically reduces the number of moving parts, and insulates Docker from the side-effects introduced across versions and distributions of LXC. In fact, libcontainer delivered such a boost to stability that we decided to make it the default
Au passage pour ne pas opposé docker et LXC, la libcontainer dispose de plusieurs backend (celui par défaut en go) mais rien ne t’empêche d'utiliser LXC ou LMCTFY de google etc...
Mais si tu me relis tu verra que je dis que Docker n'apporte pas grand chose technologiquement parlant mais je suis pas d'accord pour dire que le hard work était LXC. C'était tout autant du hard work d'arriver à fédérer une communauté ouverte avec des gros acteurs du domaine, qui s'accorde pour dire : "on fait plus les choses dans notre coin, on utilise docker comme API de containérisation, on parle le même language et on bâti nos outils autour de cette solution car on a une techno simple à utiliser, clairement documenté, avec un processus de décision clair et ouvert.
LXC bien que beaucoup plus vieux que Docker n'a jamais décollé parce que centré sur lui même, de la technique pur mais aucune communication autour ni vraiment de doc (Ubuntu la dessus à rater une belle occasion et maintenant il tente de ce rattraper avec lxd).
Après je pense que la discussion va devenir stérile, on parle de la même chose mais avec une vue différente, tu parle technique, je parle éco-système. Je préfère mille fois une techno "non parfaite" utilisé par tous et avec un processus de qualité (Doc,livraison,roadmap,processus pour participer clairement établie) qu'une techno "parfaite" mais peu utilisé et mal documenté ...
Pour toi Mesos et Docker sont complément disjoint et techniquement parlant tu as raison.
Pour moi il forme un tout cohérent et d'un point de vue service j'ai raison.
```
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . En réponse au journal Docker, la plateforme à la mode. Évalué à 6.
Le rapport entre Docker et ZooKeeper ou etcd ? L'éco-système, docker est la brique de base qui te permet de faire de l'isolation mais dès que tu veux faire du déploiement multi machine tu as d'autre besoin que juste l'isolation tels que le load balancing, la haute dispo, la découverte automatique de service etc... Et ça Mesos peut l'apporter. Mais le coeur de Mesos repose sur l'algo à consensus Zookeeper qui n'est pas celui choisi par d'autre projet gravitant autour de Docker. Kubernetes de google utilise etcd et coreOS aussi. Y a un port en cours pour intégrer Kubernetes avec Mesos. Et avoir zookeeper et etcd en parallèle c'est un peu bancal comme architecture. Donc y a un travail en cours pour avoir un backend etcd à Mesos. Y a aussi un travail en cours pour intégrer l'api de Docker Swarm.
Et pour faire tourner du Hadoop, Spark et Storm sur le meme cluster tu as besoin d'isolation, avant Mesos proposait sa propre implémentation (toujours à base de cgroups) mais depuis la version 0.20 docker est devenue une brique "1st citizen". Il se repose dessus pour fournir leur isolation. L'ancienne implémentation reste disponible, tout ceci est configurable a travers la ligne de commande qui lance le mesos-slave. Mais meme si tu fait tourner du Storm et du Spark tu as tout de meme besoin d'isolation entre ses framework et tu peux utiliser docker comme conteneur.
Docker n'est pas un framework Mesos de plus, c'est pas au même niveau dans la "stack Mesos", tu as tout en haut les frameworks (Storm,Hadoop,ElasticSearch,Jenkins,MPI,Aurora,Marathon...) et en bas, au niveau des executeurs, (sur les slave mesos) tu as le conteneur (soit l'implémentation mesos de base, soit depuis la 0.20 docker). Donc je me permet d'insister, au vue de développement en cours (le jira mesos est public), il y de plus en plus de développement qui sont fait pour s'intégrer avec l'eco-système Docker (Docker Swarm,Kubernete,support etcd) et Docker est maintenant une brique de base de la stack Mesos (Elle n'est pas irremplaçable puisque l'ancienne implémentation reste disponible mais c'est tout de même une brique de base).
Concernant LXC, oui Docker était une surcouche à LXC et ils ont implémenté libcontaineur parce qu'il en avait marre de gérer les api breaks et les X versions différentes de LXC. J'ai la flemme de me replonger dans les mailings list docker mais ça transpire même dans l'annonce officiel :
http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
Au passage pour ne pas opposé docker et LXC, la libcontainer dispose de plusieurs backend (celui par défaut en go) mais rien ne t’empêche d'utiliser LXC ou LMCTFY de google etc...
Mais si tu me relis tu verra que je dis que Docker n'apporte pas grand chose technologiquement parlant mais je suis pas d'accord pour dire que le hard work était LXC. C'était tout autant du hard work d'arriver à fédérer une communauté ouverte avec des gros acteurs du domaine, qui s'accorde pour dire : "on fait plus les choses dans notre coin, on utilise docker comme API de containérisation, on parle le même language et on bâti nos outils autour de cette solution car on a une techno simple à utiliser, clairement documenté, avec un processus de décision clair et ouvert.
LXC bien que beaucoup plus vieux que Docker n'a jamais décollé parce que centré sur lui même, de la technique pur mais aucune communication autour ni vraiment de doc (Ubuntu la dessus à rater une belle occasion et maintenant il tente de ce rattraper avec lxd).
Après je pense que la discussion va devenir stérile, on parle de la même chose mais avec une vue différente, tu parle technique, je parle éco-système. Je préfère mille fois une techno "non parfaite" utilisé par tous et avec un processus de qualité (Doc,livraison,roadmap,processus pour participer clairement établie) qu'une techno "parfaite" mais peu utilisé et mal documenté ...
Pour toi Mesos et Docker sont complément disjoint et techniquement parlant tu as raison.
Pour moi il forme un tout cohérent et d'un point de vue service j'ai raison.
```