Entretenir et sécuriser Docker

Une installation Docker vit : les images s’accumulent, les services attendent leurs mises à jour, le disque se remplit. Deux dangers guettent, et ils sont opposés : supprimer la mauvaise chose, ou ne jamais rien mettre à jour. Une seule méthode évite les deux.

1. Regarder avant d’agir

Ces commandes ne suppriment rien :

docker system df
docker ps -a
docker volume ls
docker stats --no-stream

docker system df résume l’espace occupé par les images, les conteneurs, les volumes et le cache de construction. Sa colonne RECLAIMABLE indique ce qui pourrait être libéré : ce n’est pas une liste de choses à supprimer.

2. Mettre à jour un projet Compose

Entraînez-vous sur le projet de l’épisode 7 :

cd ~/docker-lab/compose-demo
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail 30

Une mise à jour réussie ne se juge pas au message final : ouvrez réellement l’application.

Le tag alpine suit les nouvelles versions de Nginx : chaque pull peut en apporter une. Pour un service important, préférez un tag qui fige la version, dont la liste figure sur la page de l’image, sur Docker Hub. Vous choisissez alors quand passer à la suivante, après avoir lu ses notes de version et fait une sauvegarde. En cas de problème, remettre l’ancien tag dans compose.yaml puis relancer docker compose up -d suffit à revenir en arrière.

3. Faire le ménage prudemment

Chaque commande de nettoyage vise quelque chose de précis :

Docker demande confirmation avant chacune : lisez l’avertissement. Et une règle ne souffre aucune exception : tout ce qui contient le mot « volume » peut effacer des données. docker volume prune, ou l’option --volumes ajoutée à une autre commande, ne se lancent jamais par habitude, ni sans une sauvegarde vérifiée.

4. Les réglages de sécurité qui comptent

• Des images de confiance. Sur Docker Hub, préférez les badges « Docker Official Image » et « Verified Publisher ». Une image inconnue, c’est du code inconnu qui tourne chez vous.
• Le moins de ports possible. Pas de -p pour un service interne, 127.0.0.1 pour un outil personnel. L’épisode 6 détaille le raisonnement.
• Pas de secret dans une image ni dans Git. Les mots de passe vont dans un fichier .env, à côté de compose.yaml ; Compose le lit tout seul.
• Ni --privileged, ni socket Docker monté. Donner à un conteneur l’accès à /var/run/docker.sock, c’est lui donner les clés de toute la machine. Certains outils le demandent : faites-le seulement si vous savez pourquoi.
• Des mises à jour régulières, de Docker lui-même comme de vos images.

Voici à quoi ressemble un mot de passe bien rangé. Dans compose.yaml :

services:
  base:
    image: postgres:18
    environment:
      POSTGRES_PASSWORD: ${MOT_DE_PASSE_BASE}

Et dans le fichier .env, dans le même dossier :

MOT_DE_PASSE_BASE=une-longue-phrase-aleatoire

Le fichier compose.yaml peut alors être partagé ou versionné sans rien révéler. Ajoutez .env à votre .gitignore et à votre .dockerignore.

sudo apt update && sudo apt upgrade

systemctl status docker --no-pager
sudo journalctl -u docker --since "10 minutes ago" --no-pager

Quand quelque chose ne va pas

Un conteneur qui redémarre en boucle n’est qu’un symptôme : la cause est presque toujours une erreur de configuration, de droits ou d’accès aux données. Le recréer dix fois n’y change rien. Suivez la boucle : lisez l’état (docker compose ps), puis les journaux (docker compose logs), puis la configuration (docker compose config). Et changez une seule chose à la fois : sinon, vous ne saurez jamais laquelle a réglé le problème.