Aller au contenu
Accueil » Blog » Au-delà de Docker : pourquoi il est temps de parler de containers… vraiment

Au-delà de Docker : pourquoi il est temps de parler de containers… vraiment

Docker n’est pas un synonyme de conteneur

Certes, Docker a popularisé les containers Linux dès 2013, rendant leur usage accessible avec un outil simple. Mais le conteneur existait bien avant (LXC, chroot, Solaris Zones…) !

Aujourd’hui, l’écosystème est normalisé grâce à l’Open Container Initiative (OCI).

Problème : le langage courant et même la documentation technique continuent de confondre Docker (l’outil) et container (le concept).

Continuer à parler de “Docker” pour tout ce qui touche aux containers, c’est comme appeler toutes les imprimantes ou photocopieurs des “Xerox”, “Brother” ou “Lexmark” — pratique, mais faux, et parfois bloquant. C’est également l’histoire de la marque Frigidaire (abrégé “frigo”) pour les réfrigérateurs. Il s’agit d’un antonomase !

De Docker à OCI – la normalisation du monde des containers

Pour la faire courte, en 2013 Docker Inc. révolutionne l’utilisation des containers :

  • docker build
  • docker run

Dès 2015, OCI est créé. C’est d’ailleurs lancé par Docker et d’autres acteurs (Red Hat, CoreOS, Google, etc.) pour définir des standards ouverts.
Les standards ouverts sont un peu l’ossature invisible qui permet à l’open source de réellement tenir ses promesses.
Sans eux, on aurait plein de projets formidables… mais incapables de travailler ensemble, un peu comme si tout le monde parlait un dialecte maison.

Dans notre cas, en plus de la création d’un langage commun, cela nous évite le vendor lock-in : nous ne sommes pas coincé avec un seul outil ou fournisseur : Docker. En plus, les standards assurent que l’écosystème reste viable même si un acteur clé change de cap (exemples avec Bitnami, et même Docker Inc. récemment).

Le consortium autour d’OCI permet de publier deux spécifications majeures :

  • OCI Runtime Specification → définit comment un container doit être exécuté.
  • OCI Image Specification → définit le format standard des images.

Grâce aux standards OCI, la technologie ne meurt pas si Docker disparaît !

Tout cela a permit à d’autres runtimes (containerd, CRI-O, runc, kata-runtime, podman) de voir le jour et de parvenir à fonctionner avec les mêmes images container.

Kubernetes ne dépend plus de Docker depuis 1.24. A la place, il utilise l’interface CRI pour parler à un runtime OCI (n’importe lequel répondant aux standards OCI Runtime Specification).

Pourquoi continuer à dire “Docker” pose problème

De notre point de vue, cela créé une ambiguité technique. “Docker” désigne un produit commercial, pas un standard. Cela suggère parfois que Docker est utilisé dans certains systèmes alors que ce n’est pas forcément le cas.

Des hypothèses sont émises… au risque qu’elles engendrent de mauvais choix par la suite. Les avantages et limites ne sont pas systématiquement les mêmes entre CRI.

Dans tous les cas, une image OCI peut être construite et exécutée sans Docker !

On peut parler également de verrouillage mental : les équipes pensent qu’elles “ont besoin de Docker” pour faire du container. Dans le monde CI/CD, cela freine l’adoption d’outils plus légers ou spécialisés (buildah, buildkit, kaniko, etc.).

Et nous ne parlons même pas du manque d’intéropérabilité des livrables. Les scripts ou documentations qui utilisent uniquement docker CLI deviennent incompatibles dans des environnements sans Docker Engine.

Aujourd’hui, les plus grands acteurs du monde Cloud se sont séparés de Docker pour adopter un nouveau lexique :

Nos bonnes pratiques de langage et d’outillage

Mauvaise habitudeMeilleure alternativePourquoi
Parler de “Docker image”Dire “image OCI” ou “image de container”Plus neutre et exact
Fichier DockerfileContainerfileAligné sur la terminologie OCI
docker buildpodman build / buildah budMoins de dépendance à Docker
docker runcrictl run / orchestration via K8sCompatible OCI
docker execcrictl execInterface standard avec Kubernetes
Référencer “Docker” dans la doc interneUtiliser “container” ou “runtime OCI”Réduit la confusion

Un changement de culture, pas juste d’outil

Docker restera une brique importante de l’histoire des containers, mais parler correctement d’images OCI et de runtimes CRI, c’est s’aligner sur la réalité technique actuelle et se préparer pour l’avenir.

Les avantages sont clairs :

  • moins de dépendances
  • plus de compatibilité
  • meilleure clarté pour les équipes

Dans l’open source, un standard ouvert c’est comme une prise électrique universelle : chacun peut fabriquer ses appareils, mais tout se branche et tout fonctionne.
Sans ça, on retomberait dans un patchwork d’incompatibilités, et l’agilité que promet le cloud native serait largement réduite.

Le container est une technologie ouverte, et notre vocabulaire doit l’être aussi.

Ressources utiles