Pages liées à Docker, Podman et à la conteneurisation.
Voir tous les tagsHistoriquement sous Unix, un processus est soit root (tous les pouvoirs), soit un utilisateur normal (aucun pouvoir spécial) — un modèle binaire, tout ou rien. Les capabilities découpent les super-pouvoirs de root en une trentaine de droits granulaires, qu'on peut accorder ou retirer indépendamment.
Là où les namespaces isolent la vue qu'un processus a du système, les cgroups limitent et comptabilisent les ressources qu'il peut réellement consommer : CPU, mémoire, I/O disque, nombre de processus. Sans cgroups, un conteneur qui boucle à l'infini pourrait épuiser toute la RAM de la machine hôte.
Extrait de Docker Engine en 2016 puis donné à la Cloud Native Computing Foundation (CNCF), containerd est le runtime de haut niveau qui fait tourner concrètement les conteneurs derrière Docker — et aussi derrière Kubernetes.
containerd est un runtime de conteneurs bas niveau (projet CNCF), utilisé comme moteur sous-jacent par Docker Engine (depuis la 18.09) et par Kubernetes (via CRI). Cette fiche couvre l'angle service systemd ; pour le fonctionnement détaillé du runtime, voir le lien en fin de page.
Contrairement à un conteneur Docker (pensé pour être jetable), un conteneur LXC est pensé pour être persistant et administré comme une machine — le cycle de vie reflète cette différence.
Comprendre la différence entre une image (figée, en lecture seule) et un conteneur (une instance en cours d'exécution) est la clé pour ne pas se perdre dans les commandes Docker.
dockerd est le démon (daemon) qui gère les conteneurs, images, réseaux et volumes Docker. Le client docker (CLI) communique avec lui via un socket Unix. Cette fiche couvre uniquement l'angle service systemd ; pour l'usage de Docker au quotidien (images, Dockerfile, Compose), voir les liens en fin de page.
Dès qu'une application dépend de plusieurs conteneurs (un serveur web, une base de données, un cache...), lancer chacun à la main avec docker run devient vite ingérable. Compose décrit toute une application multi-conteneurs dans un seul fichier YAML, démarrable/arrêtable en une commande.
Un Dockerfile est une recette texte, exécutée instruction par instruction, où chaque instruction qui touche au système de fichiers crée une nouvelle couche. Comprendre ça explique la plupart des bonnes pratiques d'écriture.
Les équipements réseau modernes (routeurs, switches) intègrent des ressources de calcul (CPU/RAM dédiés) capables d'héberger directement des applications ou des conteneurs, sans serveur externe — rapprochant le traitement de la donnée au plus près de sa collecte (edge computing).
Une image Docker n'est pas un gros fichier monolithique : c'est un empilement de couches (layers), chacune représentant un diff du système de fichiers. C'est ce qui rend le partage d'images efficace — plusieurs images peuvent partager des couches identiques.
Incus est le fork communautaire de LXD (Linux Containers project), né en 2023 après le rachat de Canonical/LXD par une gouvernance jugée trop centralisée. Il conserve la même architecture : conteneurs système et VM légères via une API/CLI quasi identique à LXD, mais packagé nativement (pas de dépendance à snap) et maintenu par la communauté Linux Containers.
Deux approches existent : le paquet docker.io fourni par la distribution (souvent en retard sur la dernière version) ou le dépôt officiel Docker, recommandé pour avoir des versions à jour et cohérentes. Ce cours couvre l'installation via le dépôt officiel sur une distribution basée Debian/Ubuntu.
Installer les outils LXC bruts (Debian/Ubuntu)
Docker (2013) n'a pas inventé les conteneurs — les namespaces et cgroups existaient déjà, et LXC les combinait depuis 2008. Sa contribution a été de rendre les conteneurs faciles à utiliser : un format d'image portable, une commande unique pour construire/lancer/partager, et un écosystème complet autour (Docker Hub, Compose...).
LXC (LinuX Containers, 2008) est le projet qui a le premier rendu utilisables, via une CLI simple, les mécanismes noyau (namespaces + cgroups) déjà vus dans Qu'est-ce qu'un conteneur ?. Docker s'est d'ailleurs appuyé sur liblxc à ses tout débuts (avant de développer son propre runtime, libcontainer, devenu runc).
k3s (Rancher/SUSE) est une distribution Kubernetes allégée packagée en un unique binaire (< 100 Mo), pensée pour l'edge, l'IoT, le CI et les environnements où un cluster Kubernetes complet (kubeadm) est disproportionné. Il embarque control plane, kubelet et un runtime containerd dans un seul processus par nœud.
kubelet est l'agent qui tourne sur chaque nœud d'un cluster Kubernetes. Il reçoit des spécifications de Pods (via l'API server) et s'assure que les conteneurs correspondants tournent réellement, en pilotant un runtime de conteneurs (containerd, CRI-O) via l'interface CRI.
LXD est un gestionnaire de conteneurs système (par opposition aux conteneurs applicatifs Docker) : chaque conteneur LXD fait tourner un OS complet avec son propre init, se comportant comme une VM légère mais avec les performances d'un conteneur (namespaces + cgroups, pas d'hyperviseur). Peut aussi gérer des VM via QEMU.
Comme vu dans le cours Introduction & concepts, Incus (fork communautaire de LXD) est aujourd'hui l'interface recommandée pour gérer des conteneurs LXC au quotidien : un démon avec API REST, une CLI unifiée, des images prêtes à l'emploi, et la gestion intégrée du stockage/réseau. Les commandes ci-dessous utilisent incus, quasi identiques avec lxc sous LXD (il suffit généralement de substituer le nom de la commande).
Les namespaces sont le mécanisme noyau qui donne à un processus une vue isolée d'une ressource système — sans dupliquer cette ressource. C'est la brique la plus fondamentale de l'isolation des conteneurs.
Jusqu'en 2015, "conteneur" voulait dire "conteneur Docker" : le format d'image et le mode d'exécution étaient définis par un seul projet. L'OCI (Open Container Initiative, fondée en 2015 sous l'égide de la Linux Foundation, avec Docker comme contributeur fondateur) a standardisé ces formats pour que l'écosystème ne dépende plus d'une implémentation unique.
Contrairement à Docker, Podman n'a pas de démon permanent : chaque commande podman lance directement les conteneurs via runc/crun, ce qui simplifie le modèle de sécurité (pas de processus root persistant à protéger) et facilite le mode rootless par défaut. Cette fiche couvre l'angle service/socket systemd (API REST optionnelle) ; pour l'usage courant, voir le lien en fin de page.
Développé par Red Hat, Podman répond à deux critiques historiques de l'architecture Docker une expérience CLI quasi identique à docker, sans ces deux contraintes.
Un conteneur n'est pas une mini-machine virtuelle. C'est un processus Linux normal, auquel on a restreint la vue du système avec des mécanismes du noyau. Comprendre ça change tout : pas d'hyperviseur, pas de second noyau, juste de l'isolation.
Aide-mémoire exhaustif des commandes docker sur Linux, organisé par thème. Pour les concepts derrière chaque commande, voir les cours dédiés (Images, Volumes, Networks...).
Aide-mémoire des outils bas niveau liblxc (préfixés lxc-). Pour l'usage quotidien, la couche LXD/Incus est recommandée, mais connaître ces commandes reste utile pour comprendre ce qui se passe en dessous — et Incus/LXD s'appuient dessus.
Un registre est un serveur qui stocke et distribue des images, conformément à la spécification OCI distribution-spec (voir OCI). Docker Hub est le registre public par défaut, mais l'écosystème en compte beaucoup d'autres.
Chaque conteneur reçoit par défaut sa propre pile réseau isolée (un network namespace). Docker gère la connectivité entre conteneurs et vers l'extérieur via des drivers réseau configurables.
Seccomp (secure computing mode) est un mécanisme noyau qui filtre les appels système (syscalls) qu'un processus a le droit d'exécuter. Là où les capabilities limitent ce que root peut faire, seccomp limite quelles portes d'entrée vers le noyau le processus a le droit d'utiliser du tout — capability ou pas.
Ce cours assemble les briques vues séparément (Namespaces, cgroups, Capabilities, Seccomp) en une checklist pratique de durcissement, et couvre les angles pas encore traités : rootless, image scanning, secrets.
Contrairement aux conteneurs (qui partagent le noyau de l'hôte), une machine virtuelle simule un matériel complet — CPU virtuel, RAM virtuelle, disque virtuel — et fait tourner son propre noyau dessus. Ce cours couvre les extensions matérielles qui rendent cette simulation efficace.
Comme vu dans le cours Cycle de vie, la couche inscriptible d'un conteneur disparaît avec lui. Pour toute donnée qui doit survivre à la suppression d'un conteneur (base de données, fichiers uploadés...), il faut un mécanisme de stockage externe à cette couche.