Créer un home lab Raspberry Pi avec Docker : installation, sauvegarde et reprise

En bref : Commencez avec Raspberry Pi OS 64 bits compatible, SSH fonctionnel et un seul petit service Compose. Gardez son port web sur localhost, utilisez un tunnel SSH et vérifiez une sauvegarde avant d’ajouter des données importantes. Un conteneur démarré est un début, pas une preuve de récupération possible.

Nous construisons volontairement un exemple modeste : une page statique servie par nginx. Il permet de comprendre hôte, conteneur, réseau et données sans commencer par une base, un gestionnaire de mots de passe ou une console publique. Les commandes sont des exemples proposés, pas la preuve d’un essai AYXWORKS sur cette configuration matérielle exacte.

1. Préparer un hôte propre et un périmètre clair

Prévoyez une Raspberry Pi adaptée à la charge, une alimentation et un refroidissement compatibles, un stockage fiable et le réseau. Une Pi 4 ou Pi 5 avec un OS 64 bits pris en charge convient comme point de départ à ce petit exemple ; cela ne garantit pas sa capacité pour tout service futur. Consultez la documentation de la carte pour le stockage et le démarrage.

Utilisez Raspberry Pi Imager et les instructions officielles d’accès distant pour votre compte et SSH. L’utilisateur illustratif est ici labuser et le nom d’hôte lab. Remplacez-les par vos valeurs. Vérifiez SSH sur votre réseau domestique de confiance avant les applications. Si le nom .local ne fonctionne pas, relevez l’adresse dans le routeur.

Ne réimagez pas un serveur existant pour suivre ce guide. L’écriture efface le stockage choisi. Utilisez un support de réserve ou sauvegardé et contrôlez la destination. Si Docker ou des services existent déjà, examinez leur installation au lieu de la remplacer par les commandes suivantes.

2. Vérifier le système et l’architecture

Sur la Pi, inspectez :

cat /etc/os-release
dpkg --print-architecture
uname -m

La procédure vise Raspberry Pi OS 64 bits basé sur une version Debian prise en charge. Vérifiez arm64 dans la réponse de dpkg et le véritable nom de code Debian. La documentation Docker consultée inclut Bookworm et Trixie parmi les versions compatibles. Un noyau 64 bits ne prouve pas à lui seul que l’espace utilisateur l’est aussi.

Avec un système 32 bits, une version non compatible ou une autre distribution, arrêtez-vous et suivez les instructions officielles correspondantes. Ne remplacez pas le nom de code arbitrairement pour forcer l’acceptation du dépôt.

3. Installer Docker depuis le dépôt de paquets adapté

Sur l’hôte propre et compatible, suivez la procédure Docker pour Debian. Lisez les demandes du gestionnaire de paquets et arrêtez-vous en cas d’erreur. Le bloc écrit un fichier de dépôt Docker : n’écrasez pas une configuration personnalisée existante sans l’examiner.

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run --rm hello-world
sudo docker compose version

Les vérifications attendues sont un hello-world réussi et une version de Compose, pas un numéro imposé par cet article. Les commandes conservent sudo pour administrer Docker. Comme le rappelle sa documentation, le groupe docker confère des privilèges de niveau root ; ce n’est pas une commodité anodine.

4. Créer un projet Compose isolé

Le bloc refuse d’écraser ~/homelab/web si le répertoire existe. Il crée une page et un fichier Compose. La gestion des erreurs du sous-shell interrompt le bloc si le chemin est présent ou si une commande échoue.

(
  set -eu
  test ! -e "$HOME/homelab/web"
  mkdir -p "$HOME/homelab/web/site"
  cd "$HOME/homelab/web"
  printf '%s\n' '<!doctype html><title>Home lab</title><h1>Home lab is running</h1>' > site/index.html
  cat > compose.yaml <<'YAML'
name: lab-web
services:
  web:
    image: nginx:stable-alpine
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./site:/usr/share/nginx/html:ro
    restart: unless-stopped
    logging:
      driver: local
YAML
)

L’image fournit le serveur ; la page reste dans le répertoire site de l’hôte, monté en lecture seule dans le conteneur. Le port écoute uniquement sur l’adresse de boucle locale de la Pi. C’est voulu : le site n’est ouvert ni au réseau local ni à internet. Le pilote de journalisation local apporte une rotation limitée des logs au lieu de laisser croître des journaux par défaut sans limite.

Le tag d’image facilite le démarrage mais n’est pas une version immuable. Après validation, enregistrez le digest résolu et fixez-le pour reproduire l’installation. Télécharger le même tag plusieurs mois après ne garantit pas le même logiciel.

5. Démarrer et vérifier la page réelle

Exécutez depuis le nouveau projet ; examinez toute erreur avant de poursuivre :

cd "$HOME/homelab/web" || exit 1
sudo docker compose config --quiet
sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps
curl --fail http://127.0.0.1:8080/

La validation doit se terminer sans erreur, le service apparaître démarré et curl renvoyer le HTML d’exemple. L’état « running » ne prouve pas que l’application fonctionne. Si curl échoue, examinez logs, liaison du port et montage de la page avant d’ajouter des logiciels.

6. Accéder depuis le portable sans publier le port

Sur votre portable, ouvrez le tunnel avec le compte et le nom configurés :

ssh -N -l labuser -L 127.0.0.1:8080:127.0.0.1:8080 lab.local

Laissez le terminal ouvert et visitez http://127.0.0.1:8080/ dans le navigateur du portable. La commande SSH reste volontairement active sans ouvrir de shell. Arrêtez-la avec Ctrl+C. Si le port 8080 est déjà occupé localement, changez le premier port du transfert et utilisez ce nouveau port dans le navigateur.

N’ajoutez pas de redirection sur le routeur et n’exposez pas le socket Docker. Les ports publiés par Docker interagissent avec les règles de pare-feu : ne supposez pas qu’un pare-feu rend tout conteneur publié privé. L’accès depuis l’extérieur exige une conception dédiée, pas une console d’administration ouverte.

7. Examiner logs, stockage et image testée

cd "$HOME/homelab/web" || exit 1
sudo docker compose ps
sudo docker compose logs --tail=50 web
df -h
sudo docker image inspect nginx:stable-alpine --format '{{index .RepoDigests 0}}'

Utilisez les logs Compose pour les erreurs applicatives et l’usage disque pour la capacité de l’hôte. La dernière commande affiche la référence résolue de l’image ; conservez-la avec Compose quand vous fixez une version testée. Vérifiez les journaux avant de les partager, car les applications réelles peuvent y écrire des données privées.

Ne lancez pas une pile entière parce qu’une première page répond. Ajoutez un service à la fois en vérifiant architecture CPU, mémoire, données persistantes, identifiants, réseau et reprise. Un conteneur ne rend pas automatiquement un logiciel incompatible exécutable sur ARM.

8. Créer et vérifier une sauvegarde de l’exemple

Pour cette page statique, le dossier du projet contient données et configuration. Sans modifications simultanées, exécutez :

(
  set -eu
  umask 077
  mkdir -p "$HOME/backups"
  backup="$HOME/backups/lab-web-$(date +%Y%m%d-%H%M%S).tar.gz"
  test ! -e "$backup"
  tar -C "$HOME/homelab" -czf "$backup" web
  gzip -t "$backup"
  sha256sum "$backup"
  restore=$(mktemp -d "$HOME/lab-restore.XXXXXX")
  tar -xzf "$backup" -C "$restore"
  cmp "$HOME/homelab/web/site/index.html" "$restore/web/site/index.html"
  cmp "$HOME/homelab/web/compose.yaml" "$restore/web/compose.yaml"
  printf 'Backup: %s\nRestored copy: %s\n' "$backup" "$restore"
)

L’archive est contrôlée, extraite dans un nouveau dossier temporaire et comparée aux fichiers sources. cmp reste silencieux en cas de concordance ; une erreur arrête le bloc. Cela démontre une récupération de fichiers, pas une répétition complète de reprise d’une application en fonctionnement. Gardez l’extraction jusqu’à l’avoir inspectée.

Copiez l’archive sur un autre appareil ou une destination de sauvegarde protégée. Une copie uniquement sur la Pi disparaît avec son stockage. Une base de données exige une sauvegarde cohérente ou un export pris en charge ; copier son dossier en activité ne garantit rien. Les volumes Docker réclament eux aussi un plan, comme l’indique la documentation des volumes.

9. Mettre à jour avec méthode et savoir arrêter

Avant une mise à jour, gardez Compose, la référence d’image testée et la sauvegarde des données. Lisez les notes de version, téléchargez l’image choisie, recréez le service et revérifiez la page. Avec une migration de schéma, revenir à l’ancienne image ne suffit pas forcément à annuler les modifications de données ; suivez la reprise prévue par l’application.

Pour arrêter cet exemple et supprimer ses conteneurs et son réseau Compose :

cd "$HOME/homelab/web" || exit 1
sudo docker compose down

Le dossier site monté depuis l’hôte n’est pas supprimé. N’ajoutez pas -v sans réfléchir à d’autres projets et n’utilisez pas l’élagage des volumes au lieu de comprendre la persistance. Cet exemple se recrée avec le fichier Compose conservé et up -d.

Ce qu’il faut ajouter après les bases

Authentification, TLS, sauvegardes externes, surveillance et politique de mise à jour comptent avant de confier des informations irremplaçables au laboratoire. Adaptez-les à l’application. Gardez les secrets hors du contrôle de versions et limitez l’administration de Docker et SSH.

Le premier jalon est simple : expliquer où se trouve la page, comment on y accède, quelle image tourne, ce qui survit à la suppression du conteneur et comment la sauvegarde a été vérifiée. Cela vaut mieux qu’un tableau de bord plein de services dont personne n’a essayé la reprise.

Sources et limites de validation

Les documents Raspberry Pi et Docker liés ont été examinés le 14 octobre 2026. Capacité matérielle, disponibilité des images et compatibilité doivent encore être vérifiées pour l’hôte choisi. Ce tutoriel remplace les récits personnels non étayés ; il ne prétend ni à un déploiement matériel AYXWORKS effectué ni à une fiabilité améliorée mesurée.