Pour la deuxième journée de la conférence OpenStack, Adrian Otto est venu expliquer devant un parterrre de peu de 2000 personnes comment son groupe de 42 ingénieurs, membres de la communauté Openstack, avait travaillé depuis le 20 janvier, date du début de son projet de gestion de conteneurs, Magnum.
Adrian Otto travaille comme architecte chez Rackspace. Il est aussi le président du projet conteneurs d’OpenStack, et chef d’équipe sur les deux projets Solum et Magnum. A l’occasion de l’OpenStack Summit à Vancouver, il est donc venu montrer pour la première fois un outil d’administration de conteneurs qui marque le souci de la communauté OpenStack de consolider les projets de conteneurs concurrents de sa « petite » plate forme Ironic. Dans la phase d’expérimentation actuelle, hormis docker qui paraît dominer actuellement, plusieurs technologies très proches les unes des autres comme Rocket, Kubernetes, Mesos, XLC se concurrencent. Mais il faut distinguer ce qui appartient à l’offre conteneur, elle-même, sans outils de développement, des outils d’orchestration et de gestion. Dans l’univers OpenStack, d’autres techniques de gestion comme Murano, Kolla, sont aussi en phase d’expérimentation.
Petit rappel sur les conteneurs
Pour ceux qui n’auraient pas eu le temps de se familiariser avec les conteneurs, (lire l’article Quels défis dans la mise en place des containers ?) rappelons que ceux-ci sont en train de devenir à priori la solution miracle pour faire tourner des applications dans le cloud. La différence entre applications virtualisées et applications « conteneurisées », outre l’économie des licences des hyperviseurs, provient de la réduction drastique du volume de code utilisé. Cette évolution donnerait la possibilité de faire tourner des dizaines d’applications sur un seul serveur qui n’acceptait jusque-là qu’une demi douzaine d’applications virtualisées de manière classique. Ce « miracle » annoncé paraît incroyable et laisse sceptiques pas mal d’observateurs mais vu l’enthousiasme qu’il suscite chez les fournisseurs et les premiers utilisateurs, il y a certainement une grande part de vérité. ( Pour une explication plus détaillée sur la concurrence des hypervisuers, lire à la fin l’encadré les hyperviseurs face aux conteneurs).
Ce matin, donc, Adrain Otto a montré Magnum dont l’intérêt est de pouvoir contrôler plusieurs containers de natures différentes ( Docker Swarm et Kubernetes pour l’instant mais une demi douzaine sont en cours d’étude) et de pouvoir répartir la charge de travail entre différents serveurs. Otto expliquait sa démarche : « On peut se servir des conteneurs non pas comme des espaces « de calculs « mais aussi comme des outils pratiques et légers. On est parti sur ce projet de gestion de conteneurs à l’inverse de ce que l’on fait généralement. D’habitude, dans l’open source, il y a une ou deux personnes qui partent sur une même seule idée et puis au fur et à mesure se greffent d’autres idées, d’autres participants ingénieurs et l’on se met à produire des dizaines de points de repères et des éléments de conceptions et des requêtes par centaines, ce qui ne fait qu’alimenter une base de données de problèmes à résoudre. Là on est parti de milliers de requêtes sur les conteneurs et l’on a crée le cahier des charges autour des conteneurs. On peut déjà le faire avec un hyperviseur classique, à condition que ce soit le même partout.» Comme la démonstration de Magnum a été interrompue pour des problèmes de communication, les centaines de spectateurs sont restés sur leur faim. Mais à peine un quart d’heure plus tard, l’architecte en chef de Google lui même, 
( photo), est venu apporter son support à la technologie de conteneur en collaborant avec un ingénieur de l’intégrateur Mirantis à une démonstration en « live » pour échanger des conteneurs dans un cadre à priori neutre, celui des clouds de rackspace, pourtant concurrent sous certains angles de Google. Sandee Parikh après avoir avoué qu’il avait déjà mis en service des milliers de conteneurs de chez Kubernetes, se retrouvait coincé par l’absence de réseau.
La tentative de partager les différents conteneurs s’est donc conclue prématurément, la loi des « plantages » lors des présentations en direct ayant encore frappé deux fois. Mais on se souviendra que pour la première fois des solutions d’interropérabilité entre conteneurs ont été montrées ainsi que des solutions en cours de développement actif.
Les conteneurs, un bon moyen de « presque » se débarrasser des hyperviseurs
Rappelons que la virtualisation « classique » permet, via un hyperviseur comme Vmware, HyperV ou KVM, de simuler sur un même serveur une ou plusieurs machines physiques, et les exécuter sur ce serveur. Chaque machine physique « virtualisée » intègre elle-même un vrai OS sur lequel ses applications sont exécutées. Dans le cas du container, le processus fait en effet directement appel à l’OS de la machine hôte pour réaliser ses appels systèmes sans passer par des liens et des os intermédiaires. C’est une économie de puissance indéniable. On l’étend par le biais d’une API dans l’optique d’exécuter les applications dans des containers standards aptes à se déplacer d’un serveur à un autre.
puis