Le principe de la conteneurisation peut se résumer par la division du code d’un logiciel en petites unités et le regroupement de tous ses composants (les bibliothèques, frameworks et autres dépendances) dans des conteneurs.
Le principe de la conteneurisation peut se résumer par la division du code d’un logiciel en petites unités et le regroupement de tous ses composants (les bibliothèques, frameworks et autres dépendances) dans des conteneurs. Comme ces derniers ont la capacité de partager le noyau du système d’exploitation du système hôte, ils peuvent s’affranchir d’un système d’exploitation propre et sont logiquement légers. Ainsi, les applications peuvent s’exécuter de la même manière sur tous les types d’infrastructures, et être déplacées de façon cohérente dans tous les environnements. Benjamin Messiaen, en poste chez Inside, nous explique ce principe de conteneurisation, utilisé pour isoler des fonctions uniques qui effectuent des tâches spécifiques : les microservices.
Pouvez-vous nous donner votre définition de la conteneurisation ?
A mon sens le principe de conteneurisation repose sur le fait de segmenter une application en la divisant en plus petites parties, c’est-à-dire en microservices, chacun étant placé dans un conteneur. Il faut savoir que cette notion de microservices n’est pas nouvelle. Elle est arrivée avec le middleware et la prise de conscience que trop de communication tue la communication (cette technologie agit comme passerelle de communication entre les applications). Il fallait éviter autant que possible de coder des fonctionnalités trop lourdes : la notion de microservice est donc l’allégement des communications et des fonctionnalités du middleware. Ces microservices sont placés dans des conteneurs qui peuvent utiliser le noyau du système d’exploitation de la plateforme hôte. Ils permettent souvent de s’affranchir des machines virtuelles (VM), le socle est ainsi fortement allégé. De plus, les conteneurs sont plus faciles à administrer.
Si la notion de microservices n’est pas nouvelle, le principe de conteneur l’est-il ?
Non, le conteneur repose sur un principe de virtualisation qui existe lui aussi depuis longtemps. A l’origine la virtualisation a rendu possible le fait de multiplier le nombre de VM autant de fois que l’hébergeur le permet. Ce qui pouvait poser des problèmes du point de vue du maintien en condition opérationnelle (MCO), quand il y a trop de VM à gérer. Il fallait donc corriger cette dérive et pouvoir alléger le socle, soit en faisant de la « templatisation » par exemple, soit en créant des VM qui n’existent que le temps de la fonction. Mais une autre solution consiste tout simplement à se passer le plus possible de VM (qui sont assez lourdes, avec un kernel), en ayant recours à des conteneurs plus légers. Car si ces derniers ne peuvent pas émuler, ils peuvent virtualiser.
Peut-on dire que la conteneurisation répond à une approche DevOps ?
La conteneurisation répond à la fois aux besoins des Devs et des Ops, avec l’allégement des fonctionnalités par la segmentation d’un côté, et avec l’allégement du socle de l’autre. Il s’agit en effet d’une véritable approche DevOps, car ce n’est pas à l’administrateur de construire le conteneur, mais au développeur. L’administrateur se contente de l’hébergement. Pour autant, avec l’arrivée des nouvelles architectures Cloud, la conteneurisation est devenue plus un besoin de développeur qu’un besoin d’administrateur système. C’est pour cette raison qu’on trouve aujourd’hui plus d’architecture VM, comme VMWare, hébergeant des conteneurs que des purs socles de conteneurs comme Kubernetes par exemple.
Pouvez-vous nous donner les avantages apportés par l’usage des conteneurs ?
La conteneurisation apporte moins de MCO, puisqu’il n’y a quasiment plus de templatisation. Les mises à jour sont également facilitées puisqu’elles ne concernent que certains microservices et pas toute l’application, contrairement à une approche monolithique. En tout cas si l’application a été bien conçue. La conteneurisation facilite également le déploiement qui devient « quasi sûr », parce qu’avec le principe du conteneur il n’y a pas besoin d’aller chercher les bonnes versions du logiciel et les bonnes versions des dépendances du logiciel. Ce qui amène de la stabilité car il est plus facile de retrouver les bonnes versions.
Pouvez-vous développer cette notion de stabilité ?
Il faut bien comprendre qu’un conteneur est stateless, c’est-à-dire sans état. Par exemple pour une base de données, le côté « donnée » et le côté moteur sont bien séparés. En « démarrant le moteur » du conteneur, celui-ci va retrouver les données. Si ce moteur est éteint puis redémarré, il refera exactement les mêmes opérations. Mais à la différence des anciens systèmes, l’altération du moteur n’est pas possible avec un conteneur. Si le moteur est allumé puis altéré à cause de diverses manipulations, il retrouvera son état d’origine après extinction et rallumage. Ce qui est très important pour certaines applications. Par exemple des cas non prévus par le développeur peuvent apparaître avec l’utilisation d’une IA, qui peut engendrer une erreur inconnue. Si l’application est alors bloquée, elle peut redémarrer automatiquement le conteneur et revenir à son état d’origine, sans altération. De fait si une application conteneurisée arrive à passer une fonction, une fois éteint et rallumé le conteneur arrivera toujours à refaire cette fonction.
Peut-on conteneuriser toutes les applications ?
Quand une application n’a pas été réellement pensée en mode microservices et spécifiquement prévue pour un conteneur, il vaut mieux recourir à une VM. Aujourd’hui nous observons une « mode » de conteneurisation à outrance, avec des conteneurs qui peuvent peser jusqu’à 15 Go et qui sont finalement devenus aussi lourds que des VM. Alors que c’est justement ce qu’il fallait éviter. Nous avons également observé des usages de conteneurs inappropriés. Par exemple, un éditeur veut mettre en place 3 logiciels de façon générique. C’est-à-dire qu’un seul conteneur va démarrer les 3 logiciels, donc initier toute une chaîne. On perd alors le côté stateless, car le démarrage de chaque logiciel a une dépendance avec les autres. La VM est plus adaptée dans ce cas précis.
La conteneurisation répond à la fois aux besoins des Devs et des Ops, avec l’allégement des fonctionnalités par la segmentation d’un côté, et par l’allégement du socle de l’autre.
Vous souhaitez échanger avec nos experts autour de vos enjeux et de la conteneurisation, c’est par ici !
