Installer Docker sur un VPS Ubuntu 24.04/22.04 : la méthode officielle

Avant de commencer : un VPS KVM, une version d'Ubuntu supportée et un utilisateur sudo

Docker Engine n'embarque pas son propre noyau. Chaque conteneur partage le noyau de l'hôte et s'appuie sur les namespaces Linux, les cgroups et netfilter : le démon a donc besoin d'un VPS dont vous maîtrisez le noyau. C'est exactement ce qu'apporte un VPS KVM (virtualisation complète). Sur les offres basées sur conteneurs, en OpenVZ ou LXC, le noyau appartient à l'hébergeur et Docker refuse de démarrer, ou ne fonctionne que si l'hôte a activé l'imbrication. Vérifiez avant d'installer quoi que ce soit :

systemd-detect-virt                          # expect: kvm
. /etc/os-release && echo "$VERSION_CODENAME"   # noble (24.04) or jammy (22.04)
uname -m                                     # x86_64 or aarch64

Docker publie des paquets pour Ubuntu 24.04 LTS (noble) et 22.04 LTS (jammy) en 64 bits, sur x86_64 et arm64. Il vous faut aussi un utilisateur disposant des droits sudo ; les sections sur le groupe docker et le mode rootless supposent un compte ordinaire plutôt que root.

Installer Docker Engine depuis le dépôt apt officiel

Il existe quatre façons courantes d'installer Docker sur Ubuntu, et une seule correspond à la méthode documentée et supportée par Docker pour les serveurs :

Étape 1 : supprimer les paquets en conflit

Si l'image du VPS contient déjà le docker.io d'Ubuntu, un ancien docker-compose ou podman-docker, supprimez-les pour que les deux versions ne se disputent pas /usr/bin/docker. Cette boucle vient de la documentation Docker et reste inoffensive sur un système propre ; elle laisse /var/lib/docker intact :

for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do
  sudo apt-get remove $pkg
done

Étape 2 : ajouter la clé GPG et la source apt de Docker

La clé se place dans /etc/apt/keyrings/ et est référencée via signed-by=, ce qui la limite à ce seul dépôt au lieu de lui faire confiance globalement via l'apt-key obsolète. Le nom de code est lu depuis /etc/os-release, si bien que le même bloc fonctionne en 24.04 comme en 22.04 :

sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

Une erreur de signature sur ce dernier apt-get update signifie presque toujours que le fichier de clé est illisible ; relancez la ligne chmod.

Étape 3 : installer le moteur et ses plugins

sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

docker-ce est le démon, docker-ce-cli le client, containerd.io le runtime sous-jacent, et les deux plugins fournissent docker buildx et docker compose. Sur Ubuntu, le script de post-installation du paquet démarre immédiatement docker.service et l'active au démarrage.

Étape 4 : vérifier avec hello-world

sudo docker run hello-world
docker --version
sudo docker info | head -n 20

hello-world est le test définitif : le client parle au démon, le démon récupère une image minuscule depuis Docker Hub, crée un conteneur, l'exécute et renvoie sa sortie. Si vous voyez « Hello from Docker! », toutes les couches fonctionnent. Sur une installation saine en 24.04 ou 22.04, docker info indique Storage Driver: overlay2 et Cgroup Version: 2.

Utiliser Docker sans sudo : le groupe docker

Le démon écoute sur la socket Unix /var/run/docker.sock, dont le propriétaire est root:docker : les membres du groupe docker peuvent donc utiliser la CLI sans sudo :

sudo groupadd docker          # usually exists already; harmless if it does
sudo usermod -aG docker $USER
newgrp docker                 # or log out and back in
docker run hello-world

Mesurez bien ce que vous venez d'accorder. Quiconque atteint cette socket peut lancer docker run -v /:/host --privileged ... et lire ou réécrire n'importe quel fichier du VPS, ce qui rend l'appartenance au groupe docker équivalente à root, sans demande de mot de passe ni trace dans les logs sudo. Traitez-la exactement comme un accès sudo ; notre guide sur le changement d'utilisateur et l'escalade de privilèges sur Ubuntu explique pourquoi cette distinction compte sur une machine multi-utilisateurs.

Le plugin Docker Compose

Le paquet docker-compose-plugin fournit Compose v2 sous forme de sous-commande docker compose (avec une espace). L'ancien binaire Python docker-compose est en fin de vie et ne doit pas être installé à côté. Vérifiez la version, puis testez avec un compose.yaml minimal :

docker compose version

mkdir -p ~/web && cd ~/web
cat > compose.yaml <<'EOF'
services:
  web:
    image: nginx:alpine
    ports:
      - "127.0.0.1:8080:80"
    restart: unless-stopped
EOF

docker compose up -d
docker compose ps
curl -I http://127.0.0.1:8080
docker compose down

Deux détails sont délibérés : restart: unless-stopped relance le conteneur après un redémarrage, et le port est lié à 127.0.0.1 plutôt qu'à toutes les interfaces, pour les raisons expliquées dans la section pare-feu.

Mode rootless : un démon qui n'est pas root

Le mode rootless exécute le démon et les conteneurs dans un user namespace : une évasion de conteneur atterrit alors dans un compte non privilégié plutôt que sur root. C'est le bon choix quand plusieurs personnes partagent un VPS. Les prérequis sont les plages d'UID/GID subordonnés (Ubuntu les crée pour les utilisateurs normaux dans /etc/subuid et /etc/subgid), les outils uidmap, une session D-Bus utilisateur et les extras rootless de Docker :

sudo apt-get install -y uidmap dbus-user-session docker-ce-rootless-extras
grep "^$USER:" /etc/subuid /etc/subgid   # each should show a range of 65536 IDs

# optional: stop the system-wide daemon if you only want rootless
sudo systemctl disable --now docker.service docker.socket

dockerd-rootless-setuptool.sh install

L'outil d'installation crée une unité systemd propre à l'utilisateur et affiche les deux variables dont votre shell a besoin. Ajoutez-les à ~/.bashrc, puis faites démarrer le démon utilisateur au boot sans connexion :

export PATH=/usr/bin:$PATH
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

systemctl --user enable docker
sudo loginctl enable-linger $(whoami)

Le mode rootless a de vraies limites : les ports inférieurs à 1024 ne peuvent pas être publiés sauf à lancer sudo setcap cap_net_bind_service=ep $(which rootlesskit) puis à redémarrer le démon utilisateur, les réseaux overlay sont indisponibles, et les données vivent sous ~/.local/share/docker. Sur Ubuntu 24.04, AppArmor restreint les user namespaces non privilégiés ; les paquets deb fournissent le profil dont rootlesskit a besoin, mais une installation par binaire statique impose de l'ajouter à la main, comme décrit dans la documentation rootless.

Comportement au démarrage, stockage et rotation des logs

Deux choses distinctes déterminent si vos conteneurs tournent après un redémarrage : le démon doit être activé, et chaque conteneur doit porter une politique de redémarrage. Les paquets Ubuntu activent le service pour vous ; confirmez-le, et si les états de l'unité vous semblent obscurs, notre référence sur le listage des services avec systemctl détaille chaque colonne :

systemctl is-enabled docker.service containerd.service
sudo systemctl enable docker.service containerd.service   # only if the line above said disabled

Les conteneurs démarrés sans --restart restent éteints après un redémarrage ; utilisez --restart unless-stopped en ligne de commande ou restart: unless-stopped dans Compose pour tout ce qui est permanent.

Tout ce que Docker stocke (couches d'images, systèmes de fichiers de conteneurs, volumes, logs) se trouve sous /var/lib/docker, et sur un petit VPS c'est ce répertoire qui remplit le disque. Surveillez-le avec docker system df, récupérez les couches orphelines avec docker system prune, et lisez l'invite avant d'ajouter -a, qui supprime aussi toutes les images non utilisées par un conteneur en cours d'exécution. Si le VPS dispose d'un second disque, pointez data-root dessus dans /etc/docker/daemon.json avant de télécharger quoi que ce soit de volumineux.

Les logs méritent un avertissement spécifique. Le driver json-file par défaut écrit chaque ligne de la sortie standard des conteneurs dans /var/lib/docker/containers/<id>/<id>-json.log et n'effectue aucune rotation tant que vous ne la configurez pas. Un conteneur bavard peut avaler tout le disque en une semaine. Définissez des limites au niveau du démon dès le premier jour :

sudo tee /etc/docker/daemon.json > /dev/null <<'EOF'
{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" },
  "live-restore": true
}
EOF
sudo systemctl restart docker

Les options de log s'appliquent aux conteneurs créés après le redémarrage : recréez donc une fois ceux qui tournent en continu. live-restore permet au démon de redémarrer pour une mise à jour sans tuer les conteneurs actifs.

Docker et ufw : les ports publiés contournent votre pare-feu

C'est le point qui piège la plupart des gens sur un VPS public. Docker gère ses propres règles iptables : quand vous publiez un port avec -p 8080:80, le démon insère une règle DNAT dans la chaîne PREROUTING de la table nat et une règle d'acceptation dans FORWARD. Les règles d'ufw vivent dans INPUT, que le trafic forwardé ne traverse jamais. Donc ufw deny 8080 n'a aucun effet, et un conteneur de base de données publié sur 0.0.0.0:5432 est joignable depuis tout Internet alors qu'ufw annonce le port comme bloqué. Cherchez 0.0.0.0: dans la colonne PORTS de docker ps, ou lancez ss -tlnp ; notre guide sur la vérification des ports ouverts sous Linux montre comment lire cette sortie et confirmer l'exposition depuis l'extérieur.

Deux corrections propres, par ordre de préférence :

1. Liez les ports publiés à la boucle locale. -p 127.0.0.1:8080:80 garde le service accessible depuis le VPS uniquement, typiquement derrière un reverse proxy comme nginx ou Caddy que vous exposez délibérément. Les conteneurs qui ne dialoguent qu'entre eux n'ont besoin d'aucun -p.
2. Filtrez dans la chaîne DOCKER-USER. Docker évalue cette chaîne avant ses propres règles FORWARD et ne la réécrit jamais. Comme le DNAT a déjà eu lieu quand un paquet y arrive, faites correspondre le port d'origine avec conntrack :

sudo iptables -I DOCKER-USER -i eth0 ! -s 203.0.113.10 -p tcp \
  -m conntrack --ctorigdstport 8080 --ctdir ORIGINAL -j DROP

Remplacez eth0 par votre interface publique et 203.0.113.10 par l'adresse autorisée. Ces règles ne sont pas persistantes ; enregistrez-les avec le paquet iptables-persistent. Définir "iptables": false dans daemon.json casse le réseau des conteneurs d'une manière très difficile à déboguer : n'y touchez pas.

Désinstaller complètement Docker

Purgez d'abord les paquets, puis supprimez les répertoires de données, qu'apt laisse volontairement en place :

sudo apt-get purge -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras
sudo rm -rf /var/lib/docker /var/lib/containerd
sudo rm -f /etc/apt/sources.list.d/docker.list /etc/apt/keyrings/docker.asc
sudo apt-get autoremove -y

Pour une installation rootless, lancez d'abord dockerd-rootless-setuptool.sh uninstall en tant qu'utilisateur, puis supprimez ~/.local/share/docker.

Tout ceci suppose un serveur où vous êtes root, où vous contrôlez le noyau et où vous pouvez réécrire iptables sans demander la permission. S'il vous faut encore cette machine, le VPS Linux KVM avec accès root complet de rdp.monster est livré avec Ubuntu 24.04 ou 22.04, CPU et RAM dédiés, bande passante illimitée (fair-use), sans KYC, crypto acceptée, à partir de $8.99/mois, et il est livré environ 10 secondes après confirmation du paiement : vous pouvez donc lancer le test hello-world ci-dessus sur votre propre serveur juste après la commande.

Foire aux questions

Quelle version de Docker apt installe-t-il sur Ubuntu, et comment la mettre à jour ?

Le dépôt installe la dernière version stable de Docker Engine, et apt upgrade la maintient à jour.

Avec le dépôt apt de Docker configuré, apt-get install docker-ce récupère la version stable la plus récente disponible pour le nom de code de votre Ubuntu, et chaque sudo apt-get update && sudo apt-get upgrade ultérieur vous fait avancer. Lancez docker version pour voir les versions du client et du serveur. Pour figer une version précise, listez les candidates avec apt-cache madison docker-ce et installez docker-ce=<version> avec le docker-ce-cli correspondant, puis faites un apt-mark hold sur les deux paquets.

Pourquoi ai-je l'erreur « permission denied while trying to connect to the Docker daemon socket » ?

Votre utilisateur ne peut pas lire /var/run/docker.sock : rejoignez le groupe docker ou utilisez sudo.

La socket du démon appartient à root:docker, donc un simple utilisateur obtient permission denied. Préfixez vos commandes avec sudo, ou ajoutez-vous avec sudo usermod -aG docker $USER puis ouvrez une nouvelle session (ou lancez newgrp docker), car les changements de groupe ne s'appliquent qu'aux nouvelles sessions. Si l'erreur persiste, vérifiez votre appartenance avec groups, contrôlez que le démon tourne avec systemctl status docker, et assurez-vous que DOCKER_HOST ne pointe pas vers une socket rootless inexistante.

Faut-il installer Docker avec snap ou avec apt sur Ubuntu Server ?

Utilisez apt avec le dépôt de Docker ; le snap ajoute des contraintes de confinement sans aucun bénéfice sur un serveur.

Préférez apt depuis le dépôt officiel de Docker. Le snap est strictement confiné : il ne peut pas lire de fichiers hors de votre répertoire personnel sans connexions d'interfaces supplémentaires, utilise d'autres chemins pour daemon.json et les données, et son rythme de mise à jour est piloté par snapd plutôt que par vous. Ces particularités se manifestent par des permission denied mystérieux et des échecs de bind-mount. Les paquets apt suivent les conventions Ubuntu standard, s'intègrent normalement à systemd et reçoivent les mises à jour amont via l'apt upgrade que vous lancez déjà.

Combien de RAM et de disque faut-il pour un VPS Docker ?

Le moteur lui-même est léger : dimensionnez le VPS pour les conteneurs et leurs images.

Docker Engine consomme quelques dizaines de mégaoctets de RAM au repos : le vrai budget, c'est votre charge de travail. Une petite application web avec une base de données tourne confortablement dans 2 Go ; des piles plus lourdes ou plusieurs projets réclament 4 Go ou plus. Le disque compte davantage qu'on ne le croit : images, cache de build et logs atterrissent tous dans /var/lib/docker, et 20 Go se remplissent vite sans docker system prune ni rotation des logs. Préférez du CPU et de la RAM dédiés à des ressources mutualisées en burst, car les builds provoquent des pics violents et les conteneurs ne supportent pas bien le swap.