Condivisioni di Rete

Molti siti industriali conservano i propri file su un NAS o su un file server Windows nella rete locale — i risultati delle scansioni finiscono in \\nas\production, i report vengono letti da una cartella condivisa, le macchine si scambiano file tramite SMB. Un’app IronFlock può montare una condivisione di questo tipo direttamente nei propri container, così il tuo codice la legge e la scrive come una normale directory locale.

È la controparte on-premises dell’Archiviazione dei File: l’Archiviazione dei File è l’archiviazione a oggetti gestita della piattaforma, mentre una condivisione di rete è il file server del cliente sulla LAN del cliente. Usa una condivisione quando i file devono finire nell’infrastruttura esistente del cliente.

Sono supportati due protocolli: SMB/CIFS (file server Windows, praticamente ogni NAS) e NFS (comune sui server basati su Linux).

Come Funziona

Il mount viene dichiarato come volume con nome nel docker-compose.yml della tua app, usando il driver di volumi local integrato in Docker. È il motore Docker sul dispositivo a eseguire il mount quando i tuoi container si avviano — non c’è nulla da installare sul dispositivo, e l’utente del dispositivo non tocca mai una riga di comando.

L’indirizzo e le credenziali della condivisione non vengono scritti nel tuo file compose. Sono segnaposto ${VARIABLE}, valorizzati per dispositivo tramite i parametri app — lo stesso meccanismo di ogni altra impostazione per dispositivo. Gli utenti configurano la condivisione nel form Parametri dell’app su ciascun dispositivo (o una sola volta per gruppo di dispositivi), e riavviano l’app.

Dichiarare il Volume

Aggiungi al tuo docker-compose.yml un volume con nome con driver_opts e montalo nei servizi che ne hanno bisogno:

services:
  app:
    build: .
    volumes:
      - netshare:/mnt/share
    restart: unless-stopped
 
volumes:
  netshare:
    # I volumi Docker mantengono le impostazioni con cui sono stati creati.
    # Inserire il parametro di revisione nel nome del volume significa: incrementa
    # la revisione, riavvia l'app, e viene creato un volume nuovo con le
    # impostazioni correnti.
    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"

Il tuo codice lavora poi con /mnt/share come una normale directory.

Gli elementi che vale la pena capire:

APP_NAME è una delle variabili standard che la piattaforma fornisce automaticamente; circoscrive il nome del volume alla tua app.

Renderlo Configurabile

Dichiara i segnaposto in .ironflock/env-template.yml così gli utenti ottengono un vero e proprio form — con la password mascherata come segreto:

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."

Su ciascun dispositivo, l’utente compila il form nei Parametri dell’app, salva e riavvia l’app. Impostare i parametri a livello di gruppo di dispositivi configura un’intera flotta sullo stesso file server in un solo passaggio.

Modificare le Impostazioni in Seguito

Docker crea un volume la prima volta che viene usato e da quel momento ne conserva le impostazioni — modificare i soli parametri non reindirizza un volume esistente. È a questo che serve il parametro di revisione: dopo aver cambiato una qualsiasi impostazione della condivisione, l’utente aumenta la revisione di 1 e riavvia l’app. Il nuovo nome del volume fa sì che Docker crei il mount da zero con i valori correnti.

Nulla di tutto questo tocca il file server: il volume è soltanto una definizione di mount. Crearlo, ricrearlo con una nuova revisione o disinstallare l’app non elimina mai i file sulla condivisione.

NFS

Per un server NFS, lo stesso pattern con driver_opts diversi:

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 è il percorso esportato (ad es. /exports/production), addr il server. Preferisci NFSv4 (nfsvers=4) — richiede solo quest’unica opzione e nessun servizio aggiuntivo sul dispositivo.

Supporto dei Dispositivi

Sui dispositivi Windows il mount avviene all’interno dell’ambiente Linux di Docker Desktop, che include i client di entrambi i protocolli — funziona subito, incluso il raggiungimento dei server SMB sulla LAN del dispositivo. Sui dispositivi Linux i kernel delle distribuzioni standard portano già il supporto ai protocolli; non serve installare alcun pacchetto. Il supporto su FlockOS richiede un aggiornamento del sistema operativo non ancora rilasciato — contattaci se ti serve lì.

Il mount richiede un agent del dispositivo aggiornato; gli agent si aggiornano automaticamente da soli.

Da Sapere

• Dispositivi non configurati: finché i parametri non vengono compilati, l’app non riesce ad avviarsi e mostra un errore di mount nei suoi log in tempo reale. Se la tua app deve funzionare anche senza condivisione, non montarne una incondizionatamente — leggi invece i parametri nel tuo codice e salta le funzionalità che dipendono dalla condivisione.
• Credenziali: crea sul file server un account dedicato con accesso solo a questa condivisione, e usa quello nei parametri. La password è mascherata nella UI della piattaforma ma viene consegnata al dispositivo che esegue il mount — trattala come materiale locale al dispositivo, non come una credenziale di amministratore globale.
• Niente virgole nelle password: le opzioni SMB viaggiano come stringa separata da virgole, quindi una password che contiene una virgola rompe il mount. Scegli di conseguenza la password dell’account della condivisione.
• Indirizzo del server: usa un indirizzo IP o un nome che il DNS del sito risolve. I nomi mDNS come nas.local spesso non sono risolvibili dall’interno del motore Docker.
• Firewall: il dispositivo raggiunge il file server sulla porta TCP 445 (SMB) o TCP 2049 (NFS). Nelle reti di fabbrica segmentate, assicurati che quel percorso sia aperto.
• Proprietà dei file (SMB): all’interno del container i file risultano di proprietà di uid/gid indicati nelle opzioni di mount. Se il tuo processo gira come utente non root, impostali su quell’utente, altrimenti le scritture falliranno.