7 erreurs Docker qui peuvent casser votre Raspberry Pi

J’utilise Docker de plus en plus sur mon Raspberry Pi, surtout pour héberger des services qui n’ont pas de paquet dans les dépôts officiels. C’est parfait pour des tests rapides, mais avec le temps, les problèmes commencent à s’accumuler. Du coup, aujourd’hui je vous partage mes conseils pour faire tenir vos projets sur la durée.

Un conteneur Docker peut tourner indéfiniment s’il est bien configuré. Pour la stabilité, chaque conteneur doit être isolé avec ses propres fichiers de configuration, dossiers et ports réseau. Pour la stabilité, il ne faut pas oublier les redémarrages automatiques, les mises à jour régulières et les sauvegardes.

Ces principes sont probablement évidents pour les logiciels classiques, mais dans l’écosystème Docker, ce n’est pas toujours évident à mettre en place. On va voir chaque point en détail pour que votre serveur tourne comme une horloge.

Si vous débutez avec Raspberry Pi ou Linux, j’ai quelque chose qui peut vous aider !
Téléchargez ma fiche mémo des commandes Linux gratuitement – c’est un guide de référence rapide avec toutes les commandes essentielles dont vous aurez besoin utiliser votre Raspberry Pi. Cliquez ici pour l’obtenir gratuitement !

Laisser ses conteneurs tomber sans prévenir

Configurez toujours une politique de redémarrage pour que vos conteneurs se relancent automatiquement.

Commençons par le plus simple. Je m’installe avec du popcorn pour regarder Kung Fury sur ma smart TV, et là je découvre que les films sur mon serveur Plex sont inaccessibles. En vérifiant mon conteneur Docker pour Plex, je vois qu’il est planté.

Par défaut, Docker ne redémarre pas automatiquement un conteneur qui plante ou quand le Raspberry Pi reboot. Si un conteneur doit tourner 24h/24, il faut le préciser explicitement.

Pour qu’un conteneur démarre automatiquement au boot et redémarre en cas de crash, ajoutez cette ligne dans votre config :
restart: always

Le mode « always » peut être un peu agressif quand on bidouille. Dans ce cas, utilisez plutôt cette option. Elle redémarre le conteneur dans la plupart des cas, sauf si vous l’avez arrêté manuellement :
restart: unless-stopped

En général, ça suffit largement pour garder mon serveur Plex bien en vie. Pour un service vraiment critique, vous pouvez aller plus loin et créer une alerte personnalisée (en anglais) qui vous prévient dès qu’il tombe.

Entasser tous ses services dans un seul Dockerfile

Un service par conteneur, un fichier compose par service.

J’adore Docker Compose parce que les configurations en fichier texte, ça a vraiment du sens. Et je suis content que ça devienne peu à peu la norme. Mais quand j’ai démarré, j’ai eu la brillante idée de tout mettre dans un seul fichier géant. Plus simple à maintenir, non ?

Grosse erreur. Ce fichier unique s’est révélé bien plus difficile à gérer :

• Impossible de contrôler facilement quels conteneurs sont mis à jour.
• On mélange les paramètres et on crée des conflits de ports ou de volumes.
• Si un conteneur est mal configuré, tous les autres peuvent refuser de démarrer.

La bonne approche pour une maintenance sereine, c’est de tout séparer : un service, un fichier.

Par exemple, je crée un dossier distinct pour chaque conteneur, un pour Immich et un pour qbittorrent. Chaque dossier contient uniquement le fichier compose.yaml qui correspond à ce conteneur.

Note : Il existe des cas où regrouper plusieurs services dans un seul fichier Docker est justifié. Par exemple, si des conteneurs doivent partager des volumes ou un réseau virtuel pour atteindre un objectif précis.

On utilise ce type de configuration dans notre guide pour construire la stack de sécurité ultime sur Pi. Mais c’est un cas avancé, donc pour les débutants, restez sur la règle de base : un service, un fichier.

Accumuler les restes d’anciens projets Docker

Nettoyez régulièrement les conteneurs, images et volumes inutilisés.

Docker ne rend pas les choses très intuitives pour savoir ce qui traîne encore : vieux conteneurs, doublons, fichiers orphelins…

Pour avoir une idée claire, lancez cette commande :
docker system df
Ou pour plus de détails :
docker system df -v

Par exemple, vous pouvez avoir des restes de :

• Vieilles images que rien n’utilise plus.
• Conteneurs arrêtés qui ne servent plus à rien.
• Réseaux virtuels inactifs d’anciennes configurations.
• Volumes abandonnés.
• Restes de cache de build.

Tout ce bazar peut ralentir votre système (en anglais), car le Raspberry Pi doit parcourir tout ça.

Si ça ne sert plus à rien, on s’en débarrasse. Une fois mes tests terminés et ma configuration stable, je fais le ménage avec cette commande :
docker system prune

Il existe des commandes pour nettoyer de façon plus ciblée (voir ici), mais la commande ci-dessus est facile à retenir et amplement suffisante pour un usage quotidien.

Si les commandes Linux ce n’est pas trop votre truc, n’hésitez pas à jeter un œil à cet article qui vous explique les commandes qu’il faut absolument connaître. Je vous donne aussi une antisèche à télécharger pour les avoir toujours sous la main !

Laisser les conteneurs monopoliser les ressources

Définissez toujours des limites de ressources (CPU, RAM) pour vos conteneurs sur le Pi.

La plupart de mes conteneurs sont sages et ne consomment pas plus que leur part. Mais parfois, j’héberge un gros gourmand — comme une base de données PostgreSQL — qui s’accapare tout le CPU et la RAM de mon Raspberry Pi 5.

Un conteneur sans limite peut étouffer votre serveur, et le problème s’aggrave au fur et à mesure que vous ajoutez des services. Par exemple, si le système lève une exception « Out of Memory », il peut commencer à tuer des processus au hasard pour libérer de la mémoire. C’est trop chaotique.

Pour garder le contrôle sur les conteneurs voraces, on définit des limites de ressources.
Un exemple vaut mieux qu’un long discours, voici une config avec les parties importantes en gras :

services:
  stress-test:
    image: jfleach/docker-arm-stress-ng:latest
    privileged: true

    cpus: 0.5
    mem_limit: 512m
    memswap_limit: 512m

    logging:
      driver: "local"
      options:
        max-size: 50m
        max-file: 3


    command: >
      --cpu 4
      --vm 2
      --vm-bytes 800m
      --vm-populate
      --timeout 60s
      --verbose

On peut vérifier que les limites sont bien respectées avec cette commande :
docker stats

Voici ce que font ces paramètres :

• Processeur – cpus: 0.5 signifie que le conteneur peut utiliser au maximum 0,5 cœur CPU.
• Mémoire – mem_limit: 512m, memswap_limit: 512m limite le conteneur à 512 Mo de RAM. Les deux lignes sont nécessaires pour que ça fonctionne correctement sur un Raspberry Pi.
• Logs – permet de limiter l’espace disque occupé par les journaux.
  • driver: local – utilise la rotation des logs du système.
  • max-size: 50m – le fichier de log principal ne peut pas dépasser 50 Mo.
  • max-file: 3 – on conserve 3 fichiers de log en rotation avant de supprimer les plus anciens.

Ajustez ces valeurs selon vos besoins. Pour être honnête, je ne définis pas de limites pour tous mes conteneurs, car ça peut créer des goulots d’étranglement. Je vérifie d’abord si un conteneur est trop gourmand, et si c’est le cas, j’ajoute des limites.

Petit conseil : Docker ne rapporte pas correctement l’utilisation mémoire sur le Raspberry Pi par défaut. Si vous avez besoin de cette fonctionnalité, ouvrez /boot/firmware/cmdline.txt et ajoutez ces paramètres à la fin de la longue ligne qui s’y trouve :
cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1

Créer des conflits de ports

Assignez un port hôte unique à chaque conteneur pour éviter les conflits.

Quand on configure des conteneurs Docker, on définit souvent un port réseau pour accéder au service. Beaucoup de services proposent un panneau web qui utilise le port 80 par défaut. Si trois services différents utilisent tous le port 80, comment votre Raspberry Pi saura lequel afficher ?

Pour éviter les conflits, on assigne un port différent à chaque conteneur pour qu’ils ne se marchent pas dessus.
Voici la partie concernée dans une config Docker pour Pi-Hole :

pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
      - "443:443/tcp"

Quand je vois 80:80 et 443:443, mon premier réflexe c’est de les modifier. Ce sont des ports très courants qui peuvent entrer en conflit avec d’autres conteneurs, comme mon serveur web Caddy. Pour changer le port, il suffit de modifier le nombre à gauche des deux-points (:), comme ça :
6060:80/tcp
6443:443/tcp

Le panneau web de Pi-Hole est maintenant accessible sur le port 6060. Certes, c’est moins facile à retenir, mais après la configuration initiale j’y retourne rarement, et un simple favori dans le navigateur règle le problème.

Rester sur des images obsolètes

Mettez régulièrement à jour vos images Docker pour rester sécurisé.

Les conteneurs sont conçus pour être isolés du système, donc un apt update (en anglais) classique ne les touchera pas. Résultat : j’installe un truc comme Home Assistant, je l’oublie pendant un an, et il reste exposé à des failles de sécurité.

Voici deux façons de rendre les mises à jour de conteneurs plus faciles à gérer.

Comment mettre à jour des conteneurs Docker

Rendez-vous dans le dossier où est stocké le fichier compose.yaml du conteneur.
Puis lancez ces commandes pour le mettre à jour :
docker compose pull
docker compose up

La première commande télécharge la nouvelle image, la seconde redémarre le conteneur avec cette image mise à jour. Si vous préférez mettre à jour tous vos conteneurs sans le faire un par un, vous pouvez créer un script (en anglais) qui lance ces commandes automatiquement une fois par mois.

Autre option : passer par Portainer (Portainer est un gestionnaire de conteneurs graphique, en anglais, qui tourne lui-même dans un conteneur). Allez sur la page Container Details du service et cliquez sur le bouton Recreate pour mettre à jour le conteneur.

Quand utiliser le tag ‘Latest’

J’utilise souvent le tag ‘latest’ (ex : image: wg-easy:latest) pour toujours récupérer la version la plus récente lors d’une mise à jour. Mais pour un service critique, sur un serveur de production par exemple, on préfère quelque chose de plus stable.

Quand la stabilité prime, épinglez la configuration Docker sur une version d’image précise.
Par exemple, la config de mon serveur VPN WireGuard (en anglais) utilise ce tag à la place :
image: ghcr.io/wg-easy/wg-easy:14

Le tag « :14 » indique à Docker de prendre la dernière version v14, qui est déjà mature et ne reçoit que des mises à jour de sécurité. Avec le tag ‘latest’, il aurait récupéré la v15 encore en développement actif, qui aurait pu casser ma configuration.

Oublier de sauvegarder les données utilisateur

Configurez des volumes pour stocker vos données en dehors des conteneurs.

Beaucoup de conteneurs ont besoin de stocker des données — paramètres, fichiers utilisateur — comme n’importe quel programme. Mais si vous ne leur dites pas comment faire, vos données finiront par disparaître. Dans une configuration Docker, la section ‘volumes’ indique au conteneur où sauvegarder ses fichiers.

Il y a plusieurs façons de s’y prendre, voici ce que je fais :

• Stocker chaque conteneur dans son propre dossier de projet.
• Mapper les volumes des fichiers utilisateur en chemin relatif par rapport à ce dossier.

Par exemple, j’ai un dossier ~/containers pour tout ce qui concerne Docker. Dedans, j’ai un sous-dossier pour mon projet paperless-ngx, qui ne contient au départ que sa configuration Docker.

Voici la partie concernée dans le compose.yaml :

paperless-ngx:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    volumes:
      - data:/usr/src/paperless/data
      - media:/usr/src/paperless/media
      - ./export:/usr/src/paperless/export
      - ./consume:/usr/src/paperless/consume

La documentation indique que les deux premiers volumes (‘data’ et ‘media’) sont des valeurs par défaut de l’application pour son fonctionnement de base, on les ignore donc ici. Les deux suivants (‘export’ et ‘consume’), en revanche, correspondent aux fichiers utilisateur — mes documents scannés par exemple — et indiquent où les sauvegarder. Sans ces lignes, quand le conteneur s’arrête, les fichiers disparaissent dans la nature !

En mettant « ./ » devant, j’indique à Docker de mapper ces volumes dans le dossier courant — et pas dans des endroits aléatoires du système de fichiers Linux comme /etc ou /usr. Résultat : tous mes fichiers utilisateur pour paperless-ngx sont stockés au même endroit que sa configuration Docker.

Pourquoi c’est plus simple ? Parce que pour sauvegarder tous mes conteneurs, je compresse (en anglais) le dossier ~/containers, et c’est réglé.

Pour restaurer depuis une sauvegarde, je relance le conteneur et il trouve tout ce dont il a besoin dans un seul dossier. C’est encore une raison pour laquelle j’adore Docker : tout est reproductible, pas besoin d’avoir une mémoire parfaite pour tout réinstaller exactement comme avant.

C’est tout pour aujourd’hui ! Avec ces bonnes pratiques, vos conteneurs tiendront la route même quand vous n’êtes pas là pour les surveiller.

Pour aller plus loin avec Docker, jetez un œil à nos autres tutoriels :

• Débuter avec Docker sur Raspberry Pi – pour mieux comprendre les bases des conteneurs.
• Docker Compose – la méthode recommandée pour créer des fichiers de configuration.
• Installer Portainer sur Raspberry Pi (en anglais) – gérez vos conteneurs depuis une interface graphique.
• 11 projets Docker à tester sur Raspberry Pi – pour trouver des idées de services à héberger.

Si vous débutez avec Raspberry Pi ou Linux, j’ai quelque chose qui peut vous aider !
Téléchargez ma fiche mémo des commandes Linux gratuitement – c’est un guide de référence rapide avec toutes les commandes essentielles dont vous aurez besoin utiliser votre Raspberry Pi. Cliquez ici pour l’obtenir gratuitement !