rclone Agent — Architecture

Problème résolu

n8n tourne dans un container Docker. rclone doit s’exécuter sur le serveur hôte pour accéder aux credentials Google OAuth stockés localement. Il fallait donc un intermédiaire : un service HTTP que n8n peut appeler, et qui exécute rclone sur le serveur.

Architecture

n8n (container Docker)
    │
    │  HTTP POST /transfer
    │  {"src_drive_id": "...", "path": "...", "type": "fichier"}
    ▼
rclone-agent (hôte, systemd)
    │
    │  subprocess → rclone
    ▼
rclone
    │
    │  Google Drive API (OAuth)
    ▼
Google Drive (Compte A → Compte B)

Fichier source

Le fichier Python de l’agent est dans le dossier scripts/ du répertoire home (chemin exact dans context.md).

Service systemd

L’agent est géré par systemd, ce qui garantit son démarrage automatique au boot et sa relance en cas de crash.

# Statut
systemctl status rclone-agent

# Démarrer / Arrêter / Redémarrer
sudo systemctl start rclone-agent
sudo systemctl stop rclone-agent
sudo systemctl restart rclone-agent

# Logs en temps réel
journalctl -u rclone-agent -f

# Logs des 30 dernières minutes
journalctl -u rclone-agent --since "30 min ago" --no-pager

Configuration

Variable	Rôle
PORT	Port d’écoute (interne, non exposé)
BEARER_TOKEN	Authentification des requêtes (via variable d’env)
RCLONE_BIN	Chemin du binaire rclone
RCLONE_CONF	Config rclone avec les tokens OAuth
LOGS_DIR	Dossier des logs de transfert

Credentials rclone

Le fichier rclone.conf contient les tokens OAuth pour les deux comptes Google Drive :

[gdrive_a]
type = drive
scope = drive
token = {...}     ← Token JSON Google OAuth du Compte A

[gdrive_b]
type = drive
scope = drive
token = {...}     ← Token JSON Google OAuth du Compte B

Pour chaque transfert, l’agent crée un fichier de config temporaire avec uniquement les sections [src] et [dst], puis le supprime après l’exécution.

Persistance des jobs

Les jobs sont stockés en mémoire ET sur disque (fichiers .status dans le dossier logs). Au démarrage, l’agent recharge tous ces fichiers, ce qui permet de retrouver l’état des transferts après un redémarrage.

# Voir le nombre de fichiers de statut
ls ~/scripts/logs/job_*.status | wc -l

# Lire le statut d'un job
cat ~/scripts/logs/job_<job_id>.status

Transferts en parallèle

Chaque appel POST /transfer lance un thread Python séparé. Plusieurs transferts peuvent donc tourner simultanément. Le nombre est limité côté n8n (WF-B, Section C) pour éviter de saturer la connexion.

Logs de transfert

Pour chaque job, un fichier .log est créé dans le dossier logs.

Il contient :

• L’heure de démarrage, la source et la destination
• La sortie rclone (progression, stats toutes les 60s)
• Le résultat final (✅ Succès ou ❌ Erreur avec code de retour)

# Voir les 30 dernières lignes d'un log
tail -30 ~/scripts/logs/transfer_<job_id>.log

# Suivre un transfert en temps réel
tail -f ~/scripts/logs/transfer_<job_id>.log