Comment les conteneurs donnent naissance au Cloud v2

Les conteneurs, une techno de développeurs ? Des solutions comme Docker sont effectivement nées pour simplifier la vie de cette population, mais elles intéressent aussi désormais la production, comme en témoigne une table ronde organisée lors de Cloud Computing World Expo (23 et 24 mars, à Paris). Bien sûr, des mouvements comme le Devops favorisent l'emploi d'une même technologie du poste de développement au serveur de production, mais les responsables de l'infrastructure ont aussi leurs propres raisons de s'intéresser aux conteneurs. « Contrairement aux machines virtuelles, qui nécessitent un hyperviseur, le conteneur amène la virtualisation au niveau OS, résume Xavier Mesnil, architecte IT chez Zebestof. On partage le noyau Linux entre de multiples conteneurs, sans la perte de performances que provoque la virtualisation. »

Autrement dit, la technologie permet d'atteindre des performances hors de portée des VM, donc des niveaux de densité inconnus jusqu'alors. « A configuration identique, on passe par exemple de 100 VM à des centaines, voire des milliers de conteneurs », reprend l'architecte de ce spécialiste de la publicité programmatique (ou RTB pour Real Time Bidding). Dans un entretien avec Silicon.fr, Xavier Mesnil parle d'un rapport allant de 1 à 10 en termes de densité, à tel point que le goulet d'étranglement sur l'infrastructure de la société s'est déplacé vers le réseau (Zebestof a d'ailleurs migré vers des switch 10 Gbit/s).

AWS ? Trop cher

C'est d'ailleurs bien la question des performances qui a amené Zebestof aux conteneurs. En pic, la plate-forme du prestataire reçoit 80 000 requêtes par seconde. A la recherche d'une architecture capable d'encaisser de tels volumes et les montées en charge associées, la société, aujourd'hui dans le giron du groupe Le Figaro, se tourne d'abord vers AWS. « Au bout de quelques mois, on s'est rendu compte que le Cloud public avait un coût, dit Xavier Mesnil. Sur AWS, les hits HTTPS ou ceux sur le load balancer coûtent chers. » D'où la décision de réinternaliser, sur un Cloud privé. Et de partir sur les conteneurs, pour maximiser les performances offertes par l'infrastructure (actuellement 15 serveurs 32 coeurs SSD de marque Dell, pour gérer tous les environnements). L'architecture mise en place permet également d'encaisser les pics de charge, via l'ajout de nouveaux noeuds au cluster.

L'équipe de Docker.

« En 2013, au moment de la réflexion sur ce projet, Docker n'existait pas : nous avons donc opté pour OpenVZ (autre technologie de conteneurs pour Linux, NDLR), raconte l'architecte. Si nous démarrions le projet aujourd'hui, nous partitions probablement sur Docker d'autant que les limitations qui freinaient cette technologie en 2014 ont été levées. » Même si, selon Xavier Mesnil, Docker reste inadapté à certains usages, et serait plutôt réservé aux conteneurs applicatifs n'ayant pas vocation à être modifiés une fois lancés. « Ce modèle ne fonctionne pas avec un SGBD classique », observe l'architecte. Contrairement à OpenVZ, dont la maturité sur ces sujets est bonne, avec la capacité à gérer le nombre d'accès disque par conteneur ou l'allocation fine de puissance machine. Même si ces paramètres doivent être partagés par tous les conteneurs d'un même noeud.

Du dev à l'ops, au bit près

En plus de fonctionner à entre 1/3 et 1/4 du prix de son équivalent sur AWS, l'infrastructure en conteneurs de Zebestof a amené un autre bénéfice. « C'est le petit cadeau en plus, celui qu'on n'attendait pas : on a découvert que les conteneurs étaient synonymes de reproductibilité », dit l'architecte IT. A toutes les étapes, du poste du développeur au serveur de production, les équipes travaillent sur des environnements identiques au bit près, les conteneurs embarquant toutes les librairies partagées. « On a donc amélioré la vitesse du workflow entre les développeurs et la production », résume Xavier Mesnil.

[A lire, notre dossier : Docker, déjà bon pour le service ?]

C'est une histoire parallèle que raconte Gérald Croes, architecte SI d'Alptis, un courtier et grossiste en assurance qui, à l'occasion d'une refonte de son SI poussée par une modification de l'environnement réglementaire (l'obligation pour les employeurs de proposer une complémentaire santé à leurs salariés), a basculé vers la technologie Docker. « Les conteneurs n'ont jamais été une obligation, détaille l'architecte. Mais nous avions besoin de passer d'un système ensembliste de 20 ans d'âge, à des systèmes plus légers communicant entre eux. Les conteneurs ont permis de donner de l'autonomie aux différentes équipes et de réécrire les applications par blocs. » L'assureur a mis en place une architecture de micro-service, avec « des acteurs logiciels regroupés par domaines et orchestrés par l'application elle-même ». Fonctionnant sur un cluster de 5 machines, la production - environ 200 conteneurs - est hébergée dans une machine virtuelle. Une façon, notamment, d'évacuer les problématiques de sécurité que peut encore soulever Docker.

Un Docker encore adolescent

L'assureur, qui étudie aujourd'hui le recours au Cloud public en complément (notamment pour les applications ne gérant pas de données personnelles), a tout de même dû se frotter aux problèmes d'adolescence de Docker. « Nous avons été confrontés à des bogues difficiles à corriger, d'autant qu'au lancement du projet, très peu de prestataires étaient en mesure d'apporter du conseil autour de la technologie », se remémore Gérald Croes. Qui met également en exergue le besoin d'automatisation que créent les architectures de micro-services : « Orchestrer l'ensemble des conteneurs n'est pas humainement possible. Et on a besoin d'un système traçant les chaînes d'appel entre services », dit-il. Chez Alptis, la DSI a choisi Jenkins comme orchestrateur principal, secondé par Mesos Marathon pour la partie conteneurs.

Tant chez Zebestof que chez l'assureur, les deux architectes soulignent l'impact des conteneurs sur l'organisation de la DSI. « Cette technologie renferme un piège sur ce terrain, explique Xavier Mesnil, de Zebestof. Elle peut laisser croire que tout ce qui est à l'intérieur des conteneurs relève des devs, tandis que la responsabilité des ops se limiterait à l'extérieur de ces enveloppes virtuelles. Une telle vision est par trop réductrice. » Selon lui, elle aboutit à un risque de perte de compétences des ops et ce que les développeurs effectuent des choix ayant des impacts très lourds en production. Le constat dressé Gérald Croes n'est pas très éloigné : « Un conteneur ne pèse que 300 Mo en moyenne chez nous. Les équipes, notamment les développeurs, ont tendance à surconsommer. Par ailleurs, si cette consommation est devenue simple pour l'équipe de développement, c'est au prix d'une importante dose de complexité absorbée par l'architecture. »

A lire aussi :

Avec Clair, CoreOS scrute les failles de sécurité des conteneurs

Pour son anniversaire, Docker saute le pas de Windows et Mac

Crédit Photo : Donvitorio-Shutterstock