Docker, une technologie de conteneurisation qui séduit et s’affirme

Pour comprendre la conteneurisation (et donc Docker), il faut comparer cette technologie avec la virtualisation. Il est d’ailleurs fréquent de retrouver dans la littérature le terme de « virtualisation légère » pour décrire Docker.

L’architecture est cependant différente. Pour expliquer ces différences, une analogie souvent utilisée : la comparaison entre une maison (machine virtuelle) et un appartement (conteneur) :

• Les maisons: entièrement autonomes et offrent une protection (porte avec serrure). Elles disposent de leur propre infrastructure en terme de plomberie, chauffage, électricité etc… Il est presque impossible de louer une maison au format « studio » car une maison dispose généralement d’une chambre, cuisine séparée, d’une salle de bain et d’un salon. Vous serez bien souvent dans l’obligation de louer une maison plus grande ou plus petite que ce dont vous avez besoin.

• Les appartements: offrent également une protection (porte avec serrure), mais ils sont construits autour d’une infrastructure partagée. L’immeuble est ici le serveur exécutant Docker. Il propose une plomberie, chauffage, électricité etc partagée pour chaque appartement (conteneur). Les appartements sont offerts en plusieurs tailles différentes – du studio au T7 en passant par le penthouse. Vous ne louez que ce dont vous avez besoin. Le concept d’image Docker peut être rapporté au plan d’architecte. Elle va permettre de créer le conteneur en suivant une procédure bien précise.

Comparaison entre Virtualisation et conteneurisation – Source BigInt

Comme montré dans la figure ci-dessus, les conteneurs Docker partagent les ressources sous-jacentes de l’hôte Docker. De plus, les développeurs créent une image Docker qui comprend exactement ce dont ils ont besoin pour exécuter leur application. Les machines virtuelles adoptent une posture différente en embarquant la totalité d’un système d’exploitation et, bien souvent, la plupart des composants de ce système seront inutiles au fonctionnement de l’application et consommeront donc des ressources inutilement.

Le premier usage de la conteneurisation est pour le développement et le déploiement d’applications : en effet, en utilisant une image, une équipe de développement peut ainsi partager simplement la même configuration de développement, évitant ainsi les écarts entre plusieurs membres de l’équipe. L’image permet également de ne pas avoir d’écart entre l’environnement de développement et la production en permettant, en fin de cycle de développement, de déployer tout simplement l’image validée et testée en production.

Attention cependant : la création et l’accès aux données gérées/générées par le conteneur (l’application conteneurisée) doit se faire à l’extérieur dudit conteneur aux travers de « volumes ». Ces derniers contiendront les données générées/gérées par l’application (fichier de base de données par exemple). L’idée est de rendre le conteneur « immutable ». Si tel n’est pas le cas, les données seront détruites lors de la destruction du conteneur.

En terme d’autres usages métiers, d’après l’enquête Sysdig, l’on distingue plusieurs tendances en environnement de production:

• le nombre moyen de conteneurs hébergés par une machine donnée (VM ou physique) est de 15 (avec un pic d’observation à 154 conteneurs actifs sur la même machine).
• en terme de technologies, on retrouve principalement des environnements techniques associés à la haute performance applicative web ou à l’exploitation de données (JVM / Redis / etcd / NGINX et PostgreSQL occupent le haut du classement).
• 95% des conteneurs ont une durée de vie supérieure à une semaine. Si on considère l’augmentation de l’utilisation de conteneurs orientés stockage et gestion de données à long terme (PostgreSQL / MongoDB), la tendance qui se confirme est l’extension de l’utilisation d’un conteneur Docker à des applications plus élaborées et dont les données doivent persister dans le temps.
• 69% des conteneurs sont mis à jour au moins une fois par semaine, (modification et déploiement de l’image associée) ce qui reflète des solutions applicatives associées à des cycles de développement / correction courts.

De plus, d’après l’étude GrandView, à cause d’une progression massive de l’IOT et du besoin d’exploitation des données associées, la prise de parts de marché par Docker dans le domaine des solutions de conteneurisation devrait continuer à progresser au même rythme sur les 5 prochaines années.

Evolution des parts de marché des différentes solutions de conteneurisation (marché US)

• Docker comme aide au développement en environnements hétérogènes
  Nous utilisons Docker afin de faciliter nos développements et d’adapter ces derniers à l’architecture finale. Il est extrêmement facile et rapide de monter une « stack » (un ensemble de composant permettant d’exécuter l’application) calquée sur l’infrastructure du client et d’éviter le « mais pourtant ça marche chez moi en local… ».

L’utilité de Docker pour une équipe de développement

De plus, en contexte de développement, il devient vite laborieux d’entretenir plusieurs versions de PostgreSQL ou MongoDB (pour ne citer qu’eux) sur sa machine (un client à la version X, l’autre la version Y, le client X utilise un ReplicaSet, l’autre non…).

• Mais aussi pour faciliter le travail en équipe
  Nous l’utilisons également pour harmoniser les développements lorsque nous sommes plusieurs développeurs à travailler sur un projet. Mettre à jour et configurer son poste pour travailler sur un projet est systématiquement chronophage, et la complexité devient exponentielle lorsqu’il faut rapidement switcher entre projets (hotfix, évolution urgente, …).
  Via docker-compose, Docker permet de démarrer plusieurs conteneurs simultanément et donc de déployer et travailler sur une « stack » commune en quelques secondes ou minutes tout au plus dans la mesure ou toute l’application (le code) et ses dépendances (base de données, librairie etc…) seront lancés.
  Les développements sont alors effectués au plus près du cas réel et il est plus facile de détecter les différents problèmes techniques. Ces applications peuvent ensuite être exécutées en production dans un environnement conteneurisé ou non suivant le souhait du client.

• Adresser l’innovation
  Docker rentre également dans notre stratégie d’édition de logiciel SaaS (IoT et autres dans le futur) en appliquant une démarche d’intégration, de distribution et de déploiement continue (CI/CD) en compilant nos applications, en automatisant les tests et en mettant automatiquement en production.
  Déployer rapidement un conteneur Docker nous permet aussi d’expérimenter sans risque de nouvelles technologies dans ces domaines en maitrisant complètement l’environnement de test.

• Comment sauvegarder mes conteneurs ?
  La réponse est courte, vous ne le faites pas. Pour étayer ce propos, il faut expliquer les unités d’abstractions des VM et des conteneurs. L’unité d’abstraction des VM est un OS complet qui stocke une application et les données s’y afférant et donc son état. Il s’agit d’empaqueter dans un binaire unique tout ce qui autrefois se trouvait sur un serveur physique.
  Dans le cadre des conteneurs, l’unité d’abstraction est l’application ou un micro-service. Les données (donc son état) ne se trouvent pas dans le conteneur mais dans un « volume », comme évoqué précédemment. Il est donc nécessaire de sauvegarder un volume et non le conteneur qui lui, DOIT être sans état.
• Comment mettre à jour mes conteneurs ?
  Idem, vous ne le faites pas. A la place, il est nécessaire de mettre à jour l’image, de supprimer l’ancien conteneur et d’en recréer un nouveau avec l’image mise à jour. Même s’il est techniquement possible de mettre à jour un conteneur, cela est considéré comme une mauvaise pratique car le déploiement de nouveaux conteneurs avec l’ancienne image non mise à jour peut causer des erreurs, l’environnement déployé se retrouvant ainsi en décalage avec l’environnement utilisé pour le développement. Des outils permettent le type de mise à jour sans interruptions de services en démarrant le nouveau conteneur (basé sur l’image mise à jour) et attendre que ce dernier soit démarré avant de détruire et remplacer l’ancien.
  On appelle cela des outils d’orchestration. Il en existe deux principaux à savoir Swarm et Kubernetes.