Partages réseau
De nombreux sites industriels conservent leurs fichiers sur un NAS ou un serveur de fichiers Windows du réseau local — les résultats de scan partent vers \\nas\production, les rapports sont lus depuis un dossier partagé, les machines échangent des fichiers via SMB. Une application IronFlock peut monter un tel partage directement dans ses conteneurs, de sorte que votre code y lit et écrit comme dans un répertoire local.
C’est le pendant sur site du Stockage de fichiers : le Stockage de fichiers est le stockage d’objets managé de la plateforme, un partage réseau est le propre serveur de fichiers du client, sur son propre réseau local. Utilisez un partage lorsque les fichiers doivent atterrir dans l’infrastructure existante du client.
Deux protocoles sont pris en charge : SMB/CIFS (serveurs de fichiers Windows, la quasi-totalité des NAS) et NFS (courant sur les serveurs Linux).
Fonctionnement
Le montage se déclare comme un volume nommé dans le docker-compose.yml de votre application, à l’aide du pilote de volume local intégré à Docker. Le moteur Docker de l’appareil effectue lui-même le montage au démarrage de vos conteneurs — rien n’a besoin d’être installé sur l’appareil, et l’utilisateur de l’appareil ne touche jamais à une ligne de commande.
L’adresse du partage et ses identifiants ne sont pas écrits dans votre fichier compose. Ce sont des espaces réservés ${VARIABLE}, remplis par appareil depuis les paramètres d’application — le même mécanisme que pour tout autre réglage par appareil. Les utilisateurs configurent le partage dans le formulaire Paramètres de l’application sur chaque appareil (ou une seule fois par groupe d’appareils), puis redémarrent l’application.
Déclarer le volume
Ajoutez un volume nommé avec driver_opts à votre docker-compose.yml et montez-le dans les services qui en ont besoin :
services:
app:
build: .
volumes:
- netshare:/mnt/share
restart: unless-stopped
volumes:
netshare:
# Docker volumes keep the settings they were created with. Putting the
# revision parameter into the volume name means: bump the revision, restart
# the app, and a fresh volume with the current settings is created.
name: "${APP_NAME}_share_r${SHARE_REV:-1}"
driver: local
driver_opts:
type: cifs
device: "//${SHARE_HOST}/${SHARE_NAME}"
o: "username=${SHARE_USER},password=${SHARE_PASSWORD},vers=3.0,uid=1000,gid=1000"Votre code travaille ensuite avec /mnt/share comme avec un répertoire ordinaire.
Les éléments à bien comprendre :
| Champ | Signification |
|---|---|
device | L’adresse du partage : //server/sharename pour SMB |
o | Les options de montage, séparées par des virgules. vers=3.0 sélectionne la version du protocole SMB ; uid/gid déterminent quel utilisateur du conteneur possède les fichiers — faites-les correspondre à l’utilisateur sous lequel s’exécute votre processus |
name | L’identité du volume sur l’appareil. Docker ne modifie jamais un volume existant, la révision des réglages fait donc partie du nom — voir plus bas |
${VAR:-fallback} | Interpolation Compose avec valeur par défaut. Donnez à chaque espace réservé une valeur par défaut (même vide) pour que le fichier reste toujours analysable |
APP_NAME fait partie des variables standard que la plateforme fournit automatiquement ; elle rend le nom du volume propre à votre application.
Rendre le partage configurable
Déclarez les espaces réservés dans .ironflock/env-template.yml pour que les utilisateurs disposent d’un véritable formulaire — avec le mot de passe masqué comme secret :
SHARE_HOST:
label: "File server (IP or hostname)"
type: text
defaultValue: ""
description: "The SMB server or NAS on the device's local network."
SHARE_NAME:
label: "Share name"
type: text
defaultValue: ""
SHARE_USER:
label: "Username"
type: text
defaultValue: ""
SHARE_PASSWORD:
label: "Password"
type: text
secret: true
defaultValue: ""
SHARE_REV:
label: "Storage settings revision"
type: numeric
defaultValue: 1
description: "Increase by 1 whenever you change one of the settings above, then restart the app."Sur chaque appareil, l’utilisateur remplit le formulaire dans les Paramètres de l’application, enregistre, puis redémarre l’application. Définir les paramètres au niveau du groupe d’appareils configure toute une flotte sur le même serveur de fichiers en une seule étape.
Modifier les réglages par la suite
Docker crée un volume à sa première utilisation et conserve ses réglages à partir de ce moment — modifier les paramètres ne suffit pas à faire pointer ailleurs un volume existant. C’est à cela que sert le paramètre de révision : après avoir changé un réglage du partage, l’utilisateur augmente la révision de 1 et redémarre l’application. Le nouveau nom de volume amène Docker à créer un montage neuf avec les valeurs actuelles.
Rien de tout cela n’affecte le serveur de fichiers : le volume n’est qu’une définition de montage. Le créer, le recréer sous une nouvelle révision ou désinstaller l’application ne supprime jamais de fichiers sur le partage.
NFS
Pour un serveur NFS, le même schéma avec des driver_opts différents :
volumes:
netshare:
name: "${APP_NAME}_share_r${SHARE_REV:-1}"
driver: local
driver_opts:
type: nfs
device: ":${SHARE_PATH}"
o: "addr=${SHARE_HOST},nfsvers=4"SHARE_PATH est le chemin exporté (par exemple /exports/production), addr le serveur. Préférez NFSv4 (nfsvers=4) — il ne requiert que cette seule option et aucun service supplémentaire sur l’appareil.
Prise en charge par type d’appareil
| Type d’appareil | SMB/CIFS | NFS |
|---|---|---|
| Appareils Linux (installation Linux personnalisée) | ✓ | ✓ |
| Appareils Windows (Docker Desktop) | ✓ | ✓ |
| Appareils FlockOS | pas encore disponible | pas encore disponible |
Sur les appareils Windows, le montage a lieu dans l’environnement Linux de Docker Desktop, qui embarque les clients des deux protocoles — cela fonctionne d’emblée, y compris pour joindre des serveurs SMB sur le réseau local de l’appareil. Sur les appareils Linux, les noyaux des distributions standard apportent la prise en charge des protocoles ; aucun paquet n’a besoin d’être installé. La prise en charge sur FlockOS nécessite une mise à jour du système d’exploitation qui n’est pas encore publiée — contactez-nous si vous en avez besoin.
Le montage nécessite un agent d’appareil à jour ; les agents se mettent à jour automatiquement.
Bon à savoir
- Appareils non configurés : tant que les paramètres ne sont pas renseignés, l’application échoue au démarrage avec une erreur de montage dans ses journaux en temps réel. Si votre application doit aussi pouvoir fonctionner sans partage, ne montez pas le partage inconditionnellement — lisez plutôt les paramètres dans votre code et désactivez les fonctionnalités qui en dépendent.
- Identifiants : créez sur le serveur de fichiers un compte dédié n’ayant accès qu’à ce seul partage, et utilisez-le dans les paramètres. Le mot de passe est masqué dans l’interface de la plateforme mais est transmis à l’appareil qui effectue le montage — traitez-le comme un élément local à l’appareil, pas comme un identifiant d’administrateur global.
- Pas de virgule dans les mots de passe : les options SMB voyagent sous forme de chaîne séparée par des virgules ; un mot de passe contenant une virgule casse donc le montage. Choisissez le mot de passe du compte de partage en conséquence.
- Adresse du serveur : utilisez une adresse IP ou un nom que le DNS du site résout. Les noms mDNS comme
nas.localne peuvent souvent pas être résolus depuis l’intérieur du moteur Docker. - Pare-feu : l’appareil joint le serveur de fichiers sur le port TCP 445 (SMB) ou TCP 2049 (NFS). Sur les réseaux d’usine segmentés, assurez-vous que ce chemin est ouvert.
- Propriété des fichiers (SMB) : dans le conteneur, les fichiers apparaissent comme appartenant aux
uid/giddes options de montage. Si votre processus s’exécute sous un utilisateur non root, réglez-les sur cet utilisateur, sans quoi les écritures échoueront.