Architecture de Docker Desktop expliquée avec des exemples pratiques

Introduction

Docker Desktop est le moyen le plus courant d'exécuter des conteneurs sur macOS et Windows, mais son architecture est souvent mal comprise. De nombreux développeurs interagissent avec lui via docker run et ne vont jamais plus loin. Lorsque quelque chose se casse, une vision superficielle ne suffit pas. Cet article explique les composants clés de Docker Desktop, comment ils fonctionnent ensemble et comment vérifier chaque élément avec des commandes pratiques. Vous apprendrez à diagnostiquer les problèmes courants, à gérer les données en toute sécurité et à prendre des décisions éclairées concernant les performances, le réseau et les mises à niveau.

L'architecture est importante car Docker Desktop n'est pas un simple wrapper CLI. Il exécute une machine virtuelle (VM) Linux en arrière-plan, gère la traduction réseau et gère le partage de fichiers entre l'hôte et la VM. Comprendre ces couches vous aide à résoudre les problèmes plus efficacement et à éviter les pièges courants. Nous couvrirons la VM, le moteur Docker, la CLI, Compose, le stockage, le réseau et l'API d'administration, avec des exemples que vous pouvez exécuter sur votre propre machine.

Cet article s'adresse aux développeurs, ingénieurs DevOps et responsables techniques qui utilisent Docker Desktop quotidiennement et souhaitent passer d'une approche par essais et erreurs à une approche systématique. Chaque section comprend une description, une commande de vérification et des indications sur le moment de l'utiliser. À la fin, vous serez en mesure d'inspecter votre propre environnement et de répondre : mon Docker Desktop est-il sain ?

Inventaire de version et d'environnement

Avant de changer quoi que ce soit, sachez ce que vous exécutez. Les versions de Docker Desktop sont publiées fréquemment, et les problèmes sont souvent corrigés dans les versions plus récentes. Vérifiez votre version avec :

docker version

La sortie attendue inclut les versions du client et du serveur, par exemple :

Client: Docker Engine - Community
 Version:           24.0.6
 API version:       1.43
 Go version:        go1.20.7
 Git commit:        1a79695
 Built:             Fri Sep  1 19:07:36 2023
 OS/Arch:           darwin/arm64
 Context:           default

Server: Docker Desktop 4.25.0 (126437)
 Engine:
  Version:          24.0.6
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.7
  Git commit:       e2c7c9f
  Built:            Fri Sep  1 19:07:36 2023
  OS/Arch:          linux/arm64
  Experimental:     false

Vérifiez également la version de l'application Docker Desktop dans l'interface utilisateur ou avec :

docker info --format '{{.ServerVersion}}'

Cela renvoie une chaîne comme 24.0.6. Si votre version est plus ancienne que la dernière version stable, envisagez une mise à niveau. Les changements de VM (par exemple, le passage de HyperKit au framework Apple Virtualization sur macOS) affectent les performances et nécessitent une version spécifique de Docker Desktop.

Pour comprendre votre environnement, exécutez :

docker context ls

Vous verrez une liste de contextes, généralement default pour Docker Desktop. L'astérisque indique le contexte actif. Si vous avez configuré colima ou un hôte Docker distant, assurez-vous de cibler le contexte prévu. Le changement de contexte se fait avec docker context use <nom>.

Pour les opérations courantes, exécutez régulièrement docker system df pour voir l'utilisation du disque :

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          15        3         6.2GB     3.1GB (50%)
Containers      0         0         0B        0B
Local Volumes   10        2         1.4GB     400MB (28%)
Build Cache     20        0         2.8GB     2.8GB

Un espace récupérable élevé est un signal pour nettoyer les objets inutilisés. Mais observez et enregistrez toujours l'état actuel avant de nettoyer.

Chemin de configuration sûr

La configuration de Docker Desktop est répartie entre les paramètres graphiques et les fichiers. Le fichier de configuration principal est $HOME/.docker/daemon.json (ou %USERPROFILE%\.docker\daemon.json sur Windows). Docker Desktop gère certains paramètres via l'interface utilisateur, mais les options avancées (comme les registres personnalisés ou les pools d'adresses par défaut) vont dans ce fichier. Si le fichier est invalide, le démon peut ne pas démarrer. Validez le JSON avant de redémarrer :

cat ~/.docker/daemon.json | jq .

Si jq n'est pas installé, utilisez Python :

python3 -m json.tool ~/.docker/daemon.json

Un daemon.json typique pour le développement local pourrait ressembler à :

{
  "registry-mirrors": ["https://mirror.gcr.io"],
  "experimental": true,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Après avoir modifié ce fichier, redémarrez Docker Desktop. Vérifiez que les paramètres ont pris effet :

docker info --format '{{.RegistryConfig.Mirrors}}'

La sortie attendue montre le miroir configuré. Si Docker Desktop ne démarre pas, ouvrez les journaux de diagnostic depuis l'interface utilisateur ou vérifiez ~/.docker/log/host/ pour les erreurs du démon.

Les limites de ressources (CPU, mémoire, swap) sont définies dans l'interface utilisateur de Docker Desktop sous Paramètres > Ressources. Elles sont stockées dans ~/Library/Group Containers/group.com.docker/settings-store.json sur macOS ou %APPDATA%\Docker\settings-store.json sur Windows. Évitez de modifier ce fichier directement ; utilisez l'interface utilisateur. Pour vérifier les ressources allouées depuis la CLI, utilisez :

docker run --rm alpine cat /proc/meminfo | head -1

Cela montre la mémoire totale visible par la VM, qui devrait correspondre à votre allocation. Par exemple, si vous avez alloué 4 Go, attendez-vous à MemTotal: 4046560 kB.

Lorsque vous apportez des modifications de configuration, changez un paramètre à la fois, redémarrez et vérifiez. Cela isole les problèmes et facilite le retour en arrière.

Vérification et diagnostics

Une installation Docker Desktop saine répond aux commandes de base. Utilisez ces vérifications dans l'ordre :

1. Moteur en cours d'exécution

docker info

Si le serveur ne fonctionne pas, vous verrez une erreur comme Cannot connect to the Docker daemon. Sur macOS, vérifiez si l'application Docker Desktop est en cours d'exécution avec pgrep -fl Docker ou en ouvrant l'application. Sur Windows, vérifiez le service com.docker.service dans la console Services. Si le moteur est opérationnel, docker info renvoie un grand JSON avec les détails du serveur. Faites attention à Server Version, Storage Driver et Operating System.

1. Exécuter un conteneur de test

docker run --rm hello-world

La sortie attendue inclut un message de bienvenue et confirme que le démon peut extraire des images et démarrer des conteneurs.

1. Inspecter le réseau

docker network ls

Vous devriez voir les réseaux bridge, host et none. Docker Desktop utilise un proxy userland pour la publication des ports. Pour tester le mappage de port, exécutez :

docker run -d -p 8080:80 --name nginx-test nginx
curl http://localhost:8080

Le curl devrait renvoyer la page nginx par défaut. Si cela échoue, vérifiez les règles de pare-feu et si un autre processus utilise le port 8080. Sur macOS, Docker Desktop utilise vpnkit pour le réseau ; un problème connu est l'interférence des logiciels VPN avec la redirection de port. La solution consiste à désactiver le VPN ou à ajuster ses paramètres pour autoriser Docker.

1. Vérifier la consommation des ressources

Sur macOS, utilisez ps aux | grep '[D]ocker' pour voir l'utilisation du CPU et de la mémoire de com.docker.backend. Sur Windows, utilisez le Gestionnaire des tâches. Un CPU élevé sans conteneurs en cours d'exécution suggère une tâche en arrière-plan comme la synchronisation de fichiers ou une construction d'image cassée. Enquêtez avec docker stats --no-stream pour voir l'utilisation spécifique des conteneurs.

1. Diagnostiquer les problèmes de partage de fichiers

Les performances et la cohérence du partage de fichiers sont des problèmes courants, surtout avec les montages bind. Vérifiez votre fournisseur actuel de partage de fichiers :

docker info --format '{{.DriverStatus}}'

Cherchez Filesystem ou Storage Driver. Docker Desktop sur macOS utilise désormais VirtioFS par défaut (depuis la version 4.15). Si vous voyez gRPC FUSE, vous pourriez bénéficier du passage à VirtioFS dans Paramètres > Général. Pour tester les performances du système de fichiers, exécutez :

docker run --rm -v $(pwd):/data alpine sh -c 'dd if=/dev/zero of=/data/testfile bs=1M count=100; rm /data/testfile'

Comparez le temps avec une écriture native sur l'hôte. De grandes différences indiquent une surcharge. Pour le développement, gardez le code source dans un bind mount mais évitez les opérations d'E/S lourdes dans les volumes montés. Utilisez des volumes nommés pour les bases de données et les artefacts de construction.

Modes de défaillance et récupération

Docker Desktop peut échouer de plusieurs manières. Identifier le mode vous aide à récupérer rapidement.

Le moteur ne démarre pas

Symptôme : les commandes docker renvoient Cannot connect to the Docker daemon. Causes : VM corrompue, mise à jour incompatible, espace disque insuffisant ou daemon.json mal configuré. Récupération :

• Vérifiez l'état de Docker Desktop dans l'interface utilisateur. Essayez de quitter et de redémarrer l'application.
• Examinez les journaux : tail -f ~/Library/Containers/com.docker.docker/Data/log/host/*.log (macOS) ou Get-EventLog -LogName Application -Source Docker (Windows).
• Réinitialisez aux paramètres d'usine depuis le menu Dépannage. Cela supprime les conteneurs et les images mais préserve les volumes.
• Réinstallez Docker Desktop si nécessaire.

Épuisement de l'espace disque

Symptôme : les constructions échouent avec no space left on device ou Docker Desktop avertit de l'utilisation du disque. Causes : accumulation d'images, conteneurs, volumes et cache de construction inutilisés. L'image disque de la VM grandit mais ne se réduit pas automatiquement. Récupération :

• Exécutez docker system df pour voir l'utilisation.
• Supprimez les objets inutilisés : docker system prune -a --volumes (attention : supprime les volumes inutilisés).
• Si l'image disque de la VM elle-même est volumineuse, depuis l'interface utilisateur, allez dans Dépannage > Nettoyer / Purger les données. Cela réinitialise complètement Docker Desktop.
• Sur macOS, vous pouvez également supprimer manuellement Docker.raw dans ~/Library/Containers/com.docker.docker/Data/vms/0/data/ après avoir quitté Docker, mais c'est un dernier recours.

Dégradation des performances du partage de fichiers

Symptôme : les applications exécutées dans des conteneurs sont lentes lors de la lecture/écriture de fichiers montés. Causes : utilisation de l'ancien gRPC FUSE au lieu de VirtioFS, ou E/S lourdes dans les bind mounts. Récupération :

• Assurez-vous que VirtioFS est activé (Paramètres > Général > Choisir l'implémentation du partage de fichiers).
• Pour les grands dépôts de code, envisagez des stratégies basées sur docker sync ou des volumes, mais soyez conscient de la complexité supplémentaire.
• Déplacez les données des bases de données vers des volumes nommés, pas des bind mounts.

Conflits de ports

Symptôme : le conteneur démarre mais ne peut pas publier le port, erreur : Bind for 0.0.0.0:8080 failed: port is already allocated. Causes : un autre conteneur ou processus hôte utilise le port. Récupération :

• Trouvez le processus utilisant le port : lsof -i :8080 (macOS/Linux) ou netstat -ano | findstr :8080 (Windows).
• Arrêtez le processus en conflit ou modifiez le mappage de port du conteneur.

Kubernetes ne démarre pas

Symptôme : le cluster Kubernetes reste bloqué à l'état Starting. Causes : ressources insuffisantes, contexte conflictuel ou installation corrompue. Récupération :

• Vérifiez l'allocation des ressources ; Kubernetes nécessite au moins 2 CPU et 2 Go de RAM.
• Exécutez kubectl config get-contexts pour vous assurer que vous utilisez le contexte docker-desktop.
• Réinitialisez Kubernetes depuis le menu Dépannage.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour la maintenance de routine et avant tout changement majeur. Chaque élément comprend une commande et un résultat attendu.

Pour chaque élément de la liste, attribuez un seul responsable et définissez une fréquence de révision. Par exemple, Priya Shah (responsable DevOps) examine l'utilisation du disque et les versions du moteur chaque lundi. Révisez la liste de contrôle trimestriellement pour ajuster les fréquences en fonction de l'historique des incidents.

Pièges courants

Même les utilisateurs expérimentés de Docker Desktop tombent dans ces pièges. Voici comment les éviter.

Utiliser Docker Desktop comme environnement d'exécution de production

Pourquoi cela arrive : les développeurs s'habituent à Docker Desktop et pensent qu'il fonctionne de la même manière en production. Comment éviter : Docker Desktop est conçu pour le développement local. Il exécute un moteur à nœud unique dans une VM avec des valeurs par défaut non renforcées. Pour la production, utilisez un service géré (ECS, GKE, AKS) ou un hôte Linux autogéré avec Docker Engine. Exécutez des tests d'intégration sur un système CI avec un environnement similaire à la production.

Ignorer la compatibilité de version entre clients et serveurs

Pourquoi cela arrive : le client Docker peut être mis à jour indépendamment de Docker Desktop, surtout avec Homebrew ou les gestionnaires de paquets. Comment éviter : assurez-vous que docker version montre des versions client et serveur compatibles. Docker prend en charge une gamme de versions d'API, mais mélanger des versions très anciennes et très récentes peut provoquer un comportement inattendu. Épinglez les versions dans la documentation et les scripts de configuration d'équipe.

Utiliser des bind mounts pour les bases de données

Pourquoi cela arrive : il semble facile de monter un répertoire hôte pour les données de la base de données afin d'inspecter les fichiers. Comment éviter : les bind mounts peuvent causer des problèmes de permissions et de performances, surtout sur macOS/Windows. Utilisez des volumes nommés pour les bases de données :

docker volume create pgdata
docker run -d -v pgdata:/var/lib/postgresql/data postgres

Les volumes nommés sont gérés par Docker et offrent de meilleures performances pour de nombreuses charges de travail.

Surallouer les ressources à Docker Desktop

Pourquoi cela arrive : les utilisateurs donnent à Docker Desktop tout le CPU et la mémoire disponibles pour améliorer les performances. Comment éviter : la surallocation peut priver le système d'exploitation hôte et d'autres applications, provoquant des ralentissements et de l'instabilité. Commencez par des limites modérées (par ex., 50 % du total) et surveillez. Ajustez en fonction de l'utilisation réelle, pas du besoin perçu.

Ne pas nettoyer le cache de construction

Pourquoi cela arrive : le cache de construction s'accumule silencieusement et consomme de l'espace disque. Comment éviter : exécutez régulièrement docker builder prune pour supprimer le cache de construction en suspens. Utilisez docker system prune pour un nettoyage plus large, mais comprenez ce qu'il supprime.

Modifier daemon.json pendant que Docker est en cours d'exécution

Pourquoi cela arrive : les utilisateurs modifient daemon.json et redémarrent le service Docker, sans réaliser que Docker Desktop gère le fichier. Comment éviter : quittez toujours Docker Desktop avant de modifier daemon.json, puis redémarrez l'application. Sinon, utilisez l'interface utilisateur pour les paramètres pris en charge.

Conclusion

L'architecture de Docker Desktop est un système en couches : une VM légère, un moteur Docker, une CLI et de nombreux services de support. Comprendre ces couches transforme une boîte noire en un outil gérable. En vérifiant systématiquement chaque composant avec des commandes comme docker version, docker info et docker system df, vous pouvez détecter les problèmes tôt et les résoudre en toute confiance.

Pour tirer le meilleur parti de Docker Desktop, suivez un chemin de configuration sûr : changez un paramètre à la fois, vérifiez avec une commande concrète et gardez un plan de retour en arrière. Utilisez la liste de contrôle des opérations pour maintenir votre environnement sain et attribuez clairement la responsabilité des tâches de maintenance. Évitez les pièges courants en utilisant des volumes nommés pour les données avec état, en nettoyant les objets inutilisés et en ne traitant pas Docker Desktop comme une plateforme de production.

Lorsque vous rencontrez un problème, commencez par observer l'état actuel, consultez les modes de défaillance décrits ici et appliquez la plus petite correction qui résout le problème. Documentez vos découvertes et mettez à jour votre liste de contrôle. Cette approche fera de Docker Desktop une base fiable pour votre flux de travail de développement.