Comprendre le démon Docker (dockerd) et le client Docker (docker CLI)

L'architecture client-serveur de Docker

Docker s'appuie sur une architecture client-serveur sophistiquée qui constitue le fondement de son fonctionnement. Cette séparation nette entre le client et le serveur permet une flexibilité remarquable dans la façon dont les utilisateurs interagissent avec les conteneurs. D'un côté se trouve le démon Docker (dockerd), un processus serveur persistant qui s'exécute en arrière-plan et gère tous les objets Docker (conteneurs, images, volumes, réseaux). De l'autre côté, le client Docker, généralement la commande CLI (Command Line Interface) nommée simplement docker, qui permet aux utilisateurs d'envoyer des instructions au démon via une API REST bien définie.

Cette architecture distribuée offre plusieurs avantages stratégiques par rapport à un modèle monolithique. Premièrement, elle permet une séparation claire des préoccupations : le démon se concentre sur l'exécution des tâches de bas niveau liées à la gestion des conteneurs, tandis que le client fournit une interface conviviale pour les utilisateurs. Deuxièmement, elle rend possible la gestion à distance des hôtes Docker, puisque le client peut communiquer avec un démon s'exécutant sur une machine distante via TCP/IP. Troisièmement, cette séparation facilite l'intégration avec divers outils tiers et interfaces graphiques qui peuvent interagir avec le même démon via l'API standardisée.

La communication entre le client et le démon s'effectue principalement par trois canaux possibles, chacun adapté à des scénarios d'utilisation spécifiques. Sur les systèmes Unix-like (Linux et macOS), le socket Unix /var/run/docker.sock constitue la méthode de communication par défaut, offrant d'excellentes performances pour les interactions locales. Sur Windows, les named pipes (tuyaux nommés) jouent un rôle similaire. Pour les communications réseau, par exemple lorsque le client et le démon s'exécutent sur des machines différentes, un socket TCP peut être configuré, généralement sécurisé par TLS pour préserver la confidentialité et l'intégrité des échanges.

La sécurisation de cette communication revêt une importance critique, car le démon Docker s'exécute généralement avec des privilèges élevés (root sur Linux). Un accès non autorisé au socket Docker équivaut pratiquement à un accès root sur la machine hôte, puisqu'il permet de monter des volumes arbitraires et d'exécuter des conteneurs privilégiés. Pour les communications locales via le socket Unix, la sécurité repose sur les permissions du système de fichiers. Pour les communications réseau, Docker implémente une authentification mutuelle par certificats TLS, où le client et le serveur vérifient mutuellement leur identité avant d'établir une connexion sécurisée.

L'API REST qui constitue la langue commune entre le client et le démon présente une structure hiérarchique bien organisée permettant de manipuler tous les aspects des conteneurs, images, volumes et réseaux. Cette API est entièrement documentée et versionnable, ce qui facilite le développement d'outils tiers et garantit une compatibilité ascendante. Chaque commande exécutée via la CLI Docker se traduit en une ou plusieurs requêtes API transmises au démon, qui les exécute et renvoie les résultats. Cette abstraction par API permet à des utilisateurs sans connaissance approfondie des mécanismes sous-jacents de conteneurisation de gérer efficacement leur infrastructure Docker.

Le démon Docker (dockerd) : fonctionnement et responsabilités

Le démon Docker (dockerd) constitue le coeur opérationnel de l'infrastructure Docker, agissant comme un chef d'orchestre qui coordonne l'ensemble des opérations liées aux conteneurs. Ce processus système de longue durée s'exécute constamment en arrière-plan et assume plusieurs responsabilités critiques : création et destruction de conteneurs, gestion du cycle de vie des images, allocation des ressources système, configuration des réseaux virtuels, et gestion des volumes de données persistantes. Sur les systèmes utilisant systemd (la plupart des distributions Linux modernes), le démon est généralement géré comme un service système standard via systemctl start|stop|status docker.

L'architecture interne du démon Docker a considérablement évolué au fil des versions pour gagner en modularité et en robustesse. Initialement monolithique, dockerd a été progressivement refactorisé pour déléguer certaines fonctionnalités critiques à des composants spécialisés. Parmi ceux-ci figure containerd, un runtime de conteneur compatible OCI (Open Container Initiative) qui gère le cycle de vie des conteneurs et leur exécution. Le démon Docker communique avec containerd pour la création et la gestion des conteneurs, tandis que containerd utilise à son tour runc (ou un autre runtime compatible OCI) pour l'exécution effective des conteneurs en interagissant avec les fonctionnalités de conteneurisation du noyau Linux.

La gestion des ressources système représente l'une des responsabilités centrales du démon Docker. Il utilise les cgroups (control groups) du noyau Linux pour limiter et isoler l'utilisation des ressources (CPU, mémoire, I/O disque, réseau) de chaque conteneur. Cette fonctionnalité permet d'éviter qu'un conteneur accapare toutes les ressources de l'hôte au détriment des autres. Le démon surveille également l'utilisation de ces ressources et peut être configuré pour appliquer des politiques spécifiques, comme le redémarrage automatique des conteneurs ayant échoué ou l'arrêt des conteneurs dépassant leurs limites de mémoire allouée.

La gestion du réseau constitue un autre domaine crucial de responsabilité pour le démon Docker. Il configure automatiquement des interfaces réseau virtuelles, des ponts réseau (bridges), et implémente la traduction d'adresses réseau (NAT) pour permettre la communication entre les conteneurs et avec le monde extérieur. Docker propose plusieurs pilotes réseau intégrés (bridge, host, overlay, macvlan, etc.) pour répondre à différents scénarios d'utilisation. Le démon s'occupe également de la résolution DNS entre conteneurs, permettant à ceux-ci de se découvrir mutuellement par leurs noms plutôt que par leurs adresses IP potentiellement changeantes.

La journalisation et le monitoring représentent des fonctions essentielles assurées par le démon Docker. Par défaut, il capture les flux de sortie standard (stdout) et d'erreur standard (stderr) de chaque conteneur, les stocke dans des fichiers JSON et les rend accessibles via la commande docker logs. Des pilotes de journalisation alternatifs peuvent être configurés pour envoyer ces logs vers des systèmes externes comme syslog, journald, Splunk ou Elasticsearch. Le démon expose également des métriques sur son propre état et celui des conteneurs qu'il gère, permettant une intégration avec des systèmes de surveillance comme Prometheus.

Les mécanismes d'extension constituent une caractéristique importante du démon Docker moderne. A travers un système de plugins, dockerd peut être étendu pour supporter des pilotes de stockage alternatifs, des pilotes réseau tiers, ou des systèmes d'autorisation personnalisés. Cette architecture extensible permet à Docker de s'adapter à une variété d'environnements et de besoins spécifiques sans alourdir le coeur du système avec des fonctionnalités rarement utilisées. Les plugins peuvent être installés, activés, désactivés et configurés dynamiquement sans nécessiter un redémarrage complet du démon, contribuant ainsi à la flexibilité et à la résilience de l'infrastructure Docker.

Le client Docker CLI : interface utilisateur principale

Le client Docker CLI (Command Line Interface) représente le principal point d'interaction entre l'utilisateur et l'écosystème Docker. Cette interface en ligne de commande, invoquée via la commande docker, traduit les instructions humainement compréhensibles en appels API appropriés destinés au démon Docker. Sa conception ergonomique suit une structure cohérente organisée autour d'objets (container, image, network, volume) et d'actions (run, pull, build, inspect), facilitant ainsi son apprentissage et son utilisation quotidienne. Cette organisation hiérarchique des commandes permet même aux nouveaux utilisateurs de découvrir progressivement les fonctionnalités disponibles à travers l'aide contextuelle (docker --help ou docker container --help).

La syntaxe du client Docker suit généralement le modèle docker [OPTIONS] COMMAND [ARG...], où OPTIONS représente les paramètres globaux affectant le comportement du client (comme --debug pour activer les informations de débogage ou -H pour spécifier un hôte Docker distant). Les commandes de gestion de nouvelle génération adoptent une structure à deux niveaux plus explicite, comme docker container ls ou docker image build, qui clarifie l'objet manipulé tout en maintenant la rétrocompatibilité avec les commandes historiques plus concises comme docker ps ou docker build. Cette évolution syntaxique reflète la maturation de l'outil et son adaptation à un écosystème de plus en plus riche.

La flexibilité de configuration du client Docker constitue l'un de ses atouts majeurs. Il peut être personnalisé via plusieurs mécanismes : variables d'environnement (comme DOCKER_HOST pour spécifier un hôte distant ou DOCKER_TLS_VERIFY=1 pour activer la vérification TLS), fichier de configuration JSON (~/.docker/config.json), ou options de ligne de commande. Cette hiérarchie de configuration permet d'adapter finement le comportement du client à différents contextes d'utilisation, depuis les préférences personnelles d'un développeur jusqu'aux exigences strictes d'un environnement de production. La fonctionnalité de contextes Docker, introduite dans les versions récentes, simplifie davantage la gestion de multiples environnements Docker en permettant de basculer rapidement entre différentes configurations préétablies.

L'interaction avec registries d'images constitue une fonctionnalité essentielle du client Docker. Il gère l'authentification auprès de registries publics (comme Docker Hub) ou privés via la commande docker login, stocker les informations d'authentification de manière sécurisée dans le fichier config.json, généralement chiffré à l'aide du keystore du système d'exploitation. Le client implémente également des mécanismes sophistiqués pour la recherche d'images (docker search), leur téléchargement (docker pull), leur publication (docker push) ainsi que leur étiquetage et gestion locale. Ces interactions suivent les spécifications standardisées des registries Docker, garantissant ainsi la compatibilité avec la majorité des fournisseurs de registries conformes.

Les capacités de formatage et de filtrage des sorties représentent des fonctionnalités particulièrement appréciées dans les environnements automatisés ou pour le traitement par scripts. De nombreuses commandes Docker supportent l'option --format qui permet de spécifier un template Go pour structurer la sortie selon des besoins précis. Par exemple, docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Status}}" affiche un tableau personnalisé des conteneurs en cours d'exécution. De même, l'option --filter disponible sur plusieurs commandes permet de sélectionner précisément les objets qui correspondent à certains critères, comme docker container ls --filter "status=exited" pour lister uniquement les conteneurs arrêtés.

Le mode expérimental offre un aperçu des fonctionnalités en cours de développement, permettant aux utilisateurs aventureux de tester les futures capacités de Docker avant leur intégration officielle. Ce mode peut être activé en définissant "experimental": true dans le fichier ~/.docker/config.json. Les fonctionnalités expérimentales sont clairement marquées dans la documentation et peuvent être sujettes à des modifications ou même être retirées avant leur finalisation. Ce mécanisme permet à la communauté de contribuer au développement de Docker en fournissant des retours précieux sur les nouvelles fonctionnalités tout en maintenant la stabilité de la branche principale pour les utilisateurs privilégiant la fiabilité.

Configuration et personnalisation du démon Docker

La configuration du démon Docker s'effectue principalement via le fichier daemon.json, généralement situé dans /etc/docker/ sur les systèmes Linux ou C:\ProgramData\docker\config\daemon.json sur Windows. Ce fichier au format JSON permet de personnaliser précisément le comportement du démon sans avoir à modifier directement les scripts de démarrage du service. L'utilisation d'un fichier de configuration distinct présente plusieurs avantages : elle facilite la gestion programmatique des configurations, permet un versionning des paramètres dans des systèmes de contrôle de source, et garantit la persistance des configurations lors des mises à jour de Docker. Si ce fichier n'existe pas par défaut, vous pouvez le créer pour commencer à personnaliser votre installation.

Les options de stockage figurent parmi les paramètres les plus fréquemment ajustés dans la configuration du démon. Par défaut, Docker utilise le pilote overlay2 sur la plupart des distributions Linux modernes, mais d'autres options comme devicemapper, btrfs ou zfs sont disponibles selon les systèmes de fichiers supportés par votre distribution. L'emplacement des données Docker peut également être modifié via l'option "data-root", particulièrement utile lorsque la partition racine dispose d'un espace limité :

{
  "storage-driver": "overlay2",
  "data-root": "/mnt/docker-data",
  "storage-opts": [
    "overlay2.override_kernel_check=true"
  ]
}

La configuration réseau offre de nombreuses possibilités d'adaptation aux besoins spécifiques de votre environnement. Par défaut, Docker crée un réseau bridge nommé "docker0" avec la plage d'adresses 172.17.0.0/16. Cette configuration peut être modifiée pour éviter les conflits avec votre infrastructure existante :

{
  "bip": "192.168.1.1/24",
  "fixed-cidr": "192.168.1.0/25",
  "default-address-pools": [
    {"base": "172.80.0.0/16", "size": 24},
    {"base": "172.90.0.0/16", "size": 24}
  ],
  "dns": ["8.8.8.8", "8.8.4.4"]
}

Les options de journalisation configurent la façon dont Docker capture et gère les logs des conteneurs. Par défaut, Docker utilise le driver json-file qui stocke les logs dans des fichiers JSON, sans limite de taille ni rotation automatique. Cette configuration peut rapidement consommer beaucoup d'espace disque dans des environnements de production. Pour éviter ce problème, la rotation des logs peut être activée :

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "labels": "production_status",
    "env": "os,customer"
  }
}

Les paramètres de sécurité jouent un rôle crucial dans la protection de votre environnement Docker. Plusieurs options permettent de renforcer la posture de sécurité du démon :

{
  "userns-remap": "default",
  "no-new-privileges": true,
  "seccomp-profile": "/etc/docker/seccomp-profile.json",
  "selinux-enabled": true,
  "icc": false
}

Les options de performance et de ressources permettent d'ajuster finement le comportement du démon pour optimiser l'utilisation des ressources système. Des paramètres comme "default-shm-size" définissent la taille par défaut de la mémoire partagée disponible pour les conteneurs. La configuration de "default-ulimits" permet d'imposer des limites systèmes à tous les conteneurs :

{
  "default-shm-size": "64M",
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 64000,
      "Soft": 64000
    },
    "nproc": {
      "Name": "nproc",
      "Hard": 1024,
      "Soft": 1024
    }
  }
}

Options de sécurisation des communications

La sécurisation des communications entre le client Docker et le démon constitue un aspect fondamental, particulièrement lorsque ces communications traversent un réseau non sécurisé. Par défaut, le démon Docker écoute uniquement sur un socket Unix local (/var/run/docker.sock sur Linux) ou un named pipe sur Windows, ce qui limite les risques aux utilisateurs ayant déjà un accès local à la machine. Cependant, dès que le démon est configuré pour écouter sur un port réseau TCP (généralement 2375 non chiffré ou 2376 avec TLS), la mise en place d'une couche de sécurité robuste devient impérative pour prévenir toute prise de contrôle non autorisée.

La configuration d'une connexion TLS mutuelle représente la méthode privilégiée pour sécuriser les communications réseau avec le démon Docker. Cette approche nécessite la génération et la distribution d'une infrastructure à clés publiques (PKI) comprenant une autorité de certification (CA), un certificat serveur pour le démon et des certificats clients pour chaque utilisateur autorisé. Le processus débute par la création d'une CA privée :

mkdir -p ~/.docker/certs
openssl genrsa -out ~/.docker/certs/ca-key.pem 4096
openssl req -new -x509 -days 365 -key ~/.docker/certs/ca-key.pem \
  -out ~/.docker/certs/ca.pem

La génération du certificat serveur nécessite une attention particulière aux noms alternatifs du sujet (Subject Alternative Names ou SANs) qui doivent inclure tous les noms et adresses IP utilisés pour accéder à l'hôte Docker. Cette étape est cruciale car le client Docker vérifie que le certificat présenté par le serveur correspond bien au nom d'hôte utilisé pour la connexion :

openssl genrsa -out ~/.docker/certs/server-key.pem 4096
openssl req -new -key ~/.docker/certs/server-key.pem \
  -out ~/.docker/certs/server.csr

# Création d'un fichier d'extensions pour les SANs
echo "subjectAltName=DNS:yourdomain.com,DNS:*.yourdomain.com,IP:192.168.1.10" > ~/.docker/certs/extfile.cnf
echo "extendedKeyUsage=serverAuth" >> ~/.docker/certs/extfile.cnf

openssl x509 -req -days 365 -in ~/.docker/certs/server.csr -CA ~/.docker/certs/ca.pem \
  -CAkey ~/.docker/certs/ca-key.pem -CAcreateserial -out ~/.docker/certs/server-cert.pem \
  -extfile ~/.docker/certs/extfile.cnf

La configuration du démon Docker pour utiliser TLS s'effectue via plusieurs paramètres dans le fichier daemon.json ou via des options de ligne de commande :

{
  "tls": true,
  "tlsverify": true,
  "tlscacert": "/etc/docker/certs/ca.pem",
  "tlscert": "/etc/docker/certs/server-cert.pem",
  "tlskey": "/etc/docker/certs/server-key.pem",
  "hosts": ["tcp://0.0.0.0:2376", "unix:///var/run/docker.sock"]
}

Du côté client, la configuration TLS nécessite l'installation des certificats appropriés et la définition de variables d'environnement ou d'options de ligne de commande. La génération d'un certificat client suit un processus similaire à celui du serveur :

openssl genrsa -out ~/.docker/certs/client-key.pem 4096
openssl req -new -key ~/.docker/certs/client-key.pem -out ~/.docker/certs/client.csr

echo "extendedKeyUsage=clientAuth" > ~/.docker/certs/client-extfile.cnf
openssl x509 -req -days 365 -in ~/.docker/certs/client.csr -CA ~/.docker/certs/ca.pem \
  -CAkey ~/.docker/certs/ca-key.pem -CAcreateserial -out ~/.docker/certs/client-cert.pem \
  -extfile ~/.docker/certs/client-extfile.cnf

export DOCKER_HOST=tcp://your-docker-host:2376
export DOCKER_TLS_VERIFY=1
export DOCKER_CERT_PATH=~/.docker/certs

La rotation régulière des certificats constitue une bonne pratique de sécurité souvent négligée. Les certificats TLS comportent généralement une date d'expiration (typiquement un an dans les exemples précédents), mais attendre leur expiration pour les remplacer expose à un risque de service interrompu. Une approche plus proactive consiste à mettre en place un processus de rotation programmée, par exemple tous les trois à six mois, impliquant la génération de nouveaux certificats, leur distribution contrôlée aux clients et serveurs concernés, et une période de chevauchement durant laquelle les anciens et nouveaux certificats sont acceptés. Ce processus peut être automatisé via des outils comme certbot ou des scripts personnalisés intégrés à votre infrastructure de gestion de configuration.

Les restrictions d'accès au socket Unix local représentent un aspect critique de la sécurité, même lorsque TLS est configuré pour les communications réseau. Par défaut, le socket /var/run/docker.sock est accessible au groupe docker, ce qui signifie que tout utilisateur membre de ce groupe obtient implicitement des privilèges équivalents à root sur le système. Pour renforcer la sécurité, plusieurs approches peuvent être combinées : limiter strictement l'appartenance au groupe docker aux utilisateurs de confiance, utiliser des plugins d'autorisation comme Twistlock ou Authz pour un contrôle d'accès plus granulaire, ou implémenter le mode rootless Docker qui permet d'exécuter le démon avec des privilèges utilisateur standard. Cette dernière option, bien que comportant certaines limitations fonctionnelles, constitue la méthode la plus sécurisée pour les environnements à haute sensibilité.

Diagnostic et dépannage des problèmes client-serveur

Les problèmes de communication entre le client Docker et le démon figurent parmi les incidents les plus fréquemment rencontrés lors de l'utilisation quotidienne de Docker. L'erreur la plus commune se manifeste par le message "Cannot connect to the Docker daemon at [...]. Is the docker daemon running?". Ce message peut résulter de plusieurs causes distinctes : le démon Docker n'est effectivement pas démarré, le client tente de se connecter à un hôte incorrect, ou des problèmes de permissions empêchent l'accès au socket de communication. La première étape de diagnostic consiste à vérifier l'état du service Docker avec systemctl status docker sur les systèmes utilisant systemd, ou service docker status sur les systèmes plus anciens.

Les problèmes de configuration du démon peuvent être particulièrement délicats à diagnostiquer car une erreur dans le fichier daemon.json peut empêcher le démarrage complet du service. Si le démon refuse de démarrer après une modification de configuration, plusieurs approches de dépannage peuvent être employées. Commencez par vérifier la validité syntaxique du JSON avec jq . /etc/docker/daemon.json pour identifier d'éventuelles erreurs de format comme des virgules manquantes ou superflues. Ensuite, examinez les journaux système via journalctl -u docker pour obtenir des messages d'erreur spécifiques. Dans les cas extrêmes, il peut être nécessaire de déplacer temporairement le fichier de configuration problématique et redémarrer le service avec les paramètres par défaut.

Les problèmes liés à la configuration TLS constituent une source fréquente de difficultés lors de la connexion à des hôtes Docker distants. Ces problèmes se manifestent généralement par des erreurs cryptiques comme "x509: certificate signed by unknown authority" ou "x509: certificate is valid for X, not for Y". Pour diagnostiquer ces situations, activez le mode debug du client Docker via l'option --debug ou la variable d'environnement DOCKER_DEBUG=1. Vérifiez également la correspondance exacte entre le nom d'hôte utilisé dans la connexion et les noms alternatifs du sujet (SANs) inclus dans le certificat serveur. L'outil openssl peut être utilisé pour inspecter un certificat : openssl x509 -in server-cert.pem -text -noout affichera toutes les informations du certificat, y compris les SANs configurés.

Les problèmes de performance dans la communication client-serveur peuvent survenir dans divers scénarios, particulièrement lors de l'utilisation de connexions réseau sur des liens à haute latence ou lors de la manipulation d'images volumineuses. Le client Docker offre plusieurs options pour diagnostiquer ces problèmes, notamment --debug qui affiche des informations détaillées sur chaque étape de la communication avec le démon. Pour les opérations impliquant des transferts d'images, l'option --progress=plain disponible dans les commandes comme docker pull ou docker build fournit des informations plus granulaires sur la progression. Dans certains cas extrêmes, des outils d'analyse réseau comme tcpdump ou Wireshark peuvent être nécessaires pour identifier des goulots d'étranglement spécifiques.

Le dépannage des problèmes de permission sur le socket Docker nécessite une compréhension des mécanismes d'autorisation sous-jacents. Sur les systèmes Linux, vérifiez les permissions du socket avec ls -la /var/run/docker.sock qui devrait afficher quelque chose comme srw-rw---- 1 root docker, indiquant que le socket appartient à l'utilisateur root et au groupe docker. Si un utilisateur non root reçoit l'erreur "permission denied", vérifiez son appartenance au groupe docker avec groups username. Si l'utilisateur n'appartient pas à ce groupe, ajoutez-le avec usermod -aG docker username puis déconnectez-vous et reconnectez-vous pour que les changements prennent effet. Sur Windows, des problèmes similaires peuvent survenir si l'utilisateur n'a pas les droits administratifs nécessaires pour accéder au named pipe Docker.

Les outils de diagnostic intégrés à Docker peuvent considérablement faciliter l'identification de problèmes complexes. La commande docker system info fournit une vue d'ensemble complète de la configuration du démon, incluant le storage driver utilisé, les options de logging, les pilotes réseau disponibles et bien d'autres informations contextuelles précieuses. Pour les problèmes liés au réseau Docker, docker network inspect bridge permet d'examiner la configuration du réseau bridge par défaut. La commande docker system df offre une vision synthétique de l'utilisation d'espace par les différents objets Docker, ce qui peut aider à identifier des problèmes de saturation d'espace disque affectant le fonctionnement du démon. Ces outils intégrés, combinés avec la documentation détaillée disponible sur le site officiel de Docker, constituent généralement le premier niveau d'investigation avant de recourir à des outils système plus génériques.

API Docker REST : fondement de la communication

L'API REST Docker constitue le fondement sur lequel repose toute la communication entre le client et le démon, formant ainsi la colonne vertébrale de l'architecture Docker. Cette API suit les principes REST (Representational State Transfer) avec des endpoints organisés hiérarchiquement, correspondant aux différents objets Docker comme les conteneurs, images, volumes et réseaux. Chaque opération effectuée via l'interface en ligne de commande se traduit en une ou plusieurs requêtes HTTP transmises au démon, qui les exécute et retourne les résultats sous forme de réponses JSON structurées. Cette architecture basée sur une API permet une séparation claire entre la logique de présentation (l'interface utilisateur) et la logique métier (gestion des conteneurs), facilitant ainsi le développement d'interfaces alternatives et d'outils d'automatisation.

La structure de l'API Docker s'organise autour d'URLs prévisibles qui reflètent la hiérarchie des ressources manipulées. Par exemple, /containers gère les opérations relatives aux conteneurs, /images celles concernant les images, et ainsi de suite. Chaque ressource supporte généralement les méthodes HTTP standard : GET pour récupérer des informations, POST pour créer de nouvelles ressources, DELETE pour supprimer des ressources existantes, etc. Par exemple, une requête GET vers /containers/json liste les conteneurs en cours d'exécution, ce qui correspond exactement à la commande docker ps. Cette correspondance directe entre les commandes CLI et les endpoints API facilite la compréhension du système pour les développeurs souhaitant créer leurs propres outils ou automatisations.

Le versionnage de l'API Docker joue un rôle crucial dans le maintien de la compatibilité à long terme. Chaque endpoint est préfixé par un numéro de version (par exemple, /v1.41/containers/json), permettant l'évolution de l'API sans rompre la compatibilité avec les clients existants. Le démon Docker supporte généralement plusieurs versions de l'API simultanément, facilitant ainsi la transition progressive des clients vers les nouvelles fonctionnalités. Lors de l'initialisation, le client Docker négocie automatiquement la version d'API la plus récente compatible avec le démon et le client. Cette stratégie de versionnement explique pourquoi des clients Docker relativement anciens peuvent toujours communiquer avec des démons récents, bien que certaines fonctionnalités avancées puissent ne pas être accessibles.

La documentation complète de l'API Docker est disponible publiquement et constitue une ressource précieuse pour les développeurs. Chaque endpoint est documenté avec ses paramètres, codes de retour possibles, formats de requête et de réponse, ainsi que des exemples concrets d'utilisation. Cette transparence a grandement contribué à l'écosystème florissant d'outils tiers qui s'intègrent avec Docker. La documentation de l'API inclut également des sections détaillées sur l'authentification, la gestion des erreurs, et les bonnes pratiques d'utilisation. Pour explorer interactivement l'API, le démon Docker peut être configuré pour exposer une interface Swagger/OpenAPI via l'option --api-enable-cors, offrant ainsi une documentation interactive accessible via un navigateur web.

L'utilisation directe de l'API REST peut s'avérer nécessaire dans certains scénarios avancés où les fonctionnalités de la CLI sont insuffisantes ou dans des contextes d'automatisation spécifiques. Par exemple, pour lister les conteneurs en cours d'exécution directement via l'API :

curl -s --unix-socket /var/run/docker.sock http://localhost/v1.41/containers/json | jq

curl -s --cert ~/.docker/cert.pem --key ~/.docker/key.pem \
  --cacert ~/.docker/ca.pem https://docker-host:2376/v1.41/containers/json

Les SDKs (Software Development Kits) officiels et communautaires facilitent l'interaction programmatique avec l'API Docker sans nécessiter la manipulation directe des requêtes HTTP. Docker maintient des SDKs officiels pour plusieurs langages populaires comme Python (docker-py), Go (client Go), Java et JavaScript (dockerode). Ces bibliothèques encapsulent les détails de l'API REST derrière des interfaces orientées objet intuitives et gèrent automatiquement des aspects comme la négociation de version, la sérialisation/désérialisation JSON et la gestion des erreurs. Par exemple, en Python :

import docker
client = docker.from_env()
for container in client.containers.list():
    print(f"{container.id}: {container.name} - {container.status}")