Skip to Content
Desenvolvimento de Apps IoTCompartilhamentos de rede

Compartilhamentos de Rede

Muitas plantas industriais guardam seus arquivos em um NAS ou em um servidor de arquivos Windows na rede local — resultados de scans vão para \\nas\production, relatórios são lidos de uma pasta compartilhada, máquinas trocam arquivos via SMB. Um app IronFlock pode montar um compartilhamento desses diretamente nos seus containers, de modo que o seu código lê e escreve nele como em um diretório local.

Este é o equivalente on-premises do Armazenamento de Arquivos: o Armazenamento de Arquivos é o armazenamento de objetos gerenciado da plataforma; um compartilhamento de rede é o servidor de arquivos do próprio cliente, na LAN do próprio cliente. Use um compartilhamento quando os arquivos precisam chegar à infraestrutura existente do cliente.

Dois protocolos são suportados: SMB/CIFS (servidores de arquivos Windows, praticamente todo NAS) e NFS (comum em servidores baseados em Linux).

Como Funciona

A montagem é declarada como um volume nomeado no docker-compose.yml do seu app, usando o driver de volume local embutido no Docker. O engine do Docker no dispositivo realiza a montagem por conta própria quando os seus containers iniciam — nada precisa ser instalado no dispositivo, e o usuário do dispositivo nunca toca em uma linha de comando.

O endereço e as credenciais do compartilhamento não são escritos no seu arquivo compose. Eles são placeholders ${VARIABLE}, preenchidos por dispositivo a partir dos parâmetros do app — o mesmo mecanismo de qualquer outra configuração por dispositivo. Os usuários configuram o compartilhamento no formulário Parameters do app em cada dispositivo (ou uma única vez por grupo de dispositivos) e reiniciam o app.

Declarando o Volume

Adicione um volume nomeado com driver_opts ao seu docker-compose.yml e monte-o nos serviços que precisam dele:

services: app: build: . volumes: - netshare:/mnt/share restart: unless-stopped volumes: netshare: # Volumes Docker mantêm as configurações com as quais foram criados. Colocar o # parâmetro de revisão no nome do volume significa: incremente a revisão, reinicie # o app, e um volume novo com as configurações atuais é criado. 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"

O seu código então trabalha com /mnt/share como um diretório comum.

As partes que valem a pena entender:

CampoSignificado
deviceO endereço do compartilhamento: //server/sharename para SMB
oOpções de montagem, separadas por vírgula. vers=3.0 seleciona a versão do protocolo SMB; uid/gid decidem qual usuário do container é dono dos arquivos — alinhe-os ao usuário com o qual o seu processo roda
nameA identidade do volume no dispositivo. O Docker nunca altera um volume existente, então a revisão das configurações faz parte do nome — veja abaixo
${VAR:-fallback}Interpolação do Compose com um valor padrão. Dê a cada placeholder um padrão (mesmo que vazio) para que o arquivo sempre possa ser interpretado

APP_NAME é uma das variáveis padrão que a plataforma fornece automaticamente; ela restringe o nome do volume ao escopo do seu app.

Tornando o Compartilhamento Configurável

Declare os placeholders em .ironflock/env-template.yml para que os usuários recebam um formulário adequado — com a senha mascarada como segredo:

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

Em cada dispositivo, o usuário preenche o formulário em Parameters do app, salva e reinicia o app. Definir os parâmetros no nível do grupo de dispositivos configura uma frota inteira para o mesmo servidor de arquivos em um único passo.

Alterando as Configurações Mais Tarde

O Docker cria um volume na primeira vez em que ele é usado e mantém suas configurações daquele momento em diante — editar os parâmetros, por si só, não redireciona um volume existente. É para isso que serve o parâmetro de revisão: depois de alterar qualquer configuração do compartilhamento, o usuário aumenta a revisão em 1 e reinicia o app. O novo nome de volume faz o Docker criar a montagem do zero com os valores atuais.

Nada no servidor de arquivos é afetado por isso: o volume é apenas uma definição de montagem. Criá-lo, recriá-lo sob uma nova revisão ou desinstalar o app nunca exclui arquivos no compartilhamento.

NFS

Para um servidor NFS, o mesmo padrão com driver_opts diferentes:

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 é o caminho exportado (por exemplo, /exports/production), e addr é o servidor. Prefira NFSv4 (nfsvers=4) — ele precisa apenas dessa única opção e de nenhum serviço extra no dispositivo.

Suporte por Dispositivo

Tipo de dispositivoSMB/CIFSNFS
Dispositivos Linux (instalação Linux personalizada)
Dispositivos Windows (Docker Desktop)
Dispositivos FlockOSainda não disponívelainda não disponível

Em dispositivos Windows, a montagem acontece dentro do ambiente Linux do Docker Desktop, que já traz os clientes dos dois protocolos — funciona de imediato, inclusive para alcançar servidores SMB na LAN do dispositivo. Em dispositivos Linux, os kernels das distribuições padrão trazem o suporte aos protocolos; nenhum pacote precisa ser instalado. O suporte no FlockOS requer uma atualização do sistema operacional que ainda não foi lançada — fale conosco se você precisar dele lá.

A montagem requer um agente de dispositivo atualizado; os agentes se atualizam automaticamente.

Vale a Pena Saber

  • Dispositivos não configurados: até que os parâmetros sejam preenchidos, o app falha ao iniciar com um erro de montagem nos seus logs ao vivo. Se o seu app também precisa rodar sem um compartilhamento, não monte um incondicionalmente — em vez disso, leia os parâmetros no seu código e pule os recursos que dependem do compartilhamento.
  • Credenciais: crie no servidor de arquivos uma conta dedicada com acesso apenas a esse compartilhamento e use essa conta nos parâmetros. A senha é mascarada na interface da plataforma, mas é entregue ao dispositivo que realiza a montagem — trate-a como material local do dispositivo, não como uma credencial de administrador global.
  • Sem vírgulas em senhas: as opções SMB viajam como uma string separada por vírgulas, então uma senha que contenha uma vírgula quebra a montagem. Escolha a senha da conta do compartilhamento levando isso em conta.
  • Endereço do servidor: use um endereço IP ou um nome que o DNS da planta resolva. Nomes mDNS como nas.local muitas vezes não são resolvíveis de dentro do engine do Docker.
  • Firewall: o dispositivo alcança o servidor de arquivos pela porta TCP 445 (SMB) ou TCP 2049 (NFS). Em redes de fábrica segmentadas, garanta que esse caminho esteja aberto.
  • Propriedade dos arquivos (SMB): os arquivos aparecem dentro do container como pertencentes ao uid/gid das opções de montagem. Se o seu processo roda como um usuário não root, defina-os para esse usuário, ou as escritas falharão.
Last updated on