Configurazione Porte

Definisci quali servizi la tua app espone per l’accesso remoto creando un file port-template.yml nella directory .ironflock/.

Esempio Base

ports:
  - name: Web Interface
    port: 5000
    main: true
    protocol: https

Questo rende la porta 5000 disponibile per l’accesso remoto. L’installazione dell’app su un dispositivo di produzione ne attiva il tunnel; gli utenti con il privilegio network possono disattivarlo e riattivarlo dalle impostazioni dell’app sul loro dispositivo.

Esempio Completo

ports:
  - name: Web Interface
    port: 1100
    main: true
    protocol: http
 
  - name: Video Stream
    port: 1200
    protocol: http
 
  - name: Remote Desktop
    port: 5900
    protocol: tcp
 
  - name: LoRaWAN Gateway
    port: 1700
    protocol: udp

Riferimento Campi

Variabili d’Ambiente Iniettate

Per ogni porta che dichiari, la piattaforma inietta variabili d’ambiente nei container della tua app, così il tuo codice può scoprire dove il servizio è effettivamente raggiungibile — senza indirizzi codificati in modo fisso:

<port> è il numero di porta dichiarato in port-template.yml. Per l’esempio del Desktop Remoto qui sopra, l’app riceverebbe DEVICE_PORT_FOR_5900 e — mentre il suo tunnel è attivo — REMOTE_PORT_FOR_5900. Gli SDK IronFlock compongono l’URL di accesso remoto di una porta da queste variabili con getRemoteAccessUrlForPort. La piattaforma non imposta CLOUD_TUNNEL_DOMAIN: gli URL inoltrati tramite il cloud usano app.ironflock.com, a meno che la tua app non imposti essa stessa quella variabile.

Un’esecuzione di sviluppo, avviata con Run nell’IDE cloud, riceve un tunnel per ogni porta del template finché il suo container è in esecuzione. Solo gli utenti con il privilegio Sviluppa sul dispositivo possono aprire il tunnel di una porta http o https, e non può essere reso pubblico. Aprilo con il pulsante della porta nel menu laterale dell’IDE. Come ogni tunnel TCP e UDP, il tunnel di una porta tcp o udp non è protetto da alcun login. Parte solo dopo il container, quindi la sua porta remota non è nella variabile d’ambiente: l’agente la scrive in /data/env/REMOTE_PORT_FOR_<port>.txt finché il tunnel è attivo e rimuove il file quando il tunnel scompare. Gli SDK leggono prima quel file, quindi getRemoteAccessUrlForPort(port, 'udp') restituisce l’indirizzo dell’esecuzione di sviluppo non appena il tunnel è attivo. Rileggilo quando ti serve, perché può cambiare da un’esecuzione all’altra. Per una porta http o https, getRemoteAccessUrlForPort restituisce l’URL proprio dell’esecuzione di sviluppo, la cui etichetta termina con -dev (https://<device_key>-<app_name>-8080-dev.app.ironflock.com), quindi non entra mai in conflitto con quello dell’installazione di produzione.

Più app possono essere in esecuzione contemporaneamente sullo stesso dispositivo, quindi le porte dichiarate vengono mappate automaticamente su una porta libera del dispositivo. Componi sempre gli indirizzi di rete locale a partire dai valori iniettati invece di dare per scontata la porta dichiarata:

import os
 
lan_ip = os.environ.get("DEVICE_LAN_IP")
lan_port = os.environ.get("DEVICE_PORT_FOR_5900")
# il servizio è raggiungibile sulla rete locale all'indirizzo {lan_ip}:{lan_port}

Le variabili vengono impostate all’avvio del container. Le porte dei tunnel possono cambiare mentre l’app è in esecuzione (ad esempio quando un tunnel si riconnette), quindi le variabili delle porte dei tunnel (REMOTE_PORT_FOR_<port>, la relativa variabile _CLOUD e un nome personalizzato definito con remote_port_environment) vengono inoltre mantenute aggiornate come file in /data/env/<VARIABLE_NAME>.txt — gli SDK IronFlock li leggono automaticamente. Le altre variabili cambiano solo al riavvio del container.

L’agente del dispositivo rimuove un file _CLOUD quando la porta cloud scompare (inoltro tramite il cloud disattivato). Finché i file dell’agente sono presenti, un file _CLOUD mancante o vuoto significa quindi che non c’è alcuna porta cloud, e gli SDK non ripiegano sul valore obsoleto con cui il container è stato avviato.

Ogni utente del container può leggere questi file. Le versioni precedenti dell’agente del dispositivo rendevano /data/env leggibile solo da root: con queste, un container eseguito con un altro utente vede solo i valori con cui è stato avviato — nessuna porta di tunnel cambiata nel frattempo — e gli SDK registrano un avviso una sola volta.

Come Funzionano i Protocolli

HTTP / HTTPS

Per i servizi basati sul web. IronFlock crea un URL sul dominio del tunnel che inoltra il traffico alla porta locale del dispositivo. Gli utenti aprono l’URL nel loro browser. È privato: possono aprirlo solo gli utenti che hanno effettuato l’accesso a IronFlock e hanno accesso al dispositivo, a meno che la porta non sia impostata su Pubblico.

TCP

Per protocolli come VNC (Desktop Remoto) o connessioni socket dirette. IronFlock alloca una porta remota sul server tunnel e la espone alla tua app come REMOTE_PORT_FOR_<port>; il servizio è quindi raggiungibile all’indirizzo tcp://<TUNNEL_DOMAIN>:<remote port>.

UDP

Per protocolli come la comunicazione LoRaWAN o i tunnel VPN. Simile a TCP — viene allocata una porta remota ed esposta come REMOTE_PORT_FOR_<port>.

Incorporamento nelle Bacheche

Puoi incorporare il tunnel di accesso remoto di un dispositivo direttamente in una bacheca usando il Widget Embed. Questo crea un’esperienza fluida in cui gli utenti possono:

• Monitorare i dati globali da tutti i dispositivi
• Interagire con i singoli dispositivi attraverso interfacce web incorporate

Tutto all’interno della stessa dashboard.

L’installazione di un’app su un dispositivo di produzione attiva il tunnel di ogni porta del suo port-template.yml. I tunnel HTTP e HTTPS restano privati — possono aprirli solo gli utenti che hanno effettuato l’accesso a IronFlock e hanno accesso al dispositivo — a meno che una porta non venga impostata su Pubblico. I tunnel TCP e UDP sono porte esposte direttamente sul server tunnel, senza alcun login davanti, quindi l’app deve autenticare da sé i propri client. Gli utenti con il privilegio network sul dispositivo possono disattivare i tunnel e riattivarli; vedi Gestione Tunnel.