« Oui, mais ça marche sur ma machine ! »

Si vous travaillez de près ou de loin avec des développeurs, vous avez sûrement déjà entendu cette phrase. Un logiciel fonctionne parfaitement sur l’ordinateur de celui qui l’a créé, puis se comporte différemment, voire ne fonctionne pas, une fois installé chez le client. Une application livrée en production ne réagit pas comme sur la machine du développeur. En cause, une simple différence dans l’environnement.

C’est exactement à ce problème que répond la conteneurisation. La technologie n’a pourtant rien de nouveau : elle est éprouvée, largement adoptée et fait aujourd’hui partie du quotidien de nombreuses équipes techniques. Alors pourquoi y consacrer un article ? Parce que, dans les faits, nous constatons qu’il reste souvent nécessaire d’en présenter les notions fondamentales, de façon vulgarisée, à nos collaborateurs comme à nos clients. Derrière un terme désormais banal se cachent des concepts qui ne sont pas toujours partagés par tous, et bien les comprendre change la manière d’aborder un projet.

L’idée est simple : au lieu de livrer seulement l’application, on l’emballe avec tout ce dont elle a besoin pour fonctionner, ses dépendances, ses bibliothèques, sa configuration, dans une sorte de boîte autonome. Cette boîte, c’est le conteneur.

Comme on n’expédie plus seulement le logiciel mais l’ensemble de son environnement, il n’y a plus de mauvaise surprise à la livraison. La boîte se comporte de la même façon partout.

La conteneurisation repose sur quatre piliers :

• Portabilité : le conteneur tourne sur n’importe quelle machine dotée d’un environnement Linux.
• Reproductibilité : une même application peut être déployée à l’identique sur différents environnements.
• Isolation : chaque application a sa propre boîte, sans impacter les autres.
• Agilité : on peut faire évoluer un service sans toucher au reste.

C’est la comparaison qui vient naturellement, mais il y a une différence de taille. Avec une VM, on recrée un ordinateur complet, avec son propre système d’exploitation, par-dessus la machine hôte. C’est puissant, mais lourd, car chaque VM embarque tout un système à faire tourner.

Le conteneur est bien plus léger. Il partage le système d’exploitation de la machine hôte et se contente d’utiliser directement ses composants natifs pour lancer des services isolés.
Résultat ? Beaucoup moins de ressources consommées, car on ne réémule pas tout un environnement à chaque fois.

Dans ce domaine, un outil s’est largement imposé : Docker. C’est un logiciel open source créé en 2013, ayant pour but de rendre accessible cette technologie, devenu la référence de la conteneurisation. Pour l’utiliser, il faut un environnement Linux. Sous Windows, on passe traditionnellement par WSL, une couche Linux installée sur le système de Microsoft.
Des alternatives à Docker existent aussi, comme Podman par exemple.

Le meilleur moyen de comprendre l’intérêt de Docker, c’est de comparer deux façons d’installer un même service. Prenons PostgreSQL, une base de données très répandue.

La méthode classique

• On lit la documentation officielle, puis on enchaîne les étapes : configuration, installation d’une première dépendance, nouvelle configuration, deuxième dépendance, et ainsi de suite jusqu’à pouvoir enfin lancer le service. C’est long, fastidieux, difficile à maintenir et à documenter.

 

• On dépend de la machine sur laquelle on travaille, car chaque serveur a ses particularités qu’il faut prendre en compte.

• L’éditeur du logiciel fournit lui-même un conteneur prêt à l’emploi : un environnement déjà emballé et configuré, appelé image.

 

• Il suffit de récupérer cette image et de la lancer.

 

• Aucune configuration de service à faire soi-même.

 

• Tout le travail complexe a déjà été réalisé par l’éditeur.

Aucune des deux approches n’est meilleure dans l’absolu ; tout dépend du contexte.

L’installation classique garde des atouts : les données et la configuration persistent naturellement, la consommation mémoire est moindre puisqu’on travaille directement sur la machine, et on maîtrise l’installation de bout en bout. En revanche, la configuration est lourde, on dépend de l’environnement, la maintenance est complexe et les risques de conflit avec d’autres services sur le même serveur sont réels.

Le conteneur, lui, se configure très facilement en mode déclaratif : on ne bricole pas le produit, on décrit simplement comment on veut qu’il fonctionne. C’est donc très facile à reproduire, on peut faire coexister plusieurs versions sans conflit, et le conteneur n’affecte pas le système puisqu’il est isolé dans sa propre boîte. On dépend donc de l’éditeur qui maintient l’image, la conteneurisation demande des compétences à acquérir, et le conteneur reste un peu une « boîte noire », on le lance, ça marche, mais on maîtrise moins ce qui se passe à l’intérieur.

Et les données, dans tout ça ?

Une question revient souvent : si je conteneurise une base PostgreSQL, mes données sont-elles enfermées dans le conteneur ?

Non. Il n’y a aucune donnée dans un conteneur, et c’est voulu : un conteneur est jetable, il peut être détruit à tout moment. Les données, elles, sont stockées à l’extérieur, dans ce qu’on appelle un volume. Le conteneur se contente d’y accéder.

L’avantage est considérable. Si demain je veux agir sur PostgreSQL, je jette simplement l’ancien conteneur et j’en branche un nouveau sur le volume existant. Les données, elles, ne bougent pas.

Kubernetes, le chef d’orchestre

Une fois qu’on sait fabriquer des conteneurs, comment les gérer à grande échelle ? C’est là qu’intervient Kubernetes, souvent abrégé « K8S ».

Kubernetes est un orchestrateur de conteneurs open source, développé à l’origine par Google. Si vous connaissez les orchestrateurs de tâches, c’est le même principe, mais appliqué aux conteneurs.

Là où Docker fabrique et exécute les conteneurs, Kubernetes les coordonne, organise et planifie. Kubernetes pilote le bateau qui contient de nombreux conteneurs Docker. C’est pourquoi les deux technologies sont complémentaires, Docker est plutôt l’outil des développeurs, Kubernetes celui des administrateurs système.

Pourquoi un tel succès ?

• Mise à l’échelle et performance. Kubernetes ajuste automatiquement le nombre de conteneurs selon la charge. Pensez à un site de billetterie le jour de l’ouverture des ventes d’un concert très attendu : quand un conteneur commence à saturer, Kubernetes en lance d’autres pour absorber l’affluence. Résultat, pas de plantage lors des pics de trafic.
• Sécurité et isolation. Chaque application sensible est isolée, comme les appartements d’un immeuble : chacun sa porte, chacun sa clé. Une faille dans une application ne compromet pas les autres.
• Résilience et haute disponibilité. Un conteneur tombe en panne ? Kubernetes le remplace automatiquement, sans que l’utilisateur ne s’en aperçoive. Comme une équipe de nuit à l’hôpital, il y a toujours quelqu’un pour prendre le relais.
• Portabilité et multi-cloud. La même application se déploie sur AWS, Azure, Google Cloud ou sur ses propres serveurs, sans modification majeure. Comme un appareil électrique avec un adaptateur universel : on change juste la prise selon le pays, l’appareil reste le même. On évite ainsi de dépendre d’un seul fournisseur.
• Industrialisation et standardisation. Comme le plat d’une chaîne de restauration, identique partout dans le monde, l’application se comporte de la même manière quel que soit l’endroit. Fini les livraisons hasardeuses.
• Optimisation des coûts. Les ressources s’ajustent dynamiquement, comme un éclairage à détecteur de présence : la lumière s’allume au besoin. On ne paie que ce que l’on consomme.
• Observabilité et surveillance. Kubernetes permet d’inspecter en temps réel ce qui se passe sur les conteneurs, comme le tableau de bord d’une voiture renseigne sur la santé du moteur. On devient proactif, on repère un problème avant que les utilisateurs ne le signalent.

Une vraie décision stratégique

Kubernetes est la solution préférée de beaucoup, mais elle est aussi très complexe. On ne la met pas en place sans en avoir la maîtrise. En général, une entreprise qui bascule sur Kubernetes le fait au prix d’un refactoring complet de son système informatique. C’est lourd, coûteux et cela demande des compétences spécialisées. Bref, ce n’est jamais une décision prise à la légère : soit on démarre un projet de zéro sur cette base, soit on mûrit longuement la transition.

Le marché de l’orchestration

Kubernetes domine largement et les entreprises concernées ne jurent que par lui. Mais il n’est pas seul. Docker propose son propre orchestrateur, Docker Swarm, et Red Hat édite OpenShift, que l’on peut voir comme un « Kubernetes simplifié ».

Les grands fournisseurs américains, conscients que Kubernetes n’est pas une mince affaire, proposent aussi des versions clés en main : EKS chez Amazon, AKS chez Azure, GKE chez Google. Vous payez, et vous n’avez plus à gérer la configuration ni la maintenance de Kubernetes. Cela coûte beaucoup plus cher, mais vous vous contentez de profiter du service.

Un cas concret, conteneuriser un job Talend

Pour tester ce que la conteneurisation permet vraiment, nous avons mené une petite expérimentation avec Talend, un outil d’intégration de données, à partir d’un job très basique qui génère des noms et prénoms aléatoires.

Première surprise, les fonctionnalités de conteneurisation annoncées par l’éditeur ne se sont pas révélées disponibles et/ou fonctionnelles dans les versions testées, y compris payantes. Sur le papier, c’est prévu, dans la réalité, ce n’est pas si simple. Du côté de la communauté Open-Source Talaxie, rien dans les cartons de prévu non plus pour le moment.

Qu’à cela ne tienne, nous avons conteneurisé le job via un outil sur-mesure développé en interne, sans passer par la fonctionnalité de l’éditeur. Et ça marche, le job est emballé dans un conteneur que l’on peut redéployer à la volée.

Cette expérimentation démontre surtout que nous sommes capables de conteneuriser un existant, y compris lorsque l’éditeur ne le prévoit pas. Et c’est là que l’enjeu devient stratégique. Pour un client qui souhaite se détacher progressivement de Talend, cette approche ouvre une voie intéressante, le développement doit certes encore être maintenu via TOS ou Talaxie, mais la conteneurisation permet déjà de s’affranchir de l’architecture Talend (console d’administration, serveur de jobs, etc …) tout en gardant l’existant pleinement opérationnel.
Autrement dit, on amorce la sortie sans casser ce qui fonctionne, une transition en douceur plutôt qu’une bascule brutale.

Pour bien saisir l’intérêt, comparons les deux chaînes de déploiement. Dans un job Talend classique, on développe, on construit les artefacts que l’on envoie sur un dépôt (souvent Sonatype Nexus), on orchestre le tout via une console d’administration (TAC), puis on lance une machine virtuelle Java (JVM) pour exécuter le job.

Avec un job conteneurisé, on développe comme d’habitude, on conteneurise, puis on centralise l’image sur un registre, un serveur dédié au stockage d’images de conteneurs (Docker Hub ou une solution équivalente Azure Container Registry, un registre privé, etc …).

Il ne reste plus qu’à récupérer l’image et à l’exécuter à la volée. Et si l’on veut aller plus loin, on peut envoyer cette image sur un cluster Kubernetes, mais là, on entre dans l’industrialisation à grande échelle.

Un conteneur, c’est une boîte contenant une application et toutes ses dépendances : portable, isolée, jetable et reproductible à l’infini.
Docker est l’outil qui permet de fabriquer et de lancer ces boîtes tandis que Kubernetes est le chef d’orchestre qui les gère à grande échelle.

Aucune de ces approches ne remplace magiquement les méthodes classiques, tout est affaire de contexte et de besoin.
Mais elles apportent une réponse élégante à ce vieux casse-tête du « ça marche sur ma machine », en livrant, justement, bien plus que la machine.