Installer Docker sur Linux demande surtout de faire les bons choix dès le départ: moteur seul pour un serveur, environnement complet pour un poste de dev, ou mode rootless quand la réduction des privilèges prime. Dans un contexte DevOps, cette base conditionne la suite des opérations, des images de conteneurs aux pipelines CI/CD. Je vais donc aller droit au but: méthode recommandée, préparation de la machine, vérification réelle du service et erreurs qui font perdre du temps.
Les points essentiels à retenir avant de commencer
- La voie la plus propre reste le dépôt officiel, pas les paquets communautaires fournis par la distribution.
- Sur un serveur ou un runner CI, je privilégie Docker Engine; sur un poste local, Docker Desktop peut convenir si tu acceptes ses contraintes.
- Après l’installation, teste toujours docker version, docker compose version et docker run hello-world.
- Ajouter ton utilisateur au groupe docker évite `sudo`, mais ce groupe donne un accès proche du niveau root.
- Le mode rootless est intéressant quand la sécurité du poste ou du serveur compte plus que la simplicité absolue.
Choisir la bonne variante selon ton usage
Avant même de taper une commande, je distingue trois cas. Cette décision évite de réinstaller plus tard parce que le besoin réel n’était pas le bon. La documentation officielle Docker recommande clairement de passer par les dépôts officiels pour garder les mises à jour cohérentes, et je suis aligné avec cette approche dans la plupart des environnements professionnels.
| Contexte | Ce que je choisis | Pourquoi |
|---|---|---|
| Poste de développement personnel | Docker Engine ou Docker Desktop | Tu gagnes du confort avec Desktop, mais Engine suffit souvent si tu veux rester léger. |
| Serveur de production ou runner CI | Docker Engine via le dépôt officiel | Moins d’outils superflus, mises à jour plus propres, comportement plus prévisible. |
| Machine partagée ou surface d’attaque réduite | Docker en mode rootless | Le démon et les conteneurs tournent sans privilèges root, ce qui réduit l’impact d’un incident. |
| Installation ponctuelle pour test | Script de commodité | Rapide, mais je le réserve aux tests et au dev, pas à une machine durable. |
Pour Docker Desktop sur Linux, garde aussi un point en tête: Docker rappelle qu’un usage commercial à grande échelle est soumis à abonnement. Sur un serveur, je n’hésite donc pas longtemps: Engine reste le choix le plus simple et le plus net. Une fois cette décision posée, la préparation du système devient beaucoup plus directe.
Préparer la machine avant l’installation
Le problème n’est pas Docker lui-même, mais les résidus d’anciennes installations. Quand une machine a déjà servi à tester plusieurs distributions de paquets, les conflits arrivent vite. Je commence donc toujours par vérifier la version de la distribution, l’architecture et les paquets déjà présents.
- Vérifie la distribution avec `cat /etc/os-release` et l’architecture avec `uname -m`.
- Assure-toi d’être sur une version encore maintenue de ta distribution.
- Supprime les paquets Docker non officiels si la machine en a déjà vu passer.
- Garde en tête que les données sous `/var/lib/docker/` ne sont pas supprimées automatiquement lors d’une désinstallation.
Sur Debian et Ubuntu, les paquets qui posent le plus souvent problème sont `docker.io`, `docker-compose`, `docker-compose-v2`, `docker-doc` et `podman-docker`, ainsi que d’anciens composants `containerd` ou `runc`. Sur Fedora, la liste de nettoyage est un peu différente, mais la logique reste identique: on enlève ce qui peut entrer en collision avec la version officielle.
sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc | cut -f1)sudo dnf remove docker \
docker-client \
docker-client-latest \
docker-common \
docker-latest \
docker-latest-logrotate \
docker-logrotate \
docker-selinux \
docker-engine-selinux \
docker-engineSi tu pars d’une machine propre, ce passage est rapide. Si tu hérites d’un poste bricolé, il peut t’épargner une bonne demi-heure de diagnostic. Une fois l’environnement assaini, on peut passer à l’installation proprement dite.
Installer Docker depuis le dépôt officiel
Je limite ici les exemples aux familles les plus courantes en DevOps: Debian, Ubuntu et Fedora. La logique est la même sur les autres distributions maintenues, mais les détails du dépôt changent. Je n’inclus pas d’adresse brute ici, parce que l’URL dépend de la distribution et de la version, mais la méthode reste identique: clé GPG officielle, dépôt officiel, puis installation des paquets.
Sur Debian et Ubuntu
Ajoute le dépôt officiel correspondant à ta version, puis installe les paquets suivants:
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-pluginLe point important ici, c’est le plugin Compose. Il fournit `docker compose`, qui remplace progressivement l’ancien binaire `docker-compose`. Je préfère cette approche parce qu’elle garde tout le cycle de mise à jour dans le gestionnaire de paquets et évite les écarts de version.
Lire aussi : Maîtriser sudoers - Écrire des règles fiables en DevOps
Sur Fedora
Ajoute d’abord le dépôt Docker pour Fedora, puis lance l’installation:
sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now dockerSur Fedora, le dépôt officiel est aussi le meilleur compromis entre simplicité et maintenance. Docker crée le groupe `docker` à l’installation, mais n’y ajoute aucun utilisateur automatiquement, ce qui t’oblige à choisir ensuite entre `sudo`, groupe dédié ou rootless. Cette transition nous amène justement à la partie vérification.
Vérifier que le moteur répond correctement
Une installation réussie ne se juge pas à l’absence d’erreur pendant `apt` ou `dnf`. Je vérifie toujours que le démon tourne, que le client voit bien le serveur, et que Compose est disponible. C’est cette séquence qui te dit si la machine est réellement prête pour des conteneurs.
sudo systemctl status docker
docker version
docker compose version
docker run hello-world`systemctl status docker` confirme que le service est actif. `docker version` doit afficher à la fois le client et le serveur. `docker compose version` valide l’installation du plugin Compose. Enfin, `docker run hello-world` télécharge une petite image de test, la lance, puis affiche un message de confirmation: c’est le test le plus simple pour valider le chemin complet entre le client, le démon, le réseau et le runtime.
Sur Debian et Ubuntu, le service démarre généralement au boot par défaut. Sur d’autres distributions, je préfère activer explicitement le démarrage automatique pour éviter de découvrir le problème au moment où un pipeline doit repartir après un reboot. Si la commande `docker run hello-world` échoue alors que le service est actif, le souci vient souvent d’un conflit de paquets, d’un pare-feu mal aligné ou d’un groupe utilisateur mal configuré.
Sécuriser l’usage quotidien sans compliquer la vie
Le point le plus mal compris chez les débutants, c’est le groupe `docker`. Beaucoup le voient comme un simple raccourci pour éviter `sudo`, alors qu’il donne en pratique un accès très puissant à la machine. Je l’utilise, oui, mais en connaissance de cause.
sudo groupadd docker
sudo usermod -aG docker $USER
newgrp dockerAprès l’ajout au groupe, il faut se déconnecter puis se reconnecter, ou lancer `newgrp docker` pour que la session prenne bien en compte le changement. Si tu as déjà utilisé `sudo` pour exécuter des commandes Docker auparavant, il est possible que le répertoire `~/.docker/` ait des permissions incohérentes; dans ce cas, il faut le corriger plutôt que forcer la main à chaque commande.
Quand la priorité est la réduction des privilèges, je regarde le mode rootless. Docker précise que ce mode permet d’exécuter le démon et les conteneurs sans privilèges root, ce qui réduit la surface de risque. Le compromis existe pourtant: selon les cas, la mise en réseau peut être un peu moins directe et certaines habitudes d’administration ne se transposent pas à l’identique.Pour un serveur qui tourne longtemps, je pense aussi à la rotation des logs. Le driver `json-file` par défaut peut gonfler vite si on laisse les conteneurs écrire sans contrôle. Dans un environnement de production, ce détail finit par compter autant que l’installation elle-même. Une fois ces bases posées, il reste surtout à éviter les erreurs répétées au moment du déploiement réel.
Ce que je garde en tête avant de le mettre en production sur Linux
La règle la plus utile est simple: je n’utilise pas le script de commodité en production, je garde le dépôt officiel, et je documente la version installée. Sur un serveur, le but n’est pas d’avoir Docker “qui marche”, mais un runtime que l’on sait maintenir, dépanner et mettre à jour sans surprise.
Je fais aussi attention à ne pas mélanger les paquets de la distribution avec ceux de Docker CE. C’est l’une des causes les plus fréquentes d’installations à moitié cassées. Si l’environnement sert à un pipeline CI/CD ou à un projet backend partagé, je teste toujours trois choses avant de considérer la machine prête: le démarrage du service, `docker compose version` et un conteneur de test comme `hello-world`.
En pratique, si tu veux une base saine, retiens ceci: dépôt officiel, vérification du service, gestion propre des droits, puis seulement ensuite automatisation. C’est ce déroulé qui évite les installations fragiles et qui donne à Docker une place cohérente dans un poste DevOps ou sur un serveur Linux.
