Docker : pour des environnements de développement et CI maîtrisés

Commandes de visibilité

Étant amener à naviguer dans un context multi projet il est primordial de connaitre et suivre les ressources Docker utilisé sur son poste de travail.

Voici donc la liste des commandes Docker les plus utiles au quotidien :

Commande	Explication	Cas d'usage
docker version	Affiche la version du client et du daemon Docker	Vérifier la version installée, s'assurer que le daemon est démarré
docker ps	Liste les conteneurs en cours d'exécution	Voir ce qui tourne, récupérer le nom ou l'ID d'un conteneur
docker ps -a	Liste tous les conteneurs, y compris les arrêtés	Repérer un conteneur en erreur ou un conteneur oublié
docker images	Liste toutes les images locales avec leur taille	Identifier les images inutilisées qui consomment de l'espace
docker network ls	Liste les réseaux Docker existants	Vérifier qu'un réseau partagé est actif, repérer des réseaux orphelins
docker volume ls	Liste tous les volumes, utilisés ou non	Repérer des volumes orphelins après suppression d'un projet
docker system df	Récapitulatif de l'espace disque consommé par Docker	Point de départ avant toute opération de nettoyage

Commandes de nettoyage

Au fil du temps, et selon le nombre d'images Docker téléchargées (pull), Docker peut accumuler une quantité importante de données sur le disque. Ce phénomène touche aussi bien les postes de développement que les serveurs de runners pour la CI ou bien encore le staging ou la production. Conteneurs arrêtés, images intermédiaires (dangling), volumes orphelins, caches de build : tout cela s'accumule silencieusement et peut finir par saturer le disque. Il est donc essentiel de maîtriser les commandes de nettoyage pour garder le contrôle de l'espace utilisé.

docker system df (listée plus haut dans les commandes de visibilité) est le point de départ : elle donne une vue d'ensemble de l'espace occupé avant de décider quoi supprimer. En complément, df -h est une commande Linux qui affiche l'espace disque total, utilisé et disponible sur chaque partition du système (le -h signifie "human-readable", les tailles sont en Go/Mo plutôt qu'en octets). Croiser les deux commandes permet de déterminer concrètement le ratio de l'espace disque consommé par Docker par rapport à l'espace total disponible sur le serveur.

Les deux commandes de nettoyage à connaître absolument :

docker system prune -a

Supprime l'ensemble des ressources Docker inutilisées : conteneurs arrêtés, images non utilisées par un conteneur actif (y compris les images téléchargées mais jamais démarrées), réseaux orphelins et caches de build. Le flag -a (all) est important : sans lui, seules les images dites "dangling" (sans tag, résidus de builds) sont supprimées. Avec -a, toutes les images non rattachées à un conteneur en cours d'exécution sont également supprimées.

Dans certains cas d'usage, il peut être pertinent de programmer cette commande en tâche cron pour automatiser le nettoyage. Un exemple typique : un VPS utilisé comme runner de jobs GitLab CI/CD. Chaque pipeline télécharge ou reconstruit des images Docker qui s'accumulent rapidement sans jamais être supprimées automatiquement. Ajouter une cron hebdomadaire (ou quotidienne selon le volume de jobs) permet d'éviter une saturation disque progressive sans intervention manuelle. Exemple de cron à ajouter via crontab -e sur le serveur runner :

# Nettoyage Docker tous les dimanches à 3h du matin
0 3 * * 0 docker system prune -a -f >> /var/log/docker-prune.log 2>&1

Le flag -f (force) désactive la demande de confirmation interactive, indispensable pour une exécution automatisée. Le log dans /var/log/docker-prune.log permet de vérifier que la tâche s'exécute correctement et de voir combien d'espace est récupéré à chaque passage.

docker volume prune -a

Supprime tous les volumes Docker non utilisés par un conteneur actif. Le flag -a supprime aussi les volumes nommés (ceux créés explicitement dans un docker-compose.yml), pas seulement les volumes anonymes.

A utiliser avec précaution : contrairement aux images qui peuvent être re-téléchargées, les données contenues dans les volumes sont définitivement perdues (bases de données, uploads, fichiers persistants). Sur un serveur, toujours vérifier quels volumes sont en jeu avant de lancer cette commande.

Un Dockerfile mal conçu produit des images lourdes, des builds lents et des couches de cache inutilisables. Voici les points clés à maîtriser pour écrire des Dockerfiles maintenables et performants.

Se baser sur une image officielle existante

Partir d'une image officielle (Docker Hub) plutôt que de repartir de zéro depuis une image ubuntu nue. Les images officielles sont maintenues, régulièrement mises à jour pour les CVE et optimisées pour leur usage. Préférer les variantes -alpine ou -slim quand les outils de base suffisent : elles sont nettement plus légères.

# Image complète : ~180 Mo
FROM php:8.3-apache

# Variante slim : ~50 Mo
FROM php:8.3-apache-slim

Ordonner les instructions pour maximiser le cache des layers

Docker met en cache chaque instruction (RUN, COPY, ADD). Si une instruction change, toutes celles qui suivent sont reconstruites. Placer en premier ce qui change le moins souvent (installation des dépendances système), et en dernier ce qui change le plus souvent (fichier de configuration).

FROM php:8.3-apache

# Rarement modifié : installé en premier, mis en cache longtemps
RUN apt-get update && apt-get install -y libpq-dev \
    && docker-php-ext-install pdo pdo_pgsql

# Config pouvant changer plus souvant
COPY --link docker/.bashrc /home/dev/.bashrc
COPY --link docker/php/conf.d/app.ini $PHP_INI_DIR/conf.d/
COPY --link docker/php/conf.d/xdebug.ini $PHP_INI_DIR/conf.d/

Nettoyer le cache dans le même RUN que l'installation

Chaque instruction RUN crée un layer. Si le cache apt est supprimé dans une instruction séparée, le layer de l'installation le contient encore. Tout regrouper dans un seul RUN avec && pour que le layer final soit propre.

# Correct : cache nettoyé dans le même layer
RUN apt-get update && apt-get install -y curl libpq-dev \
    && docker-php-ext-install pdo pdo_pgsql \
    && rm -rf /var/lib/apt/lists/*

# Incorrect : le layer d'installation contient quand même le cache
RUN apt-get update && apt-get install -y curl
RUN rm -rf /var/lib/apt/lists/*