L'écosystème Docker a été secoué par l'annonce de Rocket, un runtime alternatif à Docker développé par CoreOS.
Le constat de CoreOS est que Docker ne repose pas sur des bases suffisamment sécurisées (un démon central tournant sous root) ni flexibles. Leur idée est de coller à l'esprit unix : des outils très spécialisés, faisant bien une tâche et une seule, qu'on intègre ensembles. Sauf que Docker va dans une direction un peu différente. Les évolutions proposées et développements en cours visent à doter docker de capacités d'orchestration, de provisioning, et de gestion réseau. Il s'agit de proposer des points d'extension dont docker serait le maître d'orchestre, pour contrôler N machines sur lesquelles vous déploierez X containers reliés entre eux par un réseau privé.
Là où ça clashe, c'est dans le ton utilisé par CoreOS (lisez leur blog) qui est tout de même assez dur. Salomon a d'ailleurs répondu sur twitter en expliquant la philosophie d'une part du projet docker (oss) et de la compagnie :
 | solomonstre 1) interface to the app and developer should be standardized, and enforced ruthlessly to prevent fragmentation #dockerway 01/12/2014 22:11 |
| solomonstre 2) infrastructure should be pluggable and composable to the extreme via drivers & plugins #dockerway 01/12/2014 22:11 |
| solomonstre 3) batteries included but removable. Docker should ship a default, swappable implementation good enough for the 80% case #dockerway 01/12/2014 22:11 |
| solomonstre 4) toolkit model. Whenever it doesn't hurt the user experience, allow using one piece of the platform without the others. #dockerway 01/12/2014 22:11 |
| solomonstre 5) Developers and Ops are equally important users. It is possible and necessary to make both happy. #dockerway 01/12/2014 22:12 |
| solomonstre 6) If you buy into Docker as a platform, we'll support and help you. If you don't, we'll support and help you :) #dockerway 01/12/2014 22:12 |
| solomonstre 7) Protect the integrity of the project at all cost. No design decision in the project has EVER been driven by revenue. #dockerway 01/12/2014 22:12 |
| solomonstre 8) Docker inc. in a nutshell: provide basic infrastructure, sell services which make the project more successful, not less. #dockerway 01/12/2014 22:12 |
etc (suivez @solomonstre si vous voulez la totale :P)
ayant un MacBook j'aime bien le #3 :D
Bon bref, l'idée de Docker c'est de fournir un outil clé en main qui couvre les cas principaux (le fameux 80%) tout en laissant l'implémentation remplaçable via des API standardisées, pour s'adapter aux besoins de chacun.
La réponse "officielle" de docker.com n'a pas tardé non plus, même si elle ne nous avance pas beaucoup.
Bon et alors. D'une part rocket est en 0.1, aussi c'est peut être très bien fait mais euh bon voilà. D'autre part, l'idée - plutôt bonne a priori - de définir un format standard de container, indépendant de l'implémentation du runtime, est malheureusement à ce jour uniquement implémentée par rocket. Il ne s'agit donc pas de prendre l'existant Docker, d'en "standardiser" une partie (autrement dit un standard de facto), et de proposer une implémentation différente.
Donc même si on peut prêter attention aux arguments de CoreOS ça semble être à ce jour essentiellement un FUD. Un peu comme si je vous disais que le code de Jenkins est tout pourri et que je lance le projet Jarvis, disponible on 0.0.1 sur mon github (hey, cherchez pas, c'est un exemple).
Bref, à moins que CoreOS ait du concret a dégainer rapidement ça va juste être un mauvais coup, 48h avant la DockerCon europe, genre totalement par hasard ...
2 commentaires:
Je trouve aussi que le timing est un poil abusé... Je comprend la stratégie mais ça affiche tout de suite les intentions. :/
Bon c'est clair que la communication est un poil agressive (il y aurait peut-être été plus juste de mettre Didier l'embrouille en illustration à la fin en fait :-) ).
Mais je trouve intéressant qu'une alternative se présente à Docker. Pour pas mal de raison, je trouve que la direction que prend Docker n'est pas la bonne. Comme CoreOS, je pense que l'on devrait se concentrer sur les fonctionnalités principales du container. Au lieu de cela, on est en train de rajouter des fonctions d’orchestration et autres pour finir avec une usine à gaz monolithique qui sera censé tout faire mais qui le fera mal.
D’autant que des solutions comme Mesos ou OpenStack gèrent déjà ces problématiques et elles le font bien. Elles peuvent sembler complexe pour des développeurs mais c’est surtout que les problématiques d’orchestration sont complexes.
Pourquoi vouloir réinventer la roue ? Il y a des choses plus urgentes à régler dans Docker. Car pour moi Docker n’est pas encore production-ready pour un ensemble de raisons (dont la sécurité).
Mais au final, avoir le choix c’est bien. On verra ce que donne chaque projet. D’autant que Docker ressemble quand même à une réécriture de LXC non ?
Enregistrer un commentaire