Open Source : Docker est-il menacé d’implosion ?

CloudDatacentersDSILogicielsOpen SourceOrchestrationProjetsVirtualisation
7 302 1 commentaire

Le torchon brûle au sein de la communauté Docker. Des sociétés utilisatrices et des partenaires de la start-up envisagent de créer un fork de la technologie de conteneurs.

Certains membres de la communauté Docker manifestent leur mécontentement vis-à-vis de la start-up éponyme, qui fait figure de porte-drapeau dans la mutation des infrastructures vers les conteneurs. Au point d’envisager de créer un fork, un dérivé du code Open Source appelé à vivre sa propre vie indépendamment de Docker. Le très spécialisé magazine The New Stack explique que des discussions de cette nature sont en cours au sein d’entreprises utilisatrices ou travaillant dans l’écosystème Docker. Des discussions « informelles », précisent nos confrères. La pomme de discorde ? La façon dont la start-up fondée par des anciens de l’Epitech gère le Docker Engine, le runtime maison permettant de construire et faire tourner des conteneurs. Le fork viserait aussi à régler différents problèmes relatifs aux déploiements en entreprise. Notamment les questions de stabilité, un prérequis pour espérer supporter des déploiements massifs au sein de grandes entreprises.

solomon_hykes
Solomon Hykes

Parmi ces mécontents, nos confrères citent les noms de Red Hat, Google, CoreOS (qui a lancé avec Rocket une alternative à Docker), Huawei et au moins deux entreprises utilisatrices de grande taille. Pour The New Stack, les dissensions se seraient cristallisées quand Docker a décidé d’intégrer sa propre technologie d’orchestration (Swarm) au Docker Engine… alors que la plupart des entreprises a fait le choix d’utiliser Kubernetes de Google. D’ailleurs ce n’est pas un hasard si, parmi les conjurés, on retrouve plusieurs fervents supporters de la technologie d’orchestration de Moutain View. En dehors de Google lui-même, qui exploite Kubernetes au sein de son Cloud public, CoreOS, qui propose du support pour cette technologie, et Huawei, qui a créé son propre outil à partir du code Open Source de Moutain View, peuvent légitimement s’inquiéter de voir Swarm bénéficier d’une intégration poussée avec le Docker Engine. De son côté, Red Hat se plaint des difficultés d’intégration entre systemd (système d’initialisation et daemon pour Linux), utilisé largement par ses clients, et le daemon de Docker. En cause, selon The New Stack, ce qui ressemble fort à des incompatibilités d’humeur entre Solomon Hykes, le co-fondateur et directeur technique de Docker, et le créateur de systemd, un salarié de Red Hat.

Une déclinaison ennuyeuse ?

Autre grief, plutôt issu de l’écosystème des sociétés travaillant autour des technologies Docker : le cycle très court des mises à jour chez Docker, rapidité qui casse fréquemment les compatibilités que ces fournisseurs garantissent à leur client. Bref, Docker voit sa technologie centrale, le Docker Engine, comme un produit et non comme une brique de base pour toute une communauté. D’où l’idée d’un fork, avec une version plus stable et plus « plan-plan » de la technologie. C’est d’ailleurs le sens d’une série de tweets, publiés fin août par Craig McLuckie, un évangéliste de Kubernetes chez Google, qui explique : « nous avons besoin d’une technologie cœur ennuyeuse ! » Priorité à la stabilité donc.

Dans un billet de blog, Bob Wise, un ingénieur de Samsung travaillant dans le Cloud et spécialiste de Kubernetes, écrit : « si votre équipe travaille en profondeur avec Kubernetes, Mesos ou Cloud Foundry, vous avez besoin d’une implémentation stable, simple, ennuyeuse de la technologie des conteneurs, avec les caractéristiques essentielles minimales, et d’un accord de la communauté autour de la création d’images, du nommage et de la publication ». Bref, un appel à ralentir la vitesse d’évolution des composants de base de la technologie.

Que va devenir l’Open Container Initiative ?

C’est finalement déjà le rôle que doit tenir le consortium Open Source OCI (Open Container Initiative), qui doit déboucher sur un format portable et ouvert, réconciliant Docker et CoreOS. Le consortium, placé sous l’égide de la Linux Foundation, réunit tous les grands noms de l’industrie. Les entreprises qui souhaitent s’affranchir de la tutelle de Docker peuvent miser sur cette initiative (ils en font d’ailleurs, pour la plupart, partie), pour bénéficier d’un runtime et désormais d’une image standard, gérés par l’OCI. Insuffisant ou trop lent aux yeux de Red Hat, Google, Huawei ou CoreOS ? En tout cas, certains membres de la communauté OCI ne se privent plus d’évoquer un pas supplémentaire, en créant un fork s’affranchissant totalement de la start-up fondée par Solomon Hykes.

Aujourd’hui, selon une récente étude, la technologie Docker est employée par 94 % des entreprises ayant adopté l’approche par conteneurs et plus de trois organisations sur quatre l’ont retenue comme le principal vecteur de leurs investissements dans ce nouveau type d’architecture. Suivent LXC (la technologie embarquée dans le noyau Linux) et rkt (le Rocket de CoreOS), crédités respectivement de 15 et 10 % (la somme des pourcentages, supérieure à 100 %, indiquant que de nombreuses entreprises testent plusieurs technologies). Le constat est moins florissant pour la start-up d’origine française en ce qui concerne les outils d’orchestration. Alors que son Swarm dominait en 2015, il est aujourd’hui largement devancé par Kubernetes, l’outil de Google.

A lire aussi :

Conteneurs : un format unique pour réconcilier Docker et CoreOS

Après avoir séduit les devs, Docker cajole les admins

Clusters Swarm, réseaux virtuels… : Docker s’attaque à la production

crédit photo © Egorov Artem – shutterstock

Lire la biographie de l´auteur  Masquer la biographie de l´auteur