Netzwerkfreigaben

Viele Industriestandorte halten ihre Dateien auf einem NAS oder einem Windows-Dateiserver im lokalen Netzwerk — Scanergebnisse landen unter \\nas\production, Berichte werden aus einem freigegebenen Ordner gelesen, Maschinen tauschen Dateien über SMB aus. Eine IronFlock-App kann eine solche Freigabe direkt in ihre Container einbinden, sodass Ihr Code sie wie ein lokales Verzeichnis liest und beschreibt.

Dies ist das On-Premises-Gegenstück zum Dateispeicher: Der Dateispeicher ist der verwaltete Objektspeicher der Plattform, eine Netzwerkfreigabe ist der eigene Dateiserver des Kunden in dessen eigenem LAN. Verwenden Sie eine Freigabe, wenn die Dateien in der bestehenden Infrastruktur des Kunden landen müssen.

Zwei Protokolle werden unterstützt: SMB/CIFS (Windows-Dateiserver, praktisch jedes NAS) und NFS (verbreitet auf Linux-basierten Servern).

Funktionsweise

Der Mount wird als benanntes Volume in der docker-compose.yml Ihrer App deklariert, mit Dockers eingebautem local-Volume-Treiber. Die Docker-Engine auf dem Gerät führt das Einbinden beim Start Ihrer Container selbst durch — auf dem Gerät muss nichts installiert werden, und der Gerätenutzer kommt nie mit einer Kommandozeile in Berührung.

Adresse und Zugangsdaten der Freigabe stehen nicht in Ihrer Compose-Datei. Sie sind ${VARIABLE}-Platzhalter, die pro Gerät aus App-Parametern befüllt werden — derselbe Mechanismus wie bei jeder anderen gerätespezifischen Einstellung. Benutzer konfigurieren die Freigabe im Parameter-Formular der App auf jedem Gerät (oder einmal pro Gerätegruppe) und starten die App neu.

Das Volume deklarieren

Fügen Sie Ihrer docker-compose.yml ein benanntes Volume mit driver_opts hinzu und binden Sie es in die Services ein, die es benötigen:

services:
  app:
    build: .
    volumes:
      - netshare:/mnt/share
    restart: unless-stopped
 
volumes:
  netshare:
    # Docker-Volumes behalten die Einstellungen, mit denen sie erstellt wurden.
    # Der Revisions-Parameter im Volume-Namen bedeutet: Revision erhöhen, App neu
    # starten, und ein frisches Volume mit den aktuellen Einstellungen wird angelegt.
    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"

Ihr Code arbeitet dann mit /mnt/share wie mit einem gewöhnlichen Verzeichnis.

Die Bestandteile im Einzelnen:

APP_NAME ist eine der Standardvariablen, die die Plattform automatisch bereitstellt; sie grenzt den Volume-Namen auf Ihre App ein.

Die Freigabe konfigurierbar machen

Deklarieren Sie die Platzhalter in .ironflock/env-template.yml, damit Benutzer ein richtiges Formular erhalten — mit dem Passwort als maskiertem 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."

Auf jedem Gerät füllt der Benutzer das Formular unter den Parametern der App aus, speichert und startet die App neu. Werden die Parameter auf Gerätegruppen-Ebene gesetzt, konfiguriert das eine ganze Flotte in einem Schritt für denselben Dateiserver.

Einstellungen später ändern

Docker legt ein Volume bei der ersten Verwendung an und behält dessen Einstellungen von diesem Moment an bei — das bloße Bearbeiten der Parameter biegt ein bestehendes Volume nicht um. Genau dafür gibt es den Revisions-Parameter: Nach dem Ändern einer Freigabe-Einstellung erhöht der Benutzer die Revision um 1 und startet die App neu. Der neue Volume-Name veranlasst Docker, den Mount frisch mit den aktuellen Werten anzulegen.

Auf dem Dateiserver berührt all das nichts: Das Volume ist nur eine Mount-Definition. Weder das Anlegen, noch das Neuanlegen unter einer neuen Revision, noch das Deinstallieren der App löscht jemals Dateien auf der Freigabe.

NFS

Für einen NFS-Server gilt dasselbe Muster mit anderen driver_opts:

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 ist der exportierte Pfad (z. B. /exports/production), addr der Server. Bevorzugen Sie NFSv4 (nfsvers=4) — es kommt mit dieser einen Option aus und benötigt keine zusätzlichen Dienste auf dem Gerät.

Geräteunterstützung

Auf Windows-Geräten geschieht das Einbinden innerhalb der Linux-Umgebung von Docker Desktop, die beide Protokoll-Clients mitbringt — es funktioniert ohne weiteres Zutun, einschließlich des Zugriffs auf SMB-Server im LAN des Geräts. Auf Linux-Geräten bringen die Standardkernel der Distributionen die Protokollunterstützung mit; es müssen keine Pakete installiert werden. Die Unterstützung auf FlockOS erfordert ein Betriebssystem-Update, das noch nicht veröffentlicht ist — sprechen Sie uns an, wenn Sie sie dort benötigen.

Das Einbinden setzt einen aktuellen Geräte-Agenten voraus; Agenten aktualisieren sich automatisch selbst.

Gut zu wissen

• Unkonfigurierte Geräte: Solange die Parameter nicht ausgefüllt sind, schlägt der Start der App mit einem Mount-Fehler in ihren Live-Logs fehl. Muss Ihre App auch ohne Freigabe laufen, binden Sie sie nicht bedingungslos ein — lesen Sie stattdessen die Parameter in Ihrem Code aus und überspringen Sie die freigabeabhängigen Funktionen.
• Zugangsdaten: Legen Sie auf dem Dateiserver ein eigenes Konto an, das nur auf diese Freigabe zugreifen darf, und verwenden Sie dieses in den Parametern. Das Passwort wird in der Plattform-Oberfläche maskiert, aber an das Gerät übergeben, das den Mount durchführt — behandeln Sie es als gerätelokales Material, nicht als globale Admin-Zugangsdaten.
• Keine Kommas in Passwörtern: Die SMB-Optionen werden als kommagetrennte Zeichenkette übergeben, ein Passwort mit Komma bricht daher den Mount. Wählen Sie das Passwort des Freigabe-Kontos entsprechend.
• Serveradresse: Verwenden Sie eine IP-Adresse oder einen Namen, den das DNS des Standorts auflöst. mDNS-Namen wie nas.local sind aus der Docker-Engine heraus oft nicht auflösbar.
• Firewall: Das Gerät erreicht den Dateiserver über TCP 445 (SMB) bzw. TCP 2049 (NFS). Stellen Sie in segmentierten Fabriknetzen sicher, dass dieser Pfad offen ist.
• Dateibesitz (SMB): Dateien erscheinen im Container mit den uid/gid aus den Mount-Optionen als Eigentümer. Läuft Ihr Prozess als Nicht-Root-Benutzer, setzen Sie beide auf diesen Benutzer — andernfalls schlagen Schreibzugriffe fehl.