La technologie des containers arrive à maturité et devient la coqueluche des services informatiques. Pas si jeunes que cela, les containers impliquent de nouvelles contraintes et de nouvelles pratiques.

Les containers envahissent les infrastructures informatiques. Leur utilisation dans les entreprises explose. Selon un rapport de novembre dernier de la Cloud Native Computing Foundation (CNCF), 54% des entreprises utilisent des containers, principalement celles comptant plus de cent salariés : 92 % des répondants utilisent cette technologie en production. Cela représente 300 % de croissance par rapport à l’utilisation des containers en 2016 : 91 % orchestrent les containers avec Kubernetes dont 83 % en production ; 55 % font fonctionner des applications stateful dans les containers; 12 % évaluent cette possibilité et la même proportion pense le faire dans les douze mois à venir. Les répondants indiquent aussi qu’ils ont recours à 81 % à plus de vingt machines virtuelles ou physiques pour leurs environnements en containers. À 41 %, la complexité et le changement sont mis en avant comme les principaux freins à de plus larges déploiements, ce qui peut être une explication à un recours accru au Cloud public (64 %) en légère augmentation depuis l’année précédente.

Une étude de Datadog, un éditeur de solutions de monitoring et de supervision des environnements cloud natifs, confirme ces chiffres. Plus de la moitié des environnements en containers fonctionnent sous Kubernetes. Et plus de 90% des containers sont orchestrés par Kubernetes ou d’autres outils comme Amazon ECS, Nomad ou Mesos. Le marché global des containers applicatifs devrait frôler les 5 milliards de dollars en 2023, avec une croissance moyenne pondérée annuelle de 39%.

Une évolution de la virtualisation?

Si on a longtemps opposé les technologies de virtualisation et de containerisation, Christophe Jauffret, architecte solutions chez Nutanix, voit une complémentarité entre les deux technologies : « 90% des containers tournent sur des machines virtuelles, il n’y a pas de collision entre les deux. La virtualisation apportait une abstraction du matériel et le container celle du système d’exploitation. Mais si cela allège au niveau du système d’exploitation il faut bien les faire tourner sur quelque chose !» Stéphane Berthaud, CTO de Veeam France, va dans le même sens : « Est-ce la prochaine vague ? Pour l’instant c’est complémentaire et il n’y aura pas de remplacement total. Tout ce qui pourra être containerisé le sera. C’est une évolution, c’est de la virtualisation optimisée. Avec la virtualisation du système d’exploitation cela devient de la virtualisation au régime minceur en supprimant tout ce qui ne sert à rien mais cela implique des changements d’architecture et de manière de concevoir les applications.»

Cela amène plusieurs avantages. Le premier est d’être beaucoup plus efficace que les hyperviseurs et d’optimiser les ressources utilisées. Deuxième force du container, la portabilité. Le conteneur créé est cohérent et ne souffrira pas d’être exécuté sur un autre environnement. Troisièmement, la conteneurisation permet aux développeurs de créer et de déployer des applications plus rapidement et de manière plus sécurisée. Avec les méthodes traditionnelles, le code est développé dans un environnement informatique spécifique. Lorsqu’il est transféré vers un nouvel emplacement, cet environnement entraîne souvent des bogues et des erreurs. La conteneurisation élimine ce problème en regroupant le code de l’application avec les fichiers de configuration, les bibliothèques et les dépendances associés nécessaires à son exécution. En conséquence, le déploiement des mises à jour et des correctifs ne devra être effectué qu’une seule fois puisque le noyau du système d’exploitation est désormais commun.

Pour les applications cloud natives

« La priorité a changé et l’application dicte tout et les métiers imposent leur rythme et leurs besoins », constate Stéphane Berthaud. Pour y répondre les entreprises se tournent vers les micro-services. Plutôt qu’une application monolithique comme nous la connaissions jusqu’à présent, elle se décompose en différents services ou fonctions. Ils structurent ainsi l’application entre différents modules faiblement couplés, un héritage des temps héroïques de la Service Oriented Architecture (SOA) du début des années 80 du siècle dernier. Ces services communiquent entre eux par une API, REST (Representational State Transfer) le plus souvent. Avec un tel niveau de modularité, les services individuels peuvent être développés plus rapidement et ils sont beaucoup plus faciles à comprendre et à maintenir. Cela s’accompagne de nouvelles méthodes de travail à la fois pour les développeurs et les équipes de production. Selon Stéphane Berthaud, pour les développeurs c’est « un peu magique et ce qui va être compliqué va être le dimensionnement et la gestion de l’infrastructure derrière, surtout si on veut le faire sur site. Dans le Cloud les capacités sont quasiment infinies ».

Stateless vs stateful

Au moment de leur émergence, les containers étaient stateless. Dans ce cas un processus ou une application est indépendant. Il ne stocke pas de données et ne fait référence à aucune transaction passée. Chaque transaction est effectuée à partir de rien, comme si c’était la première fois. Au fil du temps, certains ont pensé intéressant de les rendre stateful. Les applications et processus stateful, quant à eux, peuvent être réutilisés indéfiniment.

Les plates-formes bancaires en ligne et les messageries en sont deux exemples. Les transactions précédentes sont prises en compte et peuvent affecter la transaction actuelle. C’est pour cela que les applications stateful utilisent les mêmes serveurs chaque fois qu’elles traitent une requête d’un utilisateur. Les applications ont ainsi profité de la flexibilité et de la rapidité des conteneurs, sans cesser de stocker des informations et du contexte. Selon le sondage précité réalisé auprès des utilisateurs de Datadog, 55% des personnes interrogées indiquent utiliser des applications stateful dans des containers en production ; 12% évaluent cette possibilité et 11% indiquent vouloir le faire dans les douze prochains mois. Gaëtan Parisse, architecte cloud et DevSecOps chez Fabernovel, parle de ce qu’il constate chez ses clients : « Cela débute souvent par un test qui continue à vivre dans son coin et qui devient parfois critique, sans que cela fonctionne comme vraiment en production mais la demande est là. On a même vu des essais avec des bases Oracle ou Postgres. On se retrouve alors avec des plates-formes à la criticité forte où les données sont hypersensibles. Cela est souvent géré avec un peu tout et n’importe quoi et soit on perd en agilité soit on rencontre des problèmes de performance. Par ailleurs on a vu la containerisation de tout et n’importe quoi comme application où le container remplaçait la machine virtuelle. Il faut reconnaître les limites dans certains cas et chercher où sont les contraintes. En production cela reste dangereux.» Pour Christophe Auffret, chez Nutanix, d’un monde où tout était éphémère, on est passé « à un monde de la gestion applicative nécessitant de la persistance. Les éditeurs de containers ont essayé de s’adapter à ce concept comme avec Docker Persistent Volume, puis cela a créé la nécessité de stocker et de sauvegarder les données le plus souvent à l’extérieur des containers et le besoin d’orchestrer tout cela. Il a fallu créer des outils et divers instruments pour le monitoring entre autres questions ».

Tout cela ne manque pas de créer des problèmes complexes autour principalement du dimensionnement de la solution, de l’architecture. Pour Christophe Jauffret, il y a beaucoup de travail à faire « avec le choix de la bonne distribution. Il faut repenser l’infrastructure et toute la partie business pour obtenir la continuité, la haute disponibilité, la reprise après incident, la sauvegarde. On assiste à une course sur le marché pour les éditeurs spécialisés dans la sauvegarde pour les containers. Les spécificités de chaque plateforme fait que les choix pour les outils de sécurité et de monitoring sont différents. Tout cela demande une approche différente.» Gaëtan Parisse, chez Fabernovel, a constaté, lui, chez certains clients des applications littéralement tronçonnées sans gagner en efficacité avec des services effectuant les mêmes choses. Ces entreprises se retrouvent avec les mêmes problèmes que dans les débuts des machines virtuelles avec un contexte complètement éclaté.

Le roi Kubernetes

En quelques années l’orchestrateur né dans le giron de Google est devenue le standard de fait pour l’orchestration des environnements en containers. Pourtant l’outil ne partait pas favori face à ses concurrents, comme Mesos ou Swarm. S’il était réputé puissant, il était connu pour sa complexité et une courbe d’apprentissage plutôt longue. Il a cependant fini par s’imposer. Christophe Jauffret explique : « Kubernetes est un orchestrateur qui gère les entrées/sorties vers le matériel. Il est devenu une plaque tournante et connaît un effet de mode pour être le standard de fait. D’ailleurs l’aspect complexe ne s’améliore pas avec la dernière version et l’outil s’installe aussi faute de réelle compétition. Les principales alternatives s’appuient sur Kubernetes. Ce sont Rancher, Swarm, les balbutiements de Hashicorp Nomad. Les versions plus légères, comme K3S de Rancher ou MicroK8s de Canonical, sont intéressantes car elles enlèvent toutes les fonctions un peu lourdes en étant donc plus légères mais en respectant un grand nombre d’API.»

Plusieurs autres personnes interrogées pour cet article mettent en avant le rôle primordial de Google dans cette montée en puissance avec maintenant une communauté large et très active avec un écosystème très vaste.

Alexandre Legris, directeur des services managés dans le Cloud et hébergement chez BSO, explique encore plus simplement cette hégémonie actuelle : « Sous le nom de Borg, l’outil était utilisé depuis des années en interne chez Google, quand il est passé dans le domaine public, il avait simplement dix ans d’avance sur ses concurrents.»

De nombreuses distributions

Kubernetes connaît maintenant de nombreuses distributions. La plupart se construisent autour du noyau open source de la solution complété par des add-ons avec pour objectif de simplifier et de faciliter les déploiements des clusters Kubernetes. Vincent Barbelin, CTO chez Dell France, renchérit : « Avec Pïvotal, nous avons commencé à industrialiser la partie sur le déploiement. Aujourd’hui nous poussons cette industrialisation à l’extrême jusqu’au centre de données. Avec le projet Pacific nous proposons la gestion de cette industrialisation sur l’ensemble de la pile et les outils de télémétrie.» Cette multitude rend parfois difficile le choix d’une distribution pour réellement trouver celle qui correspond le mieux aux besoins.

Sécurité = visibilité

La sécurité est un point central des interrogations autour des environnements en containers. Vincent Barbelin situe le problème à plusieurs niveaux : « Le premier est dans le cycle de développement avec le DevSecOps : 90% des failles sont présentes dès la création du code. Il faut tester aussi les mécanismes du container et l’architecture. Un exemple intéressant mais pas pour tous est celui de Netflix avec sa stratégie Crazy Monkey qui simule tout type de pannes en pleine production. Il convient de vérifier que l’on n’ouvre pas de nouvelles failles avec les nouvelles versions du code qui peuvent être fréquentes. Il convient d’ajouter en Est-Ouest de la micro-segmentation et du micro-firewalling.» Christophe Jauffret relève qu’il est nécessaire de vérifier d’où viennent les images des containers et comment elles sont maintenues. « Plus largement comme à une époque de la virtualisation, on manque de visibilité et avoir beaucoup d’applications sur un seul OS entraîne cette perte de visibilité. Il faut donc être rigoureux afin de regagner en visibilité sur ces environnements complexes par le contrôle des logs, du monitoring, du filtrage de flux, de la détection d’intrusion avec de la granularité pour les firewalls pour savoir quel container parle à tel container et appliquer de la micro-segmentation.» La question et les bonnes pratiques sont tellement larges qu’il faudrait y consacrer un article en soi. Gaëtan Parisse regrette quant à lui que la problématique vient souvent bien après le lancement des projets autour des containers et du développement d’applications qui seront containerisées.

Serverless, la prochaine étape

Selon le rapport de la CNCF que nous avons déjà cité, 30% des entreprises utilisent déjà la technologie serverless en production. Le serverless fait référence aux applications dont l’allocation et la gestion des ressources sont entièrement gérées par le fournisseur de services cloud : 21 % l’évaluent et 12% veulent se lancer dans l’année; 60% des utilisateurs le font sur une plate-forme hébergée; 13% utilisent des logiciels d’installation; 22% se servent des deux. La plate-forme dominante est AWS Lambda (57%) devant Google Cloud Functions (27%) et Azure Functions (24%). Pour les solutions installables, Knative prend la première place, largement devant OpenFaaS et KubeLess.

Sébastien Stormacq prêche pour sa chapelle. Il est évangéliste chez AWS (Principal Developer Advocate) et voit le serverless comme une évolution vers une abstraction complète où l’on ne voit plus l’infrastructure sousjacente. Avec la possibilité de gérer un continuum dans les environnements containers à travers des environnements hybrides ou de Cloud public tout en ayant un même niveau de contrôle et les mêmes API. Avec cela les entreprises se délestent de la complexité des environnements containers dont la plupart n’ont pas le besoin. D’autres interviewés de l’enquête distinguent aussi cette tendance et voient le serverless comme l’étape suivante de l’évolution des environnements en containers.

Sébastien Stormacq observe que les utilisateurs les plus avancés déploient des applications en «service mesh», même s’il faut être pragmatique dans ce choix. Le rapport de la CNCF prévoit une accélération de l’adoption de cette technologie qui profitera probablement le plus aux outils Istio et Linkerd, qui suscitent l’intérêt le plus marqué au stade de l’évaluation. Contrairement à d’autres systèmes de gestion des communications, un service mesh est une couche d’infrastructure dédiée, créée dans l’application. Cette couche visible peut indiquer la manière dont les différents éléments d’une application interagissent entre eux. Il devient dès lors plus facile d’optimiser les communications et d’éviter les temps d’arrêt lorsque l’application évolue. Selon la CNCF, 18% des entreprises utilisatrices d’environnements en container se sont converties au service mesh, soit plus de 50% en un an et une hausse en production de 27%; 47% évaluent la technologie. Ce qui conduit à anticiper une large progression potentielle. Au bilan, les entreprises utilisatrices des environnements en containers en production mettent en avant les possibilités d’évolution horizontales améliorées et la réduction des temps de déploiement des applications et des environnements. La maturité viendra plus tard !

Une technologie qui émerge sur le tard

S’ils sont aujourd’hui à la mode, les containers existent en fait depuis la fin des années 70… du siècle dernier. Ils sont apparus précisément en 1979 avec la version 7 d’Unix et le système «chroot» qui permet de changer le répertoire racine d’un processus de la machine hôte. Le point est rapidement adopté et devient intégré à BSD en 1982. Ils connaissent ensuite une longue période de dormance pour se réveiller au début de ce siècle avec l’introduction des partitions «jails» dans Free BSD. Cet outil est ensuite amélioré tout d’abord avec Linux vServer qui permettait le partitionnement des ressources puis avec OpenVZ en 2005. L’année précédente, les jails ont été combinés avec des séparations de flux dans les containers de Solaris de Sun Microsystems. En 2006 s’y sont ajoutés les groupes de contrôles qui autorisent la prise en charge et l’isolation de l’usage des ressources comme le processeur et la mémoire.

 Les containers prennent en grande partie leur forme actuelle en 2008 avec les LXC, première mouture stable et complète de containers pouvant fonctionner sur le kernel Linux sans patch. Sur ces containers se sont développés en 2011 les containers de Warden, puis en 2013, ceux de Docker. L’apparition de Docker a changé la destinée des containers en apportant un nouveau souffle à cette technologie. Docker se fonde sur deux piliers : les containers LXC et les «libcontainers». Les libcontainers sont une évolution du système lmctfy (Let me contain that for you), une version open source des containers de Google, où les applications créent et gèrent directement les sous-containers. Docker y ajoutait une interface utilisateur agréable et plus facile d’accès. Docker a connu alors un développement record avec 100 millions de téléchargement en une année. À côté de Docker, d’autres technologies sont apparues pour améliorer les containers comme rkt qui essayait de résoudre des problèmes de la technologie Docker avec l’implémentation d’une sécurité plus rigoureuse et des prérequis de production. La création de la CNCF (Cloud Native Computing Foundation) a donné un cadre encore plus large pour le développement de la technologie avec son rassemblement de développeurs, d’industriels et d’entreprises.

En 2016, Microsoft se rallie, lui aussi, aux containers Linux et autorise les containers sur Windows qui aboutira aux Process et Hyper-v Container. Il est à noter que Microsoft, dès lors, a gagné en influence dans l’écosystème des containers.

Depuis, la technologie des containers a connu différents ajouts importants comme Kubernetes, issu du projet Borg de chez Google, Flannel, une couche de virtualisation des réseaux dans les environnements containers d’OpenShift de RedHat, ou Calico.

La technologie évolue encore très rapidement avec des changements notables comme l’apparition de nouveaux runtimes à la place de celui de Docker comme containerd ou CRI-O ou ouvrant la voie vers le serverless avec la plate-forme de Knative ou celle de Fauna (base de données NoSQL serverless). On se dirige aussi vers une nouvelle couche d’abstraction pour distribuer la gestion des tâches sur différents nœuds du cluster pouvant être distribués sur plusieurs infrastructures. Loft Labs propose maintenant une technologie de virtualisation des clusters Kubernetes, les vClusters qui permettent de partager les ressources à partir d’un seul cluster Kubernetes et de consolider ainsi les tâches.

Hardis, ça CaaS mais ça passe !

Hardis, éditeur de solutions pour la logistique mais aussi prestataire de services pour la transformation numérique des entreprises, a renouvelé son offre en passant au CaaS (Container as a service). Grégory Grimonprez explique : « Nous ne proposons plus une infrastructure ou des machines virtuelles mais une plate-forme qui fournit des applications containerisées sur une plate-forme d’hébergement sans avoir à passer par notre service. » Il ajoute : « c’est pour nous une façon différente de livrer nos services mais pas vraiment une révolution. » Pour l’instant Hardis travaille à rendre sa solution disponible pour les environnements en cloud hybride et sur les opérations d’orchestration. La solution fonctionne sur la base de la distribution Karbon de Nutanix.

BSO accompagne les entreprises dans leurs déploiements

Kubernetes Alexandre Legris, directeur de l’offre de services managés en Cloud et hébergement chez BSO, le voit bien avec les retours de ses prospects et clients. Beaucoup achètent la promesse de Kubernetes mais ne sont pas vraiment conscients de la complexité et de la difficulté de l’opération. BSO a donc mis au point un framework, une méthodologie pour accompagner les clients dans cette période délicate. La démarche démarre par un audit pour se rendre compte du niveau technique et de l’appréhension par rapport au niveau de maturité sur les déploiements. BSO accompagne ses clients ensuite dans leur transformation des applications avec une orientation des choix pour augmenter «la citoyenneté des applications» pour les environnements en containers. «Nous les orientons vers des choix que l’on sait fonctionnels», précise le directeur de BSO.