Informazioni sul runtime di Azure IoT Edge e la relativa architettura
Si applica a:
IoT Edge 1.4
Importante
IoT Edge 1.4 è la versione supportata. Se si usa una versione precedente, vedere Aggiornare IoT Edge.
Il runtime Azure IoT Edge è una raccolta di programmi che trasformano un dispositivo in un dispositivo IoT Edge. I componenti del runtime IoT Edge collettivamente abilitano i dispositivi IoT Edge alla ricezione del codice da eseguire sul dispositivo perimetrale e ne comunicano i risultati.
Nei dispositivi IoT Edge, il runtime IoT Edge è responsabile delle funzioni seguenti:
Installare e aggiornare i carichi di lavoro nel dispositivo.
Mantenere gli standard di sicurezza di Azure IoT Edge sul dispositivo.
Assicurarsi che i moduli IoT Edge siano sempre in esecuzione.
Segnalare l'integrità dei moduli al cloud per il monitoraggio remoto.
Gestire la comunicazione tra:
- Dispositivi downstream e dispositivi IoT Edge
- Moduli in un dispositivo IoT Edge
- Un dispositivo IoT Edge e il cloud
- Dispositivi IoT Edge
Le responsabilità del runtime di IoT Edge rientrano in due categorie: comunicazione e gestione dei moduli. Questi due ruoli vengono eseguiti da due componenti che fanno parte del runtime di IoT Edge. L'agente IoT Edge distribuisce e monitora i moduli, mentre l'hub IoT Edge è responsabile della comunicazione.
Sia l'agente IoT Edge che l'hub IoT Edge sono moduli, proprio come qualsiasi altro modulo in esecuzione in un dispositivo IoT Edge. A volte vengono definiti moduli di runtime.
Agente di IoT Edge
L'agente IoT Edge è uno dei due moduli che costituiscono il runtime di Azure IoT Edge. È responsabile della creazione di istanze dei moduli, assicurandosi che continuino a essere eseguiti e segnalando lo stato dei moduli a hub IoT. Questi dati di configurazione vengono scritti come proprietà del modulo gemello dell'agente IoT Edge.
Il daemon di sicurezza di IoT Edge avvia l'agente di IoT Edge all'avvio del dispositivo. L'agente recupera il modulo gemello dall'hub IoT e controlla il manifesto della distribuzione. Il manifesto della distribuzione è un file JSON che dichiara i moduli da avviare.
Ogni elemento nel manifesto della distribuzione contiene informazioni specifiche su un modulo e viene usato dall'agente IoT Edge per controllare il ciclo di vita del modulo. Per altre informazioni su tutte le proprietà usate dall'agente di IoT Edge per controllare i moduli, vedere Le proprietà del modulo gemello dell'agente IoT Edge e dell'hub IoT Edge.
L'agente di IoT Edge invia la risposta runtime all'hub IoT. Ecco un elenco di possibili risposte:
- 200 - OK
- 400 - La configurazione della distribuzione è in formato non corretto o non valida.
- 417 - Il dispositivo non ha un set di configurazione di distribuzione.
- 412 - La versione dello schema nella configurazione della distribuzione non è valida.
- 406 - Il dispositivo è offline o non invia segnalazioni sullo stato.
- 500 - Si è verificato un errore nel runtime di IoT Edge.
Per altre informazioni sulla creazione di manifesti di distribuzione, vedere Informazioni su come distribuire i moduli e stabilire route in IoT Edge.
Sicurezza
L'agente di IoT Edge svolge un ruolo fondamentale nella protezione di un dispositivo di IoT Edge. Ad esempio, esegue azioni come la verifica dell'immagine di un modulo prima di avviarla.
Per altre informazioni sul framework di sicurezza di Azure IoT Edge, vedere Gestione sicurezza IoT Edge.
Hub di IoT Edge
L'hub IoT Edge è l'altro modulo che costituisce il runtime di Azure IoT Edge. Opera come un proxy locale per l'hub IoT esponendo gli stessi endpoint del protocollo dell'hub IoT. Questa coerenza significa che i client possono connettersi al runtime di IoT Edge esattamente come per hub IoT.
L'hub IoT Edge non è una versione completa di hub IoT in esecuzione in locale. L'hub IoT Edge delega automaticamente alcune attività a hub IoT. Ad esempio, l'hub IoT Edge scarica automaticamente le informazioni di autorizzazione da hub IoT nella prima connessione per consentire a un dispositivo di connettersi. Dopo aver stabilito la prima connessione, le informazioni di autorizzazione vengono memorizzate nella cache in locale dall'hub IoT Edge. Le connessioni future da tale dispositivo sono autorizzate senza dover scaricare nuovamente le informazioni di autorizzazione dal cloud.
Comunicazione cloud
Per ridurre la larghezza di banda usata dalla soluzione IoT Edge, l'hub IoT Edge ottimizza il numero di connessioni effettive al cloud. L'hub IoT Edge accetta connessioni logiche da moduli o dispositivi downstream e li combina per una singola connessione fisica al cloud. I dettagli di questo processo sono trasparenti per il resto della soluzione. I client pensano di avere la propria connessione al cloud anche se vengono tutti inviati tramite la stessa connessione. L'hub IoT Edge può usare il protocollo AMQP o MQTT per comunicare upstream con il cloud, indipendentemente dai protocolli usati dai dispositivi downstream. Tuttavia, l'hub IoT Edge supporta attualmente solo la combinazione di connessioni logiche in una singola connessione fisica usando AMQP come protocollo upstream e le relative funzionalità di multiplexing. AMQP è il protocollo upstream predefinito.
L'hub di IoT Edge può determinare se è connesso all'hub IoT. Se la connessione viene persa, l'hub di IoT Edge salva i messaggi o gli aggiornamenti gemelli in locale. Quando viene ristabilita la connessione, tutti i dati vengono sincronizzati. Il percorso usato per questa cache temporanea è determinato da una proprietà del modulo gemello dell'hub IoT Edge. Le dimensioni della cache non vengono limitate e aumentano fino a quando il dispositivo ha capacità di archiviazione. Per altre informazioni, vedere Funzionalità offline.
Comunicazione locale
L'hub IoT Edge facilita la comunicazione locale. Consente comunicazioni da dispositivo a modulo e da modulo a modulo negoziando i messaggi per mantenere i dispositivi e i moduli indipendenti l'uno dall'altro. L'hub IoT Edge supporta le funzionalità di routing dei messaggi supportate da hub IoT.
Uso del routing
Il meccanismo di brokering usa le stesse funzionalità di routing di hub IoT per specificare il modo in cui i messaggi vengono passati tra dispositivi o moduli. I primi dispositivi o moduli specificano gli input in cui accettano messaggi e gli output in cui scrivono i messaggi. Uno sviluppatore di soluzioni può quindi instradare i messaggi tra un'origine (ad esempio output) e una destinazione (ad esempio, input), con potenziali filtri.
Il routing può essere usato da dispositivi o moduli creati con gli SDK per dispositivi IoT di Azure usando il protocollo AMQP. Tutte le primitive di messaggistica hub IoT (ad esempio, telemetria), i metodi diretti, C2D, gemelli, sono supportati, ma la comunicazione sugli argomenti definiti dall'utente non è supportata.
Per altre informazioni sulle route, vedere Informazioni su come distribuire i moduli e stabilire route in IoT Edge.
Funzionalità del meccanismo di brokering disponibili:
| Funzionalità | Definizione dei percorsi di trasferimento |
|---|---|
| Telemetria D2C | ✔ |
| Telemetria locale | ✔ |
| DirectMethods | ✔ |
| Gemello | ✔ |
| C2D per i dispositivi | ✔ |
| Creazione dell'ordine | ✔ |
| Filtro | ✔ |
| Argomenti definiti dall'utente | |
| Da dispositivo a dispositivo | |
| Trasmissione locale |
Connessione all'hub IoT Edge
L'hub IoT Edge accetta connessioni da client di dispositivi o moduli, tramite il protocollo MQTT o il protocollo AMQP.
Nota
L'hub di IoT Edge supporta client che si connettono tramite MQTT o AMQP. Non supporta i client che usano HTTP.
Quando un client si connette all'hub IoT Edge, si verifica quanto segue:
- Se si usa TLS (Transport Layer Security), viene creato un canale TLS per stabilire una comunicazione crittografata tra il client e l'hub IoT Edge.
- Le informazioni di autenticazione vengono inviate dal client all'hub IoT Edge per identificarsi.
- L'hub IoT Edge autorizza o rifiuta la connessione in base ai criteri di autorizzazione.
Connessioni sicure (TLS)
Per impostazione predefinita, l'hub IoT Edge accetta solo connessioni protette con Transport Layer Security (TLS), ad esempio connessioni crittografate che non possono essere decrittografate da terze parti.
Se un client si connette alla porta 8883 (MQTTS) o 5671 (AMQPS) all'hub IoT Edge, deve essere compilato un canale TLS. Durante l'handshake TLS, l'hub IoT Edge invia la catena di certificati che il client deve convalidare. Per convalidare la catena di certificati, il certificato radice dell'hub IoT Edge deve essere installato come certificato attendibile nel client. Se il certificato radice non è attendibile, la libreria client verrà rifiutata dall'hub IoT Edge con un errore di verifica del certificato.
I passaggi da seguire per installare questo certificato radice del broker nei client del dispositivo sono descritti nel gateway trasparente e nella documentazione preparare un dispositivo downstream. I moduli possono usare lo stesso certificato radice dell'hub IoT Edge usando l'API del daemon IoT Edge.
Authentication
L'hub IoT Edge accetta solo connessioni da dispositivi o moduli con un'identità hub IoT. Ad esempio, quelli registrati in hub IoT e hanno uno dei tre metodi di autenticazione client supportati dall'hub IoT per dimostrare la propria identità: autenticazione con chiavi simmetriche, autenticazione autofirmata X.509, autenticazione con firma della CA X.509. Queste identità hub IoT possono essere verificate localmente dall'hub IoT Edge in modo che le connessioni possano essere ancora effettuate offline.
I moduli IoT Edge attualmente supportano solo l'autenticazione con chiave simmetrica.
Autorizzazione
Verificando che un client appartenga al set di client attendibili definiti in hub IoT. Il set di client attendibili viene specificato configurando relazioni padre/figlio o dispositivo/modulo in hub IoT. Quando un modulo viene creato in IoT Edge, viene stabilita automaticamente una relazione di trust tra questo modulo e il relativo dispositivo IoT Edge. Si tratta dell'unico modello di autorizzazione supportato dal meccanismo di brokering di routing.
Configurazione remota
L'hub IoT Edge è interamente controllato dal cloud. Ottiene la configurazione da hub IoT tramite il modulo gemello. Il gemello contiene una proprietà desiderata denominata route che dichiara il modo in cui i messaggi vengono passati all'interno di una distribuzione. Per altre informazioni sulle route, vedere Dichiarare le route.
Inoltre, è possibile eseguire diverse configurazioni configurando le variabili di ambiente nell'hub IoT Edge.
Dati di telemetria della qualità del runtime
IoT Edge raccoglie dati di telemetria anonimi dal runtime host e dai moduli di sistema per migliorare la qualità del prodotto. Queste informazioni sono denominate dati di telemetria di qualità del runtime. I dati di telemetria raccolti vengono inviati periodicamente come messaggi da dispositivo a cloud per hub IoT dall'agente IoT Edge. Questi messaggi non vengono visualizzati nei dati di telemetria regolari del cliente e non utilizzano alcuna quota di messaggi.
L'agente IoT Edge e l'hub generano metriche che è possibile raccogliere per comprendere le prestazioni del dispositivo. Un subset di queste metriche viene raccolto dall'agente IoT Edge come parte dei dati di telemetria di qualità del runtime. Le metriche raccolte per i dati di telemetria della qualità del runtime vengono etichettate con il tag ms_telemetry. Per informazioni su tutte le metriche disponibili, vedere Accedere alle metriche predefinite.
Tutte le informazioni personali o organizzative, ad esempio i nomi dei dispositivi e dei moduli, vengono rimosse prima del caricamento per garantire la natura anonima dei dati di telemetria della qualità del runtime.
L'agente IoT Edge raccoglie i dati di telemetria ogni ora e invia un messaggio a hub IoT ogni 24 ore.
Se si vuole rifiutare esplicitamente di inviare dati di telemetria di runtime dai dispositivi, è possibile procedere in due modi:
- Impostare la
SendRuntimeQualityTelemetryvariabile di ambiente sufalseper edgeAgent o - Deselezionare l'opzione nel portale di Azure durante la distribuzione.