Nos logiciels s’appuient sur une plateforme 100 % propriétaire et made in France dont le déploiement et fonctionnement reposent eux-mêmes sur Docker, un produit qui fait beaucoup de bruit depuis quelques années. Voici quelques éclairages pour comprendre comment Docker s’est imposé comme un incontournable.
Arrivé dans le monde de l’open-source en 2013, Docker est une solution de conteneurisation logicielle. Si ce terme vous semble obscure, comprenez simplement que pour fonctionner, la grande majorité des logiciels s’appuient sur des dépendances externes. Ces dépendances peuvent être des bibliothèques logicielles ou encore d’autres logiciels (par exemple un serveur de base de données), qui ont eux-mêmes leurs propres dépendances. Pas toujours facile de s’y retrouver, même pour les plus avertis.
Rajoutez à cela le fait que toutes ces dépendances sont mises à jour régulièrement, parfois avec des changements majeurs non rétro-compatibles, qui nécessitent une grande vigilance et des correctifs réguliers de la part des développeurs. Comprenez également que l’installation de plusieurs versions d’un même logiciel nécessite parfois d’installer plusieurs versions de ces mêmes dépendances, ni toujours disponibles (ou maintenues) sur le gestionnaire de paquets du système hôte, ni toujours pensées pour fonctionner en parallèle sur un système unique. La tâche peut vite se transformer en cauchemar pour les équipes en charge de l’infrastructure et de sa sécurité.
Pour s’affranchir de ces problèmes, la solution communément admise depuis le début des années 2000 est la virtualisation : un serveur physique hôte (appelé « hyperviseur »), puissant, se charge de « virtualiser » (en quelque sorte de simuler) un ou plusieurs serveurs, en distribuant un sous-ensemble de ses ressources (processeur, mémoire, stockage). Ces serveurs virtuels agissent exactement comme des serveurs physiques, avec leurs propres systèmes d’exploitation et leurs propres logiciels installés.
Mais cette approche n’est pas excepte de défauts. Par exemple, héberger cinq serveurs virtualisés sur un serveur physique revient à devoir installer et maintenir six systèmes d’exploitation distincts. Même si l’apparition d’outils d’automatisation comme Ansible, couplés à de nouveaux paradigmes comme OpenStack (ou plus généralement le « cloud computing ») ont permis de simplifier ces processus, un gaspillage évident de ressources (humaines, financières, mais aussi énergétiques) en découle directement.
C’est en partant de ce constat que les premières solutions dites de « conteneurisation » se sont popularisées. Leur principe est simple : plutôt que d’émuler le fonctionnement d’un serveur complet, on se contente d’exécuter certains processus dans un espace où ils seront isolés logiciellement. Il n’y a ainsi plus qu’un serveur à maintenir, avec un seul noyau et seul ensemble de ressources. Seul le strict nécessaire se retrouve isolé. Et ce principe est loin d’être nouveau : les « jails » sont disponibles dans BSD depuis 2000, les conteneurs (LXC) dans Linux depuis 2008. Et c’est sans compter sur OpenVZ, apparu en 2005, dont certains se rappelleront sans doute comme étant la solution retenue pour beaucoup de VPS à bas coût.
Mais comment Docker, pourtant arrivé cinq ans après lXC, a-t-il su s’imposer comme étant la solution de référence ? Et bien tout simplement en appliquant le principe roi en informatique : le KISS (Keep It Simple, Stupid), ou plus exactement MISS (Make It Simple Stupid). En réalité, Docker s’est imposé car il a permis d’offrir une surcouche venant grandement simplifier l’ensemble des opérations du cycle de vie de ces conteneurs : téléchargement d’images pré-configurées et versionnées (taguées) depuis des registres publics ou privés, création, démarrage, arrêt, suppression en une seule ligne de commande, immutabilité par défaut, interface graphique, etc.
Tout cela a rendu la conteneurisation accessible à de nouveaux publics : développeurs, néophytes, sysadmins surchargés peuvent dorénavant construire leurs infrastructures locales ou de production tout en s’affranchissant des problèmes de dépendances, de disponibilité des paquets ou de configuration. Couplez cela aux innombrables images communautaires disponibles et aux nombreux outils complémentaires (docker-compose, kubernetes, etc.), et vous obtenez la recette d’un outil qui aura su se propulser dans le cœur de nombreux ingénieurs DevOPS.
Dans un prochain article, nous reviendrons plus en détail sur l’arrivée de Docker chez Values associates, depuis les premières problématiques rencontrées jusqu’à l’expérience qui en a été retirée.
Si cette thématique vous a permis de mieux comprendre d’où vient et où mène Docker, n’hésitez pas à repartager cet article autour de vous.
Vous voulez par ailleurs en savoir plus sur notre socle no code ? Sur notre gamme de logiciels dédiés aux métiers de l’audit interne, du contrôle interne, de la compliance? Sur l’offre spécifique développée en partenariat avec Mazars sur les enjeux Sapin 2? C’est ici pour nous contacter 😀