KubeCon : les containers, nouvelles vedettes de l’infrastructure

Les containers, des VM moins chères, plus performantes et plus simples

D’une manière générale, informaticiens et fournisseurs considèrent que les containers sont avant tout des machines virtuelles, mais plus simples, plus performantes et moins chères que les solutions traditionnelles de VMware et consort.

« La raison première qui nous a incités à passer aux containers est de ne plus avoir à faire les mises à jour de l’OS dans chacune des 150 machines virtuelles que nous avions auparavant en exploitation », nous confie par exemple Simon Lallemand, ingénieur système chez BlaBlaCar. « Avec les containers, il n’y a plus qu’à mettre à jour l’OS sous-jacent une fois pour toutes les instances de nos applications. L’IT gagne beaucoup de temps ».

Il ajoute que l’utilisation des containers a accessoirement permis à BlablaCar d’augmenter à plus de 2000 le nombres de ses instances virtuelles, sans avoir à acheter de nouvelles licences chez VMware.

Même constat chez Amadeus (qui est aussi très Cloud), où Eric Mountain, l’expert des systèmes distribués, explique utiliser des containers depuis 2014 pour faciliter les mises à jour système et maximiser les performances de ses applications interrogées en permanence par les transporteurs du monde entier.

En revanche, il concède n’avoir toujours pas mis en place un système de containers qui permettrait aux développeurs d’automatiser le déploiement de leurs codes.

Car initialement, les containers devaient permettre aux développeurs d’écrire leurs applications sous forme de segments indépendants (le terme consacré est « micro-services »), afin de mettre à jour des bouts de code sans devoir modifier toute l’application. L’intérêt annoncé était d’éviter de redéployer une application entière, sur tous les serveurs, à chaque fois qu’une seule de ses fonctions évolue.

Les efforts de VMware et Red Hat pour s’emparer du support

OpenShift, l’environnement d’industrialisation de mise en production des applications signé Red Hat, vient même d’être renommé « OpenShift Container Platform », alors que son utilisation des containers n’est qu’anecdotique au regard de toutes les fonctions que le logiciel offre aux développeurs.

« Au vu de l’explosion actuelle de la demande pour les containers, nous pouvons à présent considérer qu’OpenShift incarne l’avenir de notre distribution système Entreprise Linux », nous a confié Lars Hermann, le directeur des solutions d’intégration chez Red Hat. Le Red Hat Summit, qui aura lieu en mai prochain à Boston, devrait, nous a-t-il dit, être le théâtre de plusieurs annonces concernant les containers.

Signe de ce glissement des containers vers le monde de l’infrastructure, VMware s’est lui-même déplacé à KubeCon pour annoncer la disponibilité d’une multitude de modules qui rendent sa solution de virtualisation vSphere compatible avec les containers. Citons Photon, le Linux qui exécute les containers (depuis une VM) tout en sachant communiquer avec les fonctions de l’hyperviseur ESXi, Admiral qui orchestre le fonctionnement des containers depuis la console vRealize Automation, ou encore Harbor qui fait office de catalogue de containers prêts à déployer.

Tous sont en Open Source, sous l’égide de Dirk Hohndel, l’ancien patron de l’Open Source que VMware a débauché d’Intel. Et tous s’interfacent avec les projets Open source qui formalisent le fonctionnement des containers. En l’occurrence le moteur de base Docker, l’orchestrateur Kubernetes et Cloud Foundry, la plateforme Open Source PaaS que concurrençait initialement OpenShift. Selon nos sources, VMware serait bientôt compatible avec Swarm, le concurrent de Kubernetes.

Comme Red Hat, VMware ambitionne de vendre aux entreprises du support pour encadrer la déferlante des containers dans leur IT, un marché qui n’existe pas encore. « La plupart des entreprises en sont encore à des phases de test et n’utilisent pour l’heure que des outils Open Source de base. Mais quand leurs projets prendront de l’ampleur, quand ils permettront de faire gagner de l’argent à l’entreprise, ces dernières devront assurer leur production avec notre support. Quand on part en production, tout le monde apprécie d’avoir un fournisseur qui réponde dans les quatre heures pour résoudre le moindre problème », argumente Brice Dereims, architecte Cloud chez VMware.

La délicate question des containers embarqués dans des VM

De fait, la question qui aura animé cette manifestation est celle de la manière d’exécuter les containers : faut-il les faire fonctionner directement sur un serveur physique ( « bare metal ») ou à l’intérieur d’une machine virtuelle ?

VMware ne tarit bien évidemment pas d’arguments en faveur de la seconde option. « Le bare metal n’a aucun sens car les containers ont trop peu d’options d’infrastructures par rapport aux machines virtuelles ! En les exécutant depuis des machines virtuelles, on peut déplacer à chaud les charges de travail d’un serveur physique à l’autre, voire d’un datacenter à un Cloud public. Et cela sans perdre l’accès au stockage, en ajoutant en plus des règles d’accès réseau pour la sécurité », assure Brice Dereims.

On remarquera que Brice Dereims fait ici successivement référence aux technologies VMware vMotion, vSAN et NSX. Fait notable, il existe désormais un module réseau NSXT, compatible avec les hyperviseurs Hyper-V de Microsoft et KVM de Linux., qui chapeaute les switchs virtuels Open vSwitch. Une manière pour VMware de concurrencer sur son propre terrain OpenStack, la plateforme Open source d’orchestration d’infrastructure qui a, elle aussi, tendance à suggérer que les containers seraient mieux gérés depuis des VM.

Red Hat a un avis bien moins tranché. « Les entreprises qui mettront des containers dans des machines virtuelles ne le feront que parce qu’elles veulent déployer un maillage d’applications qui communiquent en réseau. Mais s’il s’agit d’exécuter plusieurs instances d’une même application Java - comme c’est la majorité des cas aujourd’hui en entreprises - vous aurez tout intérêt à exécuter vos containers en bare metal. D’autant que le fonctionnement en container seul consomme bien moins de puissance de calcul qu’au travers des machines virtuelles », répond Brian Gracely, directeur de la stratégie produits chez Red Hat. On considère en moyenne que dix containers consomment autant de puissance qu’une seule VM.

Des outils qui progressent vers les besoins des entreprises

On retiendra deux annonces majeures lors de cet événement, toutes deux orientées infrastructure.

D’abord la nouvelle version 1.6 de Kubernetes, qui permet de déployer des containers sur une flotte de serveurs dont le nombre a été étendu à 5000 (contre 2000 auparavant). Cette version apporte également le cloisonnement entre des grappes des containers ainsi que la faculté d’accéder à un stockage local. Des caractéristiques qui, aux yeux des observateurs, permettent à cet orchestrateur de containers en cluster de distancer ses concurrents Swarm et Mesos.

C’est en tout cas l’avis des ingénieurs d’Orange, qui se refusaient jusqu’à présent à utiliser autre chose que le moteur Docker de base. « Les nouvelles fonctions de Kubernetes remplacent enfin quantités de scripts d’administration que nous devions jusqu’ici écrire nous-mêmes, faute de trouver dans l’existant de quoi répondre à nos besoins. En particulier, elles vont nous permettre de déployer les containers de plusieurs de nos clients sur un seul cluster », commente Philippe Alexandre, ingénieur chez Orange.

Il ajoute : « nous voyons Kubernetes devenir petit à petit un standard. En face, Mesos se confine de plus en plus à des cas d’usage uniquement Big Data. Quant à Docker Swarm, force est de constater que son développement se perd dans les retards. »

L’autre annonce est celle du lancement de Weave Cloud Enterprise par Weaveworks, le logiciel de monitoring qui a suscité le plus d’enthousiasme parmi les visiteurs interviewés par LeMagIT.

« Weave Cloud Enterprise présente une cartographie en temps réel des containers et de leurs flux de communication. L’avantage est qu’il n’y a rien à configurer : l’outil tourne à côté de Docker, il lit les logs, découvre tout seul le réseau. Il stocke l’activité dans un historique, que l’on peut interroger avec un langage de requête pour croiser des informations », résume David Kaltschmidt, Ingénieur en chef chez WeaveWorks.

L’outil serait d’ores et déjà à l’étude chez Accenture et les équipes d’IBM BlueMix.