Définition d'un conteneur

Objectif d'un conteneur

Faire tourner une application et ses dépendances dans un environnement totalement isolé et transposable d’un système à autre en garantissant son bon fonctionnement ». Le conteneur apparait comma « LA » solution à tous les maux de l’informatique, à commencer par

• Le développeur : "Je ne comprends pas ça tourne sur mon poste."
• Le gars en charge de la mise en prod : "ben ouais, mais là ça ne fonctionne pas sur le serveur de prod, on va demander aux mecs de l’infra"
• Le geek de l’infra : "je n’ai rien touché moi !"
• Les managers : "On va faire une réunion de crise"
• L'utilisateur : "Oh Oh, je peux plus travailler moi !"

Le conteneur c’est le palliatif au manque de bon sens des services IT : avoir le même écosystème du développement de l’application à sa mise en prod. Dans les faits ça existe depuis très longtemps, ça s’appelle « jails » chez FreeBSD (mars 2000), les « zones » chez Solaris (février 2004) « LXC » chez Linux (aout 2008)…mais on en parle comme une révolution : le fautif « Docker » sorti en 2013. Toutes les méthodes de conteneurisation précédentes étaient (et le sont toujours) efficaces, mais complexes. « Docker » c’est « l’App Store » du conteneur…la démocratisation d’une technologie pour le rendre utilisable par la plus large population possible….Au risque d’en faire n’importe quoi…

Cas de Docker

Historique de Docker

Docker a débuté par la mise en œuvre d’une API permettant de piloter la couche LXC propre au noyau Linux. (C’est d’ailleurs pour ça que Windows n’a pas rejoint la bataille tout de suite…mais il n’a pas dit son dernier mot). Le produit a évolué pour disposer de son propre moteur de conteneur (mais toujours dépendant du kernel Linux) et surtout son « docker hub ». Une plateforme où s’échange des milliers de conteneurs proposés par la communauté permettant le déploiement en quelques minutes d’un CMS, d’une base de données, d’une application de compatibilité…aujourd’hui votre entreprise peut avoir son propre « hub » ou « registery » de conteneurs. Vos développeurs travaillent main dans la main avec vos administrateurs applicatifs et systèmes pour concevoir un conteneur disposant de tout le nécessaire à la bonne exécution de votre application en y incluant la bonne couche de sécurité, les bonnes pratiques de configuration…et on peut ainsi automatiser en toute sérénité le déploiement de vos conteneurs via un orchestrateur (qui a dit Kubernetes…). Ça c’est la vision idéale…souvent chacun y’a va de son conteneur fabriqué à partir d’une image téléchargée sur internet dont il n’a aucune idée de sa construction interne…du coup-là ou l'on avait 30 VMs  déployées (dont on ne sait plus a quoi servent la moitié) ben on toujours 30 VMs, mais qui hébergent chacune des centaines de conteneurs (dont certains étrangement minent du bitcoin en cachette) et….c’est le bordel !

Conclusion sur la conteneurisation

La conteneurisation est un formidable outil, mais encore une fois, pour être efficace un outil demande d’être maitrisé et utilisé correctement. Docker a pu être décrié par des experts de la sécurité remontant des défauts majeurs à ce niveau, mais la plupart du temps ces défauts peuvent être corrigés via une bonne connaissance des bonnes pratiques et surtout un échange bien plus fort entre celui qui fait l’application, celui qui la déploie et celui qui gère l’infrastructure (et je ne parle pas de la réunion hebdomadaire des chefs des équipes respectives…).

Certains appellent ça du DevOps et charment les DSI (et surtout le DAF) en leur indiquant que tout ce petit monde se résumera à une seule personne…d’autres encouragent juste à l’explosion des silos et la mise en œuvre d’équipes pluridisciplinaires ou le conteneur et l’application associée deviennent la raison d’être de la team.

Dernière précision : il n’y a pas que Docker sur le marché….