Udziały sieciowe

W wielu zakładach przemysłowych pliki trzymane są na serwerze NAS lub serwerze plików Windows w sieci lokalnej — wyniki skanowania trafiają do \\nas\production, raporty odczytywane są z udostępnionego folderu, maszyny wymieniają pliki przez SMB. Aplikacja IronFlock może zamontować taki udział bezpośrednio w swoich kontenerach, dzięki czemu twój kod odczytuje go i zapisuje jak zwykły katalog lokalny.

To odpowiednik on-premises Magazynu plików: Magazyn plików to zarządzany magazyn obiektów platformy, a udział sieciowy to własny serwer plików klienta w jego własnej sieci LAN. Użyj udziału, gdy pliki muszą trafiać do istniejącej infrastruktury klienta.

Obsługiwane są dwa protokoły: SMB/CIFS (serwery plików Windows, praktycznie każdy NAS) oraz NFS (powszechny na serwerach opartych na Linuksie).

Jak to działa

Montowanie deklaruje się jako nazwany wolumen w pliku docker-compose.yml aplikacji, z użyciem wbudowanego w Docker sterownika wolumenów local. Silnik Docker na urządzeniu sam wykonuje montowanie przy starcie kontenerów — na urządzeniu nie trzeba niczego instalować, a użytkownik urządzenia nigdy nie dotyka wiersza poleceń.

Adres udziału i poświadczenia nie są wpisywane do pliku compose. Są to symbole zastępcze ${VARIABLE}, wypełniane per urządzenie z parametrów aplikacji — tym samym mechanizmem co każde inne ustawienie per urządzenie. Użytkownicy konfigurują udział w formularzu Parametry aplikacji na każdym urządzeniu (lub jednorazowo per grupa urządzeń) i ponownie uruchamiają aplikację.

Deklarowanie wolumenu

Dodaj do docker-compose.yml nazwany wolumen z driver_opts i zamontuj go w usługach, które go potrzebują:

services:
  app:
    build: .
    volumes:
      - netshare:/mnt/share
    restart: unless-stopped
 
volumes:
  netshare:
    # Wolumeny Docker zachowują ustawienia, z którymi zostały utworzone.
    # Umieszczenie parametru rewizji w nazwie wolumenu oznacza: podnieś rewizję,
    # uruchom aplikację ponownie, a powstanie świeży wolumen z bieżącymi ustawieniami.
    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"

Twój kod pracuje odtąd z /mnt/share jak ze zwykłym katalogiem.

Elementy, które warto rozumieć:

APP_NAME to jedna ze standardowych zmiennych udostępnianych automatycznie przez platformę; wiąże ona nazwę wolumenu z twoją aplikacją.

Umożliwienie konfiguracji

Zadeklaruj symbole zastępcze w .ironflock/env-template.yml, aby użytkownicy otrzymali pełnoprawny formularz — z hasłem maskowanym jako sekret:

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

Na każdym urządzeniu użytkownik wypełnia formularz w sekcji Parametry aplikacji, zapisuje i ponownie uruchamia aplikację. Ustawienie parametrów na poziomie grupy urządzeń konfiguruje całą flotę względem tego samego serwera plików w jednym kroku.

Późniejsza zmiana ustawień

Docker tworzy wolumen przy pierwszym użyciu i od tej chwili zachowuje jego ustawienia — sama edycja parametrów nie przekieruje istniejącego wolumenu. Właśnie do tego służy parametr rewizji: po zmianie dowolnego ustawienia udziału użytkownik zwiększa rewizję o 1 i ponownie uruchamia aplikację. Nowa nazwa wolumenu sprawia, że Docker tworzy montowanie od nowa, z bieżącymi wartościami.

Nic z tego nie dotyka niczego na serwerze plików: wolumen to wyłącznie definicja montowania. Jego utworzenie, odtworzenie pod nową rewizją ani odinstalowanie aplikacji nigdy nie usuwa plików na udziale.

NFS

Dla serwera NFS ten sam wzorzec z innymi 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 to eksportowana ścieżka (np. /exports/production), addr — serwer. Preferuj NFSv4 (nfsvers=4) — potrzebuje tylko tej jednej opcji i żadnych dodatkowych usług na urządzeniu.

Obsługiwane urządzenia

Na urządzeniach Windows montowanie odbywa się wewnątrz linuksowego środowiska Docker Desktop, które zawiera klientów obu protokołów — działa to od razu, łącznie z dostępem do serwerów SMB w sieci LAN urządzenia. Na urządzeniach Linux obsługę protokołów zapewniają standardowe jądra dystrybucji; nie trzeba instalować żadnych pakietów. Obsługa na FlockOS wymaga aktualizacji systemu operacyjnego, która nie została jeszcze wydana — skontaktuj się z nami, jeśli potrzebujesz jej właśnie tam.

Montowanie wymaga aktualnego agenta urządzenia; agent aktualizuje się automatycznie.

Warto wiedzieć

• Nieskonfigurowane urządzenia: dopóki parametry nie zostaną wypełnione, aplikacja nie startuje, a w jej logach na żywo pojawia się błąd montowania. Jeśli twoja aplikacja ma działać także bez udziału, nie montuj go bezwarunkowo — zamiast tego odczytaj parametry w kodzie i pomiń funkcje zależne od udziału.
• Poświadczenia: utwórz na serwerze plików dedykowane konto z dostępem wyłącznie do tego udziału i użyj go w parametrach. Hasło jest maskowane w interfejsie platformy, ale trafia na urządzenie wykonujące montowanie — traktuj je jako materiał lokalny dla urządzenia, a nie jako globalne poświadczenie administratora.
• Bez przecinków w hasłach: opcje SMB przekazywane są jako ciąg rozdzielany przecinkami, więc hasło zawierające przecinek psuje montowanie. Dobierz hasło konta udziału z myślą o tym.
• Adres serwera: użyj adresu IP lub nazwy, którą rozwiązuje DNS zakładu. Nazwy mDNS takie jak nas.local często nie dają się rozwiązać z wnętrza silnika Docker.
• Zapora sieciowa: urządzenie łączy się z serwerem plików na porcie TCP 445 (SMB) lub TCP 2049 (NFS). W segmentowanych sieciach fabrycznych upewnij się, że ta ścieżka jest otwarta.
• Własność plików (SMB): pliki widoczne są w kontenerze jako należące do uid/gid z opcji montowania. Jeśli twój proces działa jako użytkownik inny niż root, ustaw je na tego użytkownika — inaczej zapisy będą kończyć się błędem.