Installer Docker sur Debian 12 et Debian 13 peut sembler une formalité technique, mais c’est souvent le moment où une architecture tient ou se casse. Ce texte propose une méthode détaillée, reposant sur le dépôt officiel Docker et la gestion paquets via apt, pour transformer une machine Debian fraîche en plateforme de containers fiable. Le contexte type couvre aussi bien une PME bordelaise qui déploie des passerelles IoT que le homelab d’un développeur front qui veut isoler des services sans monter un cluster Kubernetes. On y trouve les commandes à coller, mais surtout la logique derrière chaque étape : pourquoi stocker la clé GPG dans /etc/apt/keyrings, pourquoi préférer le plugin docker-compose plutôt qu’un binaire isolé, et quels contrôles effectuer après l’installation pour éviter les interruptions imprévues.
Les recommandations tiennent compte des particularités de Debian 12 (Bookworm) et Debian 13 (Trixie), des contraintes réseau (proxy, firewall) et des usages réels en 2026, quand la stabilité et la reproductibilité priment pour des déploiements industriels ou pédagogiques. Le ton est direct, didactique et concret : pas de script opaque, mais une séquence documentée, reproductible et vérifiable.
En bref :
- Préférence claire : utiliser le dépôt officiel Docker pour contrôler les versions via apt.
- Paquets recommandés : docker-ce, docker-ce-cli, containerd.io, docker-buildx-plugin, docker-compose-plugin.
- Vérifications essentielles : systemctl status docker, docker version, docker run hello-world.
- Sécurité pratique : limiter les volumes montés, éviter –privileged, séparer /var/lib/docker et /srv.
- Évolution possible : Portainer pour visibilité, Rancher ou Kubernetes si besoin réel d’orchestration.
Pourquoi installer Docker sur Debian 12 et 13 : contexte, choix et prises de position
Dans un atelier logiciel, le choix de la distribution n’est pas anodin. Debian 12 et Debian 13 offrent un socle long terme et bien connu des administrateurs, avec des noyaux et des bibliothèques testés.
Installer Docker sur ces versions n’est pas seulement une question de commandes : c’est un arbitrage entre stabilité, maintenance et facilité d’audit.
Prise de position n°1 : préférer le dépôt officiel Docker plutôt que le paquet docker.io des dépôts Debian. Sur le long terme, le dépôt officiel permet de contrôler les versions via apt-cache madison et d’éviter des écarts gênants entre le démon et la CLI.
Prise de position n°2 : refuser get.docker.sh pour les environnements de production ou de préproduction. Le script est pratique pour prototypage, mais il automatise des choix sans transparence, ce qui complique les audits.
Prise de position n°3 : installer d’emblée les extensions buildx et compose via les plugins apt. Ces plugins s’intègrent dans la gestion paquets et évitent des binaires isolés qui vieillissent mal.
Cas d’usage concret
Une PME bordelaise déploie des passerelles IoT sur le terrain. Chaque passerelle tourne sur Debian et doit héberger un broker MQTT, un agent de supervision et parfois un container de transformée de données. Docker permet d’isoler ces composants et de revenir en arrière rapidement si une mise à jour foire.
La même logique s’applique pour un homelab de dev front : un service WordPress, un outil de preview et un agent CI peuvent tourner sur la même machine sans se marcher sur les pieds.
Le fil conducteur ici sera l’exemple d’« AtelierTech », une PME fictive qui passe progressivement d’un usage docker run isolé vers des stacks Compose, puis vers Portainer quand la visibilité devient critique. Ce parcours illustre qu’on n’a pas toujours besoin d’une orchestration lourde dès le départ.
En synthèse : Debian 12 et 13 sont de bons socles pour Docker si on accepte la discipline paquets/clé GPG/contrôles post-installation. Cette approche réduit les surprises et facilite les audits.
Insight : choisir le dépôt officiel et garder le contrôle apt évite des incohérences qui apparaissent souvent après plusieurs mises à jour.
Préparation et installation via apt sur Debian 12 et Debian 13 : méthode complète pas à pas
Pour que l’installation soit reproductible, suivre une séquence précise évite les erreurs. La machine est supposée accessible en SSH, avec un utilisateur sudo. Les prérequis sont modestes, mais une mise à jour initiale est non négociable.
Étape 1 : maintenir le système à jour. Exécute : sudo apt update && sudo apt upgrade -y. Sauter cette étape amène souvent des conflits de dépendances plus tard.
Étape 2 : installer les dépendances utiles : sudo apt install ca-certificates curl gnupg lsb-release -y. Ces paquets sécurisent la récupération des clés et aident à déterminer la variable VERSION_CODENAME automatiquement.
Étape 3 : préparer le trousseau de clés/apt. Crée le répertoire dédié : sudo install -m 0755 -d /etc/apt/keyrings. Cette organisation évite d’empiler les clés dans un fichier global.
Étape 4 : importer la clé GPG Docker et la rendre lisible pour apt :
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
Étape 5 : ajouter le dépôt officiel en s’appuyant sur l’architecture et le codename détectés automatiquement :
echo « deb [arch=$(dpkg –print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian $(. /etc/os-release && echo « $VERSION_CODENAME ») stable » | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
Étape 6 : mettre à jour l’index apt puis installer les paquets recommandés :
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y
Chaque paquet joue un rôle précis : docker-ce est le démon, docker-ce-cli la CLI, containerd.io le runtime bas niveau, buildx le builder multi-plateforme, compose le moteur de stacks. Installer tout cela via apt conserve la traçabilité des versions.
Tableau comparatif des approches d’installation
| Méthode | Source des paquets | Contrôle des versions | Usage recommandé |
|---|---|---|---|
| Dépôt officiel Docker | download.docker.com | Élevé via apt-cache madison | Serveurs, homelabs sérieux, IoT en production |
| Dépôts Debian (docker.io) | mirrors Debian | Limité, versions souvent plus anciennes | Tests rapides, environnements non critiques |
| Script get.docker.sh | Script automatisé | Faible, choix opaques | Prototypage, machines jetables |
Après l’installation, un sudo systemctl status docker permet de vérifier que le service est actif. Si des erreurs remontent, commencer par journalctl -u docker pour localiser le problème.
Insight : formater l’ajout des clés dans /etc/apt/keyrings et installer les plugins via apt simplifie les audits et la maintenance.
Configuration post-installation et vérifications essentielles sur Debian 12/13
Après l’installation, il faut démarrer, activer et vérifier. Ces contrôles évitent des surprises à la première mise à jour ou après un redémarrage inattendu.
Premières commandes : sudo systemctl start docker puis sudo systemctl enable docker pour assurer un démarrage automatique. Vérifier l’état avec sudo systemctl status docker.
La commande docker version donne deux lignes à lire attentivement : le client (CLI) et le serveur (daemon). Des écarts trop larges entre les versions indiquent une mise à jour partielle ou l’installation parallèle d’une CLI provenant d’un autre canal.
Pour éviter d’exécuter docker en root à chaque fois, la création du groupe docker et l’ajout de l’utilisateur sont pratiques :
sudo groupadd docker || true
sudo usermod -aG docker ton_utilisateur
Se reconnecter ou utiliser newgrp docker pour appliquer la modification. Attention toutefois : appartenir au groupe docker confère des capacités proches de root, car on peut monter des volumes sensibles. Sur une machine partagée, restreindre ce groupe.
Tests et diagnostics
Test classique : docker run hello-world. Cette commande vérifie l’accès au registre, le téléchargement d’images et l’exécution basique. Si ça échoue, vérifier le proxy HTTP/HTTPS et les variables d’environnement système.
Si le réseau impose un proxy, créer un fichier systemd pour Docker contenant HTTP_PROXY, HTTPS_PROXY et NO_PROXY, par exemple dans /etc/systemd/system/docker.service.d/proxy.conf, puis recharger systemd et redémarrer Docker.
Logs & stockage : observer les logs via docker logs -f nom_conteneur pour suivre l’exécution. Contrôler l’espace disque avec df -h et localiser l’usage Docker via du -sh /var/lib/docker/* si le stockage devient critique.
Sur des environnements d’entreprise, signer les images ou utiliser un registre privé qui scanne les CVE est recommandé. Mais pour un homelab, reconstruire régulièrement les images et éviter les snapshots “latest” suffisent souvent pour garder la propreté.
Insight : une série de vérifications simples (systemctl, docker version, hello-world) économise des heures de dépannage plus tard.
Sécurité, bonnes pratiques et montée en charge vers une plateforme orchestrée
Docker n’est pas une solution magique pour la sécurité. Il change la surface d’attaque, qui doit être traitée. Sur une Debian utilisée en production ou comme passerelle IoT, quelques règles simples réduisent significativement les risques.
Limiter les privilèges des conteneurs, éviter –privileged, et contrôler les montages de volumes. Un volume pointant vers /var/run/docker.sock donne un accès aux API Docker depuis le conteneur, ce qui peut compromettre l’hôte.
Isoler les réseaux Docker entre services exposés et services internes. Utiliser des réseaux user-defined et des politiques de firewall sur l’hôte permet d’empêcher des communications non souhaitées.
Scanner les images via des outils CI ou des registres qui remontent les CVE. Reconstruire des images sur des bases à jour et limiter les images « trouvées » publiquement évite d’introduire des composants vulnérables.
De Portainer à Kubernetes
Pour une visibilité rapide, Portainer apporte un tableau de bord qui facilite la découverte des images, volumes et réseaux. C’est un bon pas entre CLI pure et orchestrateur complet.
Quand plusieurs nœuds sont alignés, Rancher ou Kubernetes deviennent pertinents, mais il s’agit d’un changement de paradigme. On passe de containers isolés à des déploiements, des services, des ingress et des politiques réseau. Pour beaucoup de petites structures, Docker Compose couvre 80 % des besoins.
Conseil pratique : réserver Kubernetes aux cas où la scalabilité, la haute disponibilité ou le multi-tenant sont réellement nécessaires. Ne pas complexifier pour complexifier.
Insight : traiter Docker comme une couche à part entière de l’architecture impose règles de sauvegarde, scans d’images et séparation claire des données persistantes.
Faut-il utiliser get.docker.sh pour installer Docker sur Debian 12 ou 13 ?
Le script accélère l’installation, mais il automatise des choix sans transparence. Pour des environnements de production ou de long terme, préférer le dépôt officiel Docker et l’installation via apt afin de garder le contrôle sur les versions et les configurations.
Quelle est la différence entre installer Docker sur Debian 12 et Debian 13 ?
Fonctionnellement, le moteur Docker se comporte de la même façon. Les différences tiennent au noyau et aux bibliothèques systèmes : Debian 13 apporte des versions plus récentes qui peuvent améliorer la compatibilité avec certaines stacks, mais la méthode d’installation via apt reste identique.
Comment vérifier que Docker est à jour sur un serveur Debian ?
Après avoir configuré le dépôt Docker, exécuter sudo apt update puis apt list –upgradable pour voir les mises à jour. Appliquer sudo apt upgrade et redémarrer le service avec sudo systemctl restart docker après un test en préproduction.
Pourquoi ajouter l’utilisateur au groupe docker au lieu d’utiliser sudo à chaque commande ?
L’appartenance au groupe docker simplifie le quotidien en évitant le préfixe sudo, utile aux développeurs. Toutefois, ce groupe confère des droits proches de root. Sur une machine partagée, il est préférable de garder sudo obligatoire et de restreindre l’accès au groupe.
Docker peut-il remplacer les machines virtuelles sur Debian ?
Docker offre une virtualisation légère adaptée aux microservices et aux environnements de test, mais il ne remplace pas toujours une VM. Les VM restent nécessaires pour des besoins d’isolation complète d’un système d’exploitation ou pour des exigences de conformité.