Recursos compartidos de red

Muchas plantas industriales guardan sus archivos en un NAS o en un servidor de archivos Windows dentro de la red local — los resultados de escaneo van a \\nas\production, los informes se leen de una carpeta compartida, las máquinas intercambian archivos por SMB. Una app de IronFlock puede montar un recurso compartido de este tipo directamente en sus contenedores, de modo que tu código lo lee y escribe como si fuera un directorio local.

Es la contraparte on-premises del Almacenamiento de archivos: el Almacenamiento de archivos es el almacenamiento de objetos gestionado de la plataforma; un recurso compartido de red es el servidor de archivos propio del cliente en su propia LAN. Usa un recurso compartido cuando los archivos deban acabar en la infraestructura existente del cliente.

Se admiten dos protocolos: SMB/CIFS (servidores de archivos Windows, prácticamente cualquier NAS) y NFS (habitual en servidores basados en Linux).

Cómo funciona

El montaje se declara como un volumen con nombre en el docker-compose.yml de tu app, usando el driver de volúmenes local integrado en Docker. El motor de Docker del dispositivo realiza el montaje por sí mismo cuando arrancan tus contenedores — no hay que instalar nada en el dispositivo, y el usuario del dispositivo nunca toca una línea de comandos.

La dirección y las credenciales del recurso compartido no se escriben en tu archivo compose. Son marcadores de posición ${VARIABLE}, que se rellenan por dispositivo desde los parámetros de la aplicación — el mismo mecanismo que cualquier otro ajuste por dispositivo. Los usuarios configuran el recurso compartido en el formulario de Parámetros de la app en cada dispositivo (o una sola vez por grupo de dispositivos) y reinician la app.

Declarar el volumen

Añade a tu docker-compose.yml un volumen con nombre con driver_opts y móntalo en los servicios que lo necesiten:

services:
  app:
    build: .
    volumes:
      - netshare:/mnt/share
    restart: unless-stopped
 
volumes:
  netshare:
    # Los volúmenes de Docker conservan los ajustes con los que se crearon. Poner
    # el parámetro de revisión en el nombre del volumen significa: incrementa la
    # revisión, reinicia la app, y se crea un volumen nuevo con los ajustes actuales.
    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"

Tu código trabaja entonces con /mnt/share como un directorio corriente.

Las piezas que conviene entender:

APP_NAME es una de las variables estándar que la plataforma proporciona automáticamente; acota el nombre del volumen al ámbito de tu app.

Hacerlo configurable

Declara los marcadores en .ironflock/env-template.yml para que los usuarios obtengan un formulario en condiciones — con la contraseña enmascarada como secreto:

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

En cada dispositivo, el usuario rellena el formulario en los Parámetros de la app, guarda y reinicia la app. Establecer los parámetros a nivel de grupo de dispositivos configura una flota entera contra el mismo servidor de archivos en un solo paso.

Cambiar los ajustes más adelante

Docker crea un volumen la primera vez que se usa y conserva sus ajustes desde ese momento — editar los parámetros por sí solo no reapunta un volumen existente. Para eso está el parámetro de revisión: después de cambiar cualquier ajuste del recurso compartido, el usuario incrementa la revisión en 1 y reinicia la app. El nuevo nombre de volumen hace que Docker cree el montaje desde cero con los valores actuales.

Nada de esto afecta al servidor de archivos: el volumen es solo una definición de montaje. Crearlo, recrearlo bajo una nueva revisión o desinstalar la app nunca elimina archivos del recurso compartido.

NFS

Para un servidor NFS, el mismo patrón con otras 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 es la ruta exportada (por ejemplo /exports/production) y addr el servidor. Prefiere NFSv4 (nfsvers=4) — solo necesita esa única opción y ningún servicio adicional en el dispositivo.

Dispositivos compatibles

En los dispositivos Windows el montaje ocurre dentro del entorno Linux de Docker Desktop, que incluye los clientes de ambos protocolos — funciona de fábrica, incluido el acceso a servidores SMB en la LAN del dispositivo. En los dispositivos Linux, los kernels de las distribuciones estándar traen el soporte de los protocolos; no hay que instalar ningún paquete. El soporte en FlockOS requiere una actualización del sistema operativo que aún no está publicada — habla con nosotros si lo necesitas allí.

El montaje requiere un agente de dispositivo actualizado; los agentes se actualizan automáticamente.

Conviene saber

• Dispositivos sin configurar: hasta que se rellenan los parámetros, la app no arranca y muestra un error de montaje en sus logs en vivo. Si tu app también debe funcionar sin recurso compartido, no montes uno incondicionalmente — lee los parámetros en tu código y omite en su lugar las funciones que dependen del recurso compartido.
• Credenciales: crea en el servidor de archivos una cuenta dedicada con acceso solo a este recurso compartido, y usa esa en los parámetros. La contraseña se enmascara en la interfaz de la plataforma, pero se entrega al dispositivo que realiza el montaje — trátala como material local del dispositivo, no como una credencial de administrador global.
• Sin comas en las contraseñas: las opciones SMB viajan como una cadena separada por comas, así que una contraseña que contenga una coma rompe el montaje. Elige la contraseña de la cuenta del recurso compartido en consecuencia.
• Dirección del servidor: usa una dirección IP o un nombre que resuelva el DNS de la planta. Los nombres mDNS como nas.local a menudo no se pueden resolver desde dentro del motor de Docker.
• Firewall: el dispositivo alcanza el servidor de archivos por TCP 445 (SMB) o TCP 2049 (NFS). En redes de fábrica segmentadas, asegúrate de que esa ruta esté abierta.
• Propiedad de los archivos (SMB): los archivos aparecen dentro del contenedor como propiedad del uid/gid de las opciones de montaje. Si tu proceso se ejecuta como un usuario no root, ajústalos a ese usuario, o las escrituras fallarán.