Comment démarrer CloudCMD après les montages SSHFS dans Portainer

by  on  in Accueil

Le problème rencontré

J’utilise CloudCMD dans un conteneur Docker géré par Portainer pour accéder à mes fichiers via une interface web. Jusque-là, tout va bien. Sauf que… j’ai deux répertoires distants (hors de mon réseau domestique) qui se montent via SSHFS au démarrage de mon serveur :

  • distant_toto : un répertoire hébergé sur le serveur de Toto (xxx.xxx.x.xx)
  • distant_tata : un répertoire hébergé sur le serveur de Tata (yyy.yyy.y.yy)

Ces montages SSHFS se font automatiquement au boot du serveur, mais ils prennent un peu de temps à s’établir (connexion réseau, authentification SSH, etc.).

Le problème : CloudCMD démarre plus vite que les montages SSHFS ne sont prêts ! Résultat : CloudCMD affiche des répertoires vides pour distant_toto et distant_tata. Je suis alors obligé de redémarrer manuellement le conteneur CloudCMD après chaque redémarrage du serveur pour qu’il puisse enfin voir le contenu des répertoires distants.

Pas très pratique…

La solution : un délai de démarrage dans Portainer

L’idée est simple : faire attendre CloudCMD avant de démarrer, le temps que les montages SSHFS soient opérationnels.

Docker Compose (et donc Portainer) permet d’orchestrer le démarrage de plusieurs conteneurs avec des dépendances. On va créer un petit conteneur léger qui ne fait qu’attendre 90 secondes, puis CloudCMD ne démarrera qu’après la fin de cette attente.

Ma configuration SSHFS

Pour que les montages SSHFS se fassent automatiquement au démarrage du serveur, j’ai ajouté ces deux lignes dans mon fichier /etc/fstab :

# Éditer le fichier fstab
sudo nano /etc/fstab

Ajoutez ces lignes à la fin du fichier :

# Montage SSHFS du serveur de Toto
toto_user@xxx.xxx.x.xx:/    /home/myuser/distant_toto    fuse.sshfs    _netdev,reconnect,allow_other,IdentityFile=/home/myuser/.ssh/id_sshfs_auto,ServerAliveInterval=15,ServerAliveCountMax=3,uid=1000,gid=1000    0 0

# Montage SSHFS du serveur de Tata
tata_user@yyy.yyy.y.yy:/    /home/myuser/distant_tata    fuse.sshfs    _netdev,reconnect,allow_other,IdentityFile=/home/myuser/.ssh/id_sshfs_auto,ServerAliveInterval=15,ServerAliveCountMax=3,uid=1000,gid=1000    0 0

Explication des options importantes :

  • _netdev : indique que c’est un montage réseau, attend que le réseau soit disponible
  • reconnect : se reconnecte automatiquement en cas de perte de connexion
  • allow_other : permet aux autres utilisateurs d’accéder aux fichiers montés
  • IdentityFile : spécifie la clé SSH à utiliser pour l’authentification
  • ServerAliveInterval=15 : envoie un signal toutes les 15 secondes pour maintenir la connexion
  • ServerAliveCountMax=3 : déconnecte après 3 échecs consécutifs
  • uid=1000,gid=1000 : définit l’utilisateur et le groupe propriétaire (adaptez selon votre UID/GID)

Créez les points de montage si ce n’est pas déjà fait :

mkdir -p /home/myuser/distant_toto
mkdir -p /home/myuser/distant_tata

Testez votre configuration sans redémarrer :

# Monter tous les systèmes de fichiers du fstab
sudo mount -a

# Vérifier que les montages sont effectifs
mount | grep sshfs
ls -la /home/myuser/distant_toto
ls -la /home/myuser/distant_tata

Ces montages se trouvent maintenant dans /home/myuser/distant_toto et /home/myuser/distant_tata sur mon serveur local et se montent automatiquement à chaque démarrage.

La stack CloudCMD modifiée

Voici ma configuration complète dans Portainer (à copier dans l’éditeur de stack) :

version: '3.8'

services:
  # Conteneur qui attend simplement 90 secondes
  wait-for-sshfs:
    image: alpine:latest
    container_name: cloudcmd-mount-checker
    command: sh -c "echo 'Attente de 90 secondes pour les montages SSHFS...' && sleep 90 && echo 'Montages prêts, CloudCMD peut démarrer'"
    restart: "no"

  cloudcmd:
    image: coderaiser/cloudcmd:latest
    container_name: cloudcmd
    restart: unless-stopped
    depends_on:
      - wait-for-sshfs
    ports:
      - "8200:8000"
    volumes:
      - /mnt/freebox/nvme/:/mnt/freebox/nvme/:rw
      - /mnt/synology/films/:/mnt/synology/films/:rw
      - /data/:/data/:rw
      - /home/myuser/:/home/myuser/:rw
      - /home/myuser/distant_toto:/mnt/distant_toto:rw
      - /home/myuser/distant_tata:/mnt/distant_tata:rw
    environment:
      - CLOUDCMD_ROOT=/
      - CLOUDCMD_AUTH=false
      - CLOUDCMD_TERMINAL=true
      - CLOUDCMD_CONSOLE=true
    networks:
      - cloudcmd_network

networks:
  cloudcmd_network:
    driver: bridge

Comment ça fonctionne ?

  1. Le conteneur wait-for-sshfs :
    • Utilise une image Alpine Linux ultra-légère (environ 5 Mo)
    • Exécute simplement sleep 90 pour attendre 90 secondes
    • Affiche un message dans les logs pour tracer son activité
    • Ne redémarre jamais (restart: "no") car son job est ponctuel
  2. Le conteneur cloudcmd :
    • Dépend de wait-for-sshfs grâce à depends_on
    • Ne démarre qu’après la fin du conteneur wait-for-sshfs
    • Monte les répertoires SSHFS locaux vers des points de montage internes
    • Redémarre automatiquement en cas de crash (restart: unless-stopped)

Déploiement dans Portainer

  1. Stoppez votre stack CloudCMD actuelle si elle tourne
  2. Copiez-collez la configuration ci-dessus dans l’éditeur de stack
  3. Adaptez les chemins si nécessaire (remplacez /home/myuser/ par votre chemin réel)
  4. Déployez la stack
  5. Attendez environ 90 secondes

Vérification

Dans l’interface Portainer, section Containers :

  • cloudcmd-mount-checker : devrait être en état Exited (c’est normal, il a terminé son attente)
  • cloudcmd : devrait être en état Running avec le port 8200:8000 visible

Vous pouvez consulter les logs de cloudcmd-mount-checker pour voir les messages d’attente.

Pourquoi 90 secondes ?

J’ai choisi 90 secondes comme durée d’attente car :

  • Les montages SSHFS mettent généralement entre 30 et 60 secondes à s’établir sur mon réseau
  • Mieux vaut prévoir une marge de sécurité
  • Si vos montages sont plus rapides, vous pouvez réduire à 60 secondes
  • Si vos montages sont plus lents, augmentez à 120 secondes

Bonus : vérifier vos montages SSHFS

Pour vérifier que vos montages sont actifs sur votre serveur :

# Lister tous les montages SSHFS
mount | grep sshfs

# Tester l'accès aux répertoires
ls -la /home/myuser/distant_toto
ls -la /home/myuser/distant_tata

Conclusion

Cette solution simple et élégante résout définitivement le problème de démarrage de CloudCMD avant que les montages SSHFS ne soient prêts. Plus besoin de redémarrer manuellement le conteneur après chaque reboot du serveur !

Le conteneur wait-for-sshfs ne consomme pratiquement aucune ressource et se termine automatiquement après son attente. CloudCMD démarre ensuite avec tous ses répertoires distants correctement montés et accessibles.

Avantages de cette méthode :

  • ✅ Simple à mettre en place
  • ✅ Fonctionne avec toutes les versions de Docker Compose
  • ✅ Pas de modification du conteneur CloudCMD
  • ✅ Compatible avec tous les types de montages réseau (SSHFS, NFS, CIFS…)
  • ✅ Le délai ne s’applique qu’au démarrage de la stack, pas aux redémarrages du conteneur CloudCMD

Note : Si CloudCMD redémarre seul (crash, mise à jour…), il n’attendra pas 90 secondes puisque le conteneur wait-for-sshfs n’est lancé qu’une fois au démarrage de la stack complète.

Bon selfhosting ! 🚀