Docker et Debian forment un duo sobre mais très efficace pour qui veut des conteneurs prévisibles, faciles à maintenir et intégrables à une infrastructure existante. L’objectif de ce guide pas à pas est simple : partir d’une Debian 12 ou 13 fraîchement installée et arriver à un moteur Docker opérationnel, contrôlable et utilisable en production légère ou en homelab sérieux.
Pas de script magique opaque, mais une installation maîtrisée, reproductible et documentée, qui permet de diagnostiquer chaque étape en cas de problème.
Le contexte typique ressemble souvent à celui d’une PME industrielle ou d’un intégrateur IoT : une ou deux machines Debian bien lockées, parfois un Raspberry Pi sous Debian pour la passerelle terrain, et la volonté de déployer quelques services clés sans se lancer dans un cluster Kubernetes complet. Dans ce décor, Docker sert autant à isoler un broker MQTT qu’à héberger un portail interne ou un outil de supervision.
Encore faut-il que le socle soit propre : bon dépôt, clé GPG, services Systemd bien configurés et vérifications post-installation systématiques. Tout le reste en dépend.
En bref
- Debian 12 et Debian 13 offrent un socle très stable pour Docker, adapté aux serveurs, aux passerelles IoT et aux homelabs.
- L’installation recommandée passe par le dépôt officiel Docker, la clé GPG dédiée et les paquets docker-ce, containerd, buildx et Compose.
- Un contrôle précis via systemctl, docker version et docker run hello-world évite les mauvaises surprises en production.
- Les commandes de base (ps, logs, rm, build) constituent une trousse minimale pour exploiter les conteneurs sans s’y perdre.
- Pour les équipes qui montent en charge, Portainer, Rancher, Kubernetes, Grafana et Loki transforment une Debian bien tenue en plateforme de virtualisation applicative sérieuse.
Installer Docker sur Debian 12 et 13 depuis le dépôt officiel, étape par étape
Sur Debian, Docker s’installe vite, à condition de respecter une séquence précise. Cette séquence repose sur quelques choix assumés : passer par le dépôt officiel Docker plutôt que par celui de Debian, bannir apt-key au profit d’un trousseau dans /etc/apt/keyrings, installer aussi bien Docker Engine que les extensions Buildx et Compose.
Cette approche évite les mélanges de versions et les comportements étranges sur le long terme.
Le scénario de référence sera celui d’une machine Debian 12 Bookworm ou Debian 13 Trixie, accessible en SSH, avec des droits sudo. Beaucoup d’équipes déploient ce socle sur des VPS ou de petites machines physiques recyclées. Les prérequis sont modestes : quelques centaines de mégaoctets de RAM disponible, un stockage raisonnable sur /var, et une connexion réseau correcte vers Internet pour récupérer les images.
Première étape, ne pas bâcler la mise à jour du système. Une simple commande du type sudo apt update && sudo apt upgrade -y aligne l’index des paquets et applique les derniers correctifs de sécurité. C’est la ligne que certains administrateurs sautent pour « aller plus vite », et qui finit en conflit de dépendances le jour où l’on tente de mettre à niveau Docker. Une Debian entretenue, c’est moins de surprises et des reproductions de bug plus fiables.
Viennent ensuite les dépendances utiles : ca-certificates pour la vérification TLS, curl pour récupérer les fichiers distants, parfois gnupg et un paquet de type lsb-release ou la lecture de /etc/os-release pour identifier clairement la version. L’installation se résume souvent à un sudo apt install ca-certificates curl gnupg, mais ce raccourci cache un point de vue important : sécuriser le chemin d’accès au dépôt avant de se préoccuper de Docker lui-même.
Une fois les briques de base en place, la création du répertoire des clés avec sudo install -m 0755 -d /etc/apt/keyrings clarifie la situation. Plutôt que d’empiler les clés GPG dans un coin obscur, elles restent rangées dans un répertoire dédié, avec des droits corrects. Le téléchargement de la clé Docker se fait ensuite via curl, avec un flux directement converti en fichier binaire GPG grâce à gpg –dearmor ou, selon la méthode choisie, stocké en .asc puis rendu lisible via chmod. Le but reste identique : permettre à apt de vérifier chaque paquet Docker.
L’ajout du dépôt Docker s’effectue avec une commande echo/tee qui écrit une ligne deb dans /etc/apt/sources.list.d/docker.list. L’utilisation de $(dpkg –print-architecture) et de $(. /etc/os-release && echo « $VERSION_CODENAME ») évite de durcir la configuration sur amd64/bookworm et garde la main sur la compatibilité avec Debian 13. Pour un parc hétérogène, cette automatisation réduit les erreurs de copier-coller et rend les scripts d’installation plus robustes.
Une fois le dépôt en place, un sudo apt update fait apparaître les paquets docker-ce, docker-ce-cli, containerd.io mais aussi les plugins docker-buildx-plugin et docker-compose-plugin. C’est ici qu’apparaît une première prise de position : mieux vaut installer d’emblée ces extensions plutôt que de bricoler un binaire docker-compose téléchargé à part, qui vieillira mal. Une ligne d’installation complète ressemble à ceci :
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Certains environnements exigent des versions givées pour des raisons de qualification logicielle. Dans ce cas, la combinaison apt-cache madison docker-ce, suivie de l’installation en fixant une variable VERSION_STRING, reste une solution saine. On garde Docker dans le système de paquets, sans basculer dans un mode d’installation exotique qui rendra les audits plus compliqués.
Une fois l’installation terminée, Docker s’enregistre comme service Systemd. La migration de Debian 11 à Debian 12 a d’ailleurs rappelé à certains administrateurs que multiplier les overrides à la main dans /etc/systemd/system sans documentation claire finit par se payer. Quand on part sur Debian 13, autant profiter de ce retour d’expérience et noter noir sur blanc chaque modification structurelle.
Configuration post-installation de Docker sur Debian : service, groupe et vérifications
Une fois les paquets en place, le moteur Docker doit être démarré et contrôlé proprement. La commande sudo systemctl start docker lance le service, pendant que sudo systemctl enable docker l’inscrit pour un démarrage automatique à chaque reboot. Sur un serveur ou une passerelle IoT, ne pas activer ce démarrage automatique revient à parier sur le fait que personne n’oubliera de le lancer après une coupure électrique. Mauvais pari.
La commande sudo systemctl status docker permet de vérifier l’état réel du service : active (running), erreurs de configuration, problèmes au niveau de containerd, tout y passe. Beaucoup d’incidents sont déjà visibles ici, notamment quand une ancienne version de Docker traîne ou que le noyau ne supporte pas certains modules nécessaires au stockage en OverlayFS.
Deuxième vérification, la sortie de docker version. On y lit côté client la version de la CLI, côté serveur la version du démon. Quand ces deux valeurs ne correspondent plus du tout, c’est souvent le signe d’une mise à jour incomplète ou d’un client Docker installé en parallèle via un autre canal. Sur une Debian bien tenue, les deux valeurs restent alignées sur une branche stable unique issue du dépôt officiel.
Vient ensuite la question des droits. Travailler en root pour chaque commande docker n’est ni confortable ni souhaitable sur la durée. La création du groupe docker suivie d’un sudo usermod -aG docker nom_utilisateur permet d’exécuter docker sans sudo, après une reconnexion de la session. Ce choix appelle cependant un arbitrage de sécurité : intégrer un utilisateur dans ce groupe lui donne un pouvoir très proche de root, puisqu’il peut monter des volumes sensibles ou manipuler le réseau de l’hôte. Sur une machine partagée, ce groupe doit rester restreint.
Pour refermer ce premier volet, un test simple mais structurant reste indispensable : docker run hello-world. Cette commande télécharge une petite image officielle et exécute un conteneur qui affiche un message de confirmation. En quelques secondes, on valide la chaîne complète : résolution DNS, accès au registre public, stockage des couches d’images dans /var/lib/docker, création de réseau par défaut, exécution du binaire dans le conteneur. Si quelque chose bloque, le message d’erreur et les logs indiquent où creuser.
Sur un réseau d’entreprise verrouillé, le premier frein vient souvent du proxy HTTP. Docker n’est pas le seul concerné, mais il en paye vite le prix : les images ne se téléchargent pas, les timeouts se multiplient. Configurer un fichier type /etc/systemd/system/docker.service.d/proxy.conf, avec les variables d’environnement HTTP_PROXY, HTTPS_PROXY et NO_PROXY, puis recharger Systemd résout souvent l’affaire. Ce détail de configuration fait gagner des heures quand il est anticipé.
Ce socle maîtrisé ouvre ensuite la porte à un autre sujet clé : l’usage quotidien des conteneurs, la manière de les lister, les arrêter, nettoyer les images, construire des artefacts reproductibles. C’est là que commence vraiment le travail, au-delà de l’installation initiale.
Commandes Docker essentielles sur Debian pour gérer les conteneurs au quotidien
Une Debian bien installée avec Docker qui tourne ne sert pas à grand-chose si les équipes restent hésitantes devant la ligne de commande. Sur le terrain, la différence entre un homelab utile et un serveur vite abandonné se joue souvent sur cinq ou six commandes bien maîtrisées. L’objectif n’est pas de tout connaître, mais d’être autonome sur le cycle de vie d’un conteneur classique.
Le réflexe de base consiste à inspecter l’existant. docker ps liste les conteneurs actifs, avec leur nom, leur image, le port exposé. Ajouter l’option -a affiche aussi les conteneurs stoppés, ceux qui ont planté, et parfois quelques reliquats de tests qui encombrent le système. Sur une Debian utilisée comme banc d’essai, le premier ménage du lundi matin passe par là.
Pour arrêter un conteneur qui tourne, docker stop nom_ou_id envoie un signal d’arrêt propre. Si le processus ignore ce signal, un docker kill reste possible, mais il faut l’utiliser avec parcimonie. Effacer ensuite le conteneur avec docker rm évite d’empiler les vestiges. De nombreux systèmes se retrouvent avec des dizaines de conteneurs sortis avec statut 0, juste parce que personne n’a pris le temps de les enlever.
Les images occupent rapidement de la place, surtout lorsque l’on multiplie les tests. docker images affiche l’ensemble des images locales et leur taille. Supprimer une image non utilisée se fait avec docker rmi, à condition qu’aucun conteneur encore présent ne s’y réfère. Les équipes qui négligent cette étape finissent avec un /var saturé sans comprendre pourquoi. Sur Debian, ajouter un peu de surveillance disque via les outils habituels (df, du, ou un petit tableau Grafana) complète utilement ces commandes.
Construire une image locale, reproductible, commence avec un Dockerfile propre et une commande du type docker build -t service-iot:1.0 .. La notation nom:tag évite d’empiler des latest peu explicites. Derrière cette commande, la mécanique des couches d’images empilées permet de reconstruire rapidement après de petits changements, ce qui compte beaucoup sur des liaisons réseau modestes. Une fois satisfaite, l’équipe pousse l’image vers un registre privé, puis la déploie indifféremment sur Debian, Ubuntu ou un autre hôte compatible OCI.
Pour diagnostiquer un comportement étrange ou suivre un conteneur en production, docker logs -f nom_conteneur reste l’outil de base. L’option -f suit les flux stdout/stderr en temps réel, ce qui reste précieux quand on essaye de comprendre une panne sporadique. Sur certaines installations, cette étape est relayée vers un stack de logs plus avancé, mais même dans ce cas, savoir revenir aux logs bruts permet de vérifier ce qui remonte vraiment.
Un exemple simple parlant dans le monde IoT consiste à déployer un broker MQTT comme Eclipse Mosquitto, via une commande du type :
docker run -d –name mqtt-broker -p 1883:1883 eclipse-mosquitto
En quelques secondes, une Debian 12 devient un point central de collecte. Une équipe peut ensuite brancher ses capteurs, vérifier les flux avec mosquitto_sub, et observer les logs du conteneur pour traquer les déconnexions. Ce type d’usage illustre bien l’intérêt de Docker pour prototyper sans saccager le système hôte.
Pour garder une vue synthétique de l’état des conteneurs et des réseaux, certains administrateurs ajoutent très tôt un tableau de bord léger comme Portainer. D’autres préfèrent rester exclusivement en CLI pendant un certain temps, pour ancrer les réflexes. Les deux approches se défendent, mais une conviction se dégage : sans une poignée de commandes maîtrisées, aucune interface graphique ne rattrapera un manque de compréhension de base.
Ce socle de gestion quotidienne prépare naturellement le terrain pour une montée en charge plus structurée : Compose pour les stacks multi-services, Portainer pour la visualisation, puis potentiellement une orchestration de niveau supérieur.
Tableau comparatif des approches d’installation Docker sur Debian
Pour clarifier les choix, le tableau ci-dessous compare trois méthodes courantes d’installation de Docker sur Debian 12 ou 13.
| Méthode | Source des paquets | Contrôle des versions | Usage recommandé |
|---|---|---|---|
| Dépôt officiel Docker (recommandé) | download.docker.com | Forte, avec apt-cache madison et VERSION_STRING | Serveurs, homelabs sérieux, environnements IoT en production |
| Dépôts Debian standard | mirrors Debian | Plus limité, versions parfois en retard | Tests rapides, environnements peu sensibles aux versions |
| Script get.docker.sh | Script automatisé Docker | Faible, beaucoup d’automatisme opaque | Prototypage ponctuel, machines jetables, pas de production |
Ce tableau illustre un choix net : pour un système qui doit tenir dans la durée, le dépôt officiel reste la meilleure option. Les scripts tout-en-un séduisent sur le moment, mais compliquent les audits et les mises à jour maîtrisées quelques mois plus tard.
Virtualisation légère, sécurité et bonnes pratiques de configuration sur Debian
Docker ne remplace pas la virtualisation classique façon hyperviseur, mais il s’y superpose pour proposer une isolation applicative plus fine. Sur une Debian 12 bien entretenue, cette isolation repose sur les cgroups, les namespaces et le système de fichiers en couches. Pour des équipes habituées à des VM monolithiques, ce changement de modèle surprend parfois : ici, on ne démarre pas un OS complet à chaque fois, on empile des processus isolés sur le même noyau.
Ce fonctionnement explique pourquoi la surface d’attaque ne disparaît pas, elle se déplace. Plusieurs acteurs de la cybersécurité OT le répètent : un conteneur mal configuré avec un volume monté sur /var/run/docker.sock ou sur des dossiers système sensibles devient très vite une passerelle vers l’hôte. Les retours sur des environnements industriels en attestent, et rejoignent des analyses plus globales sur la cybersécurité des systèmes OT.
Pour limiter les risques, quelques pratiques de base valent une check-list simple :
- Limiter les privilèges des conteneurs, éviter les options du type –privileged et les montages inutiles.
- Maintenir les images à jour, en reconstruisant régulièrement sur des bases Debian ou Alpine récentes.
- Isoler les réseaux Docker entre les services exposés à Internet et ceux qui ne devraient jamais quitter le LAN.
- Activer des scans d’images via un registre ou un outil de CI capable de détecter les CVE connues.
Sur une Debian utilisée comme passerelle IoT, l’enjeu est double : protéger l’infrastructure interne et ne pas transformer la machine en point d’entrée vers l’atelier. Plusieurs entreprises ont appris à leurs dépens qu’un dashboard exposé directement, sans reverse proxy ni authentification solide, attire inévitablement des scans automatisés.
Une astuce souvent négligée consiste à séparer clairement les volumes persistants des couches éphémères. Sur Debian, monter un volume explicite dans /srv ou /data pour stocker les données de production évite que /var/lib/docker concentre à la fois les images et les données métier. Le jour où l’on migre vers une autre machine, cette séparation rend les backups et restaurations bien plus simples.
La question du firewall n’est pas à négliger non plus. Docker crée ses propres règles iptables ou nftables, mais cela ne dispense pas de garder une politique réseau cohérente côté système. Sur Debian, un pare-feu bien réglé autour des ports 80/443 exposés par un reverse proxy et des ports internes réservés aux services de back-end reste une défense utile, surtout quand on héberge quelques outils d’administration sensibles.
Enfin, les logs. Docker fournit un flux brut par conteneur, mais beaucoup d’équipes préfèrent centraliser et structurer ces informations. Des stacks comme Grafana + Loki tournent très bien dans des conteneurs eux aussi, mais il faut rester vigilant : une pile de supervision ne doit pas devenir plus lourde, ni plus fragile, que les services qu’elle surveille. Sur une Debian 13 modeste, calibrer ces briques évite de consommer toute la RAM juste pour des métriques.
Tout cela ramène à une idée simple : Docker apporte une forme de virtualisation adaptée aux services et aux micro-applications, à condition d’être traité comme une couche à part entière de l’architecture, avec des règles, des backups, une gestion des droits. Prendre ce temps en amont évite de courir après des incidents en aval.
De Docker seul à une plateforme orchestrée sous Debian : Portainer, Rancher, Kubernetes
Une seule machine Debian avec quelques conteneurs rend déjà de fiers services, mais de nombreuses équipes finissent par vouloir aller plus loin. C’est souvent là que les questions d’orchestration surgissent : comment mettre à jour sans coupure, répartir la charge, gérer plusieurs nœuds, centraliser les logs et la surveillance. Docker ne couvre pas tout cela en natif, même avec Compose, il faut alors s’appuyer sur des outils complémentaires.
Portainer fait partie des briques qui arrivent en premier. Déployé lui-même sous forme de conteneur, il offre un tableau de bord visuel qui recense images, volumes, réseaux, stacks Compose. Sur Debian 12 ou 13, un déploiement simple permet à une équipe peu à l’aise avec la ligne de commande de comprendre visuellement comment les services s’imbriquent. Certains administrateurs gardent tout de même les commandes CLI comme référence, ce qui évite d’être démuni en cas de bug de l’interface.
Quand on commence à aligner plusieurs nœuds Debian, parfois mélangés avec des hôtes Ubuntu, la discussion se tourne vers Kubernetes. Rancher joue ici le rôle de chef d’orchestre : il propose un installateur qui fédère ces nœuds, déploie un cluster et met à disposition une interface centrale pour gérer namespaces, workloads et politiques réseau. Le fait de pouvoir intégrer aussi des distributions comme MicroK8s donne une marge de manœuvre intéressante pour les homelabs qui veulent coller aux pratiques des grands comptes sans se ruiner.
Ce saut de Docker simple à une plateforme orchestrée implique un changement de culture. Au lieu d’un docker run isolé, on raisonne en déploiements, en services, en ingress, en secrets. Sur Debian, cela suppose aussi d’accepter que le noyau, les paramètres réseau, les limites de ressources soient pensés pour un cluster, pas seulement pour un serveur mono-rôle. Certaines entreprises ont découvert à cette occasion que leurs anciennes habitudes sysadmin (scripts bricolés, paquets hors dépôts, droits larges) ne passaient plus.
La question de la signature d’images revient aussi sur le devant de la scène. Des acteurs comme Red Hat avec Quay, ou des registres publics type GitHub Container Registry, ont popularisé des approches où chaque couche d’image est signée et vérifiée dans le pipeline CI/CD. Sur Debian, cela se traduit par des runners qui construisent, signent et poussent les images, puis des nœuds d’exécution qui refusent ce qui n’est pas validé. L’époque où l’on tirait n’importe quelle image « trouvée sur Internet » depuis un serveur de production tire clairement à sa fin.
Pour la supervision, beaucoup d’architectures convergent vers des couples Grafana + Prometheus pour les métriques, et Loki pour les logs. Ces briques tournent très bien en conteneurs orchestrés. Une Debian correctement dimensionnée, avec du stockage adapté, devient alors une brique d’un système de supervision temps réel capable de suivre aussi bien des microservices web que des passerelles IoT dans un atelier.
Il existe pourtant un piège classique : vouloir tout basculer d’un coup dans cet univers orchestré sans clarifier les objectifs. Pour un petit environnement, Docker + Compose bien utilisés couvrent déjà 80 % des besoins. Réserver Kubernetes et Rancher aux cas où la scalabilité, la haute disponibilité ou des contraintes fortes de multi-tenant sont réellement au rendez-vous évite beaucoup de complexité inutile.
Dans cette montée en gamme, Debian garde un rôle central. Sa stabilité rassure pour des déploiements longs, sa communauté offre des retours solides, et sa compatibilité avec la plupart des stacks open source de virtualisation applicative en fait une base logique pour qui ne veut pas être enfermé dans une solution propriétaire.
Cas d’usage concrets : IoT, homelab, environnements de test et intégration avec d’autres outils
Tout cela reste assez théorique tant qu’on n’ancre pas Docker et Debian dans des situations concrètes. Une PME qui déploie une dizaine de passerelles sur le terrain, un bureau d’étude qui veut un environnement de test reproductible, un développeur qui monte un homelab pour expérimenter des automatismes domestiques ou industriels, tous rencontrent des besoins proches : isoler, versionner, redéployer sans douleur.
Sur une passerelle IoT, Debian 12 ou 13 installée sur un petit PC industriel sert souvent de socle à un ensemble cohérent de services : un broker MQTT, un serveur Node-RED, une base de données légère type InfluxDB, un agent de supervision. Docker permet d’assembler ces pièces sans polluer le système. En cas de mise à jour ratée d’un composant, on revient à une version précédente du conteneur sans réinstaller toute la machine.
Dans un homelab, l’installation de Docker sur Debian vient souvent après d’autres expérimentations, par exemple une machine virtuelle macOS sous VMware pour des besoins spécifiques ou quelques VM Windows pour des tests d’interopérabilité. L’avantage de Docker apparaît alors clairement : démarrage très rapide des services, faible consommation de ressources par rapport à des VM complètes, facilité de mise à jour par remplacement d’image.
Les environnements de test y gagnent aussi. On peut imaginer une équipe qui développe un petit agent de collecte de données, intégré plus tard dans des flux d’automatisation inspirés de ce que l’on fait avec des agents IA sur des plateformes type n8n, comme décrit dans certains tutoriels spécialisés. Déployer rapidement cet agent dans un conteneur docker, sur une Debian dédiée, permet de mesurer les comportements sans perturber le reste de l’infrastructure.
Les pipelines d’intégration continue s’intègrent bien à cette logique. Un commit déclenche la construction d’une image Docker, l’exécution de tests, puis le déploiement sur un environnement Debian de staging. Si les tests passent, la même image migre vers la production. Cette reproductibilité limite les écarts entre les machines et simplifie la chasse aux bugs « qui n’apparaissent que sur le serveur ». C’est encore plus vrai quand les tests incluent des scénarios réseau, des charges simulées, des coupures contrôlées.
Pour finir, un mot sur la pédagogie. Dans les écoles d’ingénieurs et les IUT, Debian + Docker serre de plus en plus de base aux cours de systèmes, de réseaux et de développement. Les étudiants peuvent lancer des services variés, casser des choses, reconstruire, sans avoir besoin de privilèges absolus sur les machines physiques. Ce terrain de jeu contrôlé évite que chacun installe des stacks complètes et parfois douteuses en root, puis laisse derrière lui un système difficile à remettre d’équerre.
Que ce soit en production légère, en homelab ou en formation, la combinaison de Debian 12 ou 13 avec Docker conserve donc une cohérence forte : prévisibilité, documentation abondante, outils de supervision matures. Le tout repose cependant sur un point clé : traiter Docker non comme une mode, mais comme un composant à part entière de l’architecture, avec ses propres règles, ses sauvegardes et ses limites connues.
Faut-il utiliser le script get.docker.sh pour installer Docker sur Debian 12 ou 13 ?
Le script get.docker.sh rend l’installation très rapide, mais il automatise beaucoup de choix sans transparence. Pour des environnements de production, de homelab long terme ou des passerelles IoT critiques, mieux vaut passer par le dépôt officiel Docker avec une installation manuelle. On garde ainsi le contrôle sur les versions, la configuration des dépôts et l’audit des changements.
Quelle différence entre Docker sur Debian 12 et Docker sur Debian 13 ?
Sur le plan fonctionnel, Docker Engine et ses composants se comportent de façon similaire sur Debian 12 et Debian 13. La différence se situe surtout au niveau du noyau, des versions des bibliothèques système et de la durée de support. Debian 13 apporte des versions plus récentes, parfois utiles pour certaines stacks, mais la méthode d’installation et les commandes restent quasiment identiques.
Comment vérifier régulièrement que Docker est à jour sur un serveur Debian ?
Une fois le dépôt Docker configuré, un simple sudo apt update suivi de apt list –upgradable permet de voir si de nouvelles versions sont disponibles. Pour mettre à jour, sudo apt upgrade applique les changements, puis un redémarrage du service via sudo systemctl restart docker permet de prendre en compte la nouvelle version. Il est recommandé de tester les mises à jour d’abord sur un environnement de préproduction.
Pourquoi ajouter l’utilisateur au groupe docker plutôt que d’utiliser sudo à chaque commande ?
Ajouter l’utilisateur au groupe docker améliore le confort au quotidien, surtout pour les développeurs qui enchaînent les commandes. En revanche, ce groupe confère quasiment des droits d’administration sur la machine, car un utilisateur peut monter des volumes sensibles ou manipuler le réseau. Sur une machine partagée, il peut être plus prudent de garder sudo obligatoire et de restreindre l’accès au groupe docker.
Docker remplace-t-il complètement les machines virtuelles sur Debian ?
Docker ne remplace pas totalement les machines virtuelles. Il offre une virtualisation légère des applications, qui convient bien aux microservices, aux passerelles IoT ou aux environnements de test. Les VM gardent leur intérêt pour isoler des systèmes d’exploitation différents, exécuter des logiciels très liés au noyau ou respecter certaines exigences de conformité. Dans beaucoup d’architectures, Debian héberge d’ailleurs à la fois des VM et des conteneurs, chacun pour son rôle.