Esercitazione: Creare una gerarchia di dispositivi IoT Edge

Si applica a: IoT Edge 1.5 IoT Edge 1.4

Questa esercitazione illustra come distribuire nodi di Azure IoT Edge in reti organizzate in livelli gerarchici. Ogni livello di una gerarchia è un dispositivo gateway che gestisce messaggi e richieste provenienti da dispositivi del livello sottostante. Questa configurazione è nota anche come edge annidato.

È possibile strutturare una gerarchia di dispositivi in modo che solo il livello superiore abbia connettività al cloud e i livelli inferiori possano comunicare solo con livelli upstream e downstream adiacenti. Questa suddivisione in livelli della rete è alla base della maggior parte delle reti industriali, che seguono lo standard ISA-95:

Questa esercitazione illustra nel dettaglio la procedura di creazione di una gerarchia di dispositivi IoT Edge, la distribuzione di contenitori di runtime IoT Edge nei dispositivi e la configurazione locale dei dispositivi. Eseguire le attività seguenti:

In questa esercitazione vengono definiti i livelli di rete seguenti:

• Livello superiore: i dispositivi IoT Edge in questo livello possono connettersi direttamente al cloud.

• Livelli inferiori: i dispositivi IoT Edge a livelli al di sotto del livello superiore non possono connettersi direttamente al cloud. Devono passare attraverso uno o più dispositivi IoT Edge intermediari per inviare e ricevere dati.

Questa esercitazione usa una gerarchia costituita da due dispositivi per semplicità. Il dispositivo di livello superiore rappresenta un dispositivo al livello superiore della gerarchia che può connettersi direttamente al cloud. Questo dispositivo viene definito dispositivo padre. Il dispositivo di livello inferiore rappresenta un dispositivo al livello inferiore della gerarchia che non può connettersi direttamente al cloud. È possibile aggiungere altri dispositivi per rappresentare l'ambiente di produzione in base alle esigenze. I dispositivi a livelli inferiori sono definiti dispositivi figlio.

Prerequisiti

Per creare una gerarchia di dispositivi IoT Edge occorre:

• Un computer (Windows o Linux) con connettività Internet.

• Un account Azure con una sottoscrizione valida. Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare.

• Un hub IoT di livello Gratuito o Standard in Azure.

• Shell Bash in Azure Cloud Shell usando l'interfaccia della riga di comando di Azure con l'estensione Azure IoT installata. Questa esercitazione usa Azure Cloud Shell. Per visualizzare le versioni correnti dei moduli e delle estensioni dell'interfaccia della riga di comando di Azure, eseguire az version.

• Due dispositivi Linux per configurare la gerarchia. Se non sono disponibili dispositivi, è possibile creare macchine virtuali di Azure per ogni dispositivo nella gerarchia usando il modello Azure Resource Manager di IoT Edge. IoT Edge versione 1.5 è preinstallato con questo modello di Resource Manager. Se si installa IoT Edge nei propri dispositivi, vedere Installare Azure IoT Edge per Linux o Aggiornare IoT Edge.

• Per semplificare la comunicazione di rete tra dispositivi, le macchine virtuali devono trovarsi nella stessa rete virtuale o usare il peering di rete virtuale.

• Assicurarsi che le porte seguenti siano aperte in ingresso per tutti i dispositivi ad eccezione del dispositivo di livello più basso: 443, 5671, 8883:

  • 443: usato tra hub perimetrali padre e figlio per le chiamate API REST e per eseguire il pull delle immagini del contenitore Docker.
  • 5671, 8883: usato per AMQP e MQTT.

  Per altre informazioni, vedere Come aprire le porte per una macchina virtuale con il portale di Azure.

  Suggerimento

  Usare l'handle SSH e l'FQDN o l'indirizzo IP di ogni macchina virtuale per la configurazione nei passaggi successivi, quindi tenere traccia di queste informazioni. È possibile trovare l'indirizzo IP e il nome di dominio completo nel portale di Azure. Per l'indirizzo IP passare all'elenco di macchine virtuali e prendere nota del campo Indirizzo IP pubblico. Per il nome di dominio completo, passare alla pagina di panoramica di ogni macchina virtuale e cercare il campo Nome DNS. Per l'handle SSH, passare alla pagina connessione di ogni macchina virtuale.

Creare la gerarchia di dispositivi IoT Edge

I dispositivi IoT Edge costituiscono i livelli della gerarchia. Questa esercitazione crea una gerarchia di due dispositivi IoT Edge: il dispositivo di livello superiore e il dispositivo di livello inferiore. È possibile creare più dispositivi downstream in base alle esigenze.

Per creare e configurare la gerarchia dei dispositivi IoT Edge, usare il comando az iot edge devices create dell'interfaccia della riga di comando di Azure. Il comando semplifica la configurazione della gerarchia automatizzando e condensando diversi passaggi:

• Crea dispositivi nell'hub IoT
• Imposta le relazioni padre-figlio per autorizzare la comunicazione tra i dispositivi
• Applica il manifesto della distribuzione a ogni dispositivo
• Genera una catena di certificati per ogni dispositivo per stabilire comunicazioni sicure tra di esse
• Genera i file di configurazione per ogni dispositivo

Creare la configurazione di un dispositivo

Si crea un gruppo di dispositivi perimetrali annidati con un dispositivo padre con un dispositivo figlio. In questa esercitazione vengono usati manifesti di distribuzione di esempio di base. Per altri esempi di scenario, esaminare i modelli di esempio di configurazione.

1. Prima di usare il comando az iot edge devices create, è necessario definire il manifesto della distribuzione per i dispositivi di livello superiore e inferiore. Scaricare il file di esempio deploymentTopLayer.json nel computer locale.

   Il manifesto della distribuzione del dispositivo di livello superiore definisce il modulo proxy dell’API IoT Edge e dichiara la route dal dispositivo di livello inferiore all'hub IoT.

2. Scaricare il file di esempio deploymentLowerLayer.json nel computer locale.

   Il manifesto della distribuzione del dispositivo di livello inferiore include il modulo del sensore di temperatura simulato e dichiara la route al dispositivo di livello superiore. Nella sezione systemModules è possibile visualizzare che i moduli di runtime sono impostati per eseguire il pull da $upstream:443, invece di mcr.microsoft.com. Il dispositivo di livello inferiore invia richieste di immagine Docker al modulo Proxy API IoT Edge sulla porta 443, perché non può eseguire direttamente il pull delle immagini dal cloud. L'altro modulo distribuito nel dispositivo di livello inferiore, il modulo Sensore temperatura simulato, effettua anche la richiesta di immagine a $upstream:443.

   Per altre informazioni su come creare un manifesto della distribuzione di livello inferiore, vedere Connettere i dispositivi Azure IoT Edge per creare una gerarchia.

3. Nella Azure Cloud Shellusare il comando dell'interfaccia della riga di comando di Azure az iot edge devices create per creare dispositivi nell'hub IoT e i bundle di configurazione per ogni dispositivo nella gerarchia. Sostituire i segnaposto seguenti con i valori appropriati:

   Segnaposto	Descrizione
   <hub-name>	Il nome dell'hub IoT.
   <config-bundle-output-path>	Percorso della cartella in cui salvare i bundle di configurazione.
   <parent-device-name>	Il nome ID dispositivo padre di livello superiore.
   <parent-deployment-manifest>	File manifesto della distribuzione del dispositivo padre.
   <parent-fqdn-or-ip>	Nome di dominio completo (FQDN) del dispositivo padre o indirizzo IP.
   <child-device-name>	Il nome ID dispositivo figlio di livello inferiore.
   <child-deployment-manifest>	File manifesto della distribuzione del dispositivo figlio.
   <child-fqdn-or-ip>	Nome di dominio completo (FQDN) del dispositivo figlio o indirizzo IP.

   az iot edge devices create \
      --hub-name <hub-name> \
      --output-path <config-bundle-output-path> \
      --default-edge-agent "mcr.microsoft.com/azureiotedge-agent:1.5" \
      --device id=<parent-device-name> \
         deployment=<parent-deployment-manifest> \
         hostname=<parent-fqdn-or-ip> \
      --device id=child-1 \
         parent=parent-1 \
         deployment=<child-deployment-manifest> \
         hostname=<child-fqdn-or-ip>
   

   Ad esempio, il comando seguente crea una gerarchia di due dispositivi IoT Edge nell'hub IoT. Un dispositivo di livello superiore denominato parent-1 e un dispositivo di livello inferiore denominato child-1*. Il comando salva i bundle di configurazione per ogni dispositivo nella directory di output. Il comando genera anche certificati di test autofirmato e li include nel bundle di configurazione. I bundle di configurazione vengono installati in ogni dispositivo usando uno script di installazione.

   az iot edge devices create \
      --hub-name my-iot-hub \
      --output-path ./output \
      --default-edge-agent "mcr.microsoft.com/azureiotedge-agent:1.5" \
      --device id=parent-1 \
         deployment=./deploymentTopLayer.json \
         hostname=10.0.0.4 \
      --device id=child-1 \
         parent=parent-1 \
         deployment=./deploymentLowerLayer.json \
         hostname=10.1.0.4
   

Dopo aver eseguito il comando, è possibile trovare i bundle di configurazione del dispositivo nella directory di output. Ad esempio:

PS C:\nested-edge\output> dir

   Directory: C:\nested-edge\output

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           4/10/2023  4:12 PM           7192 child-1.tgz
-a---           4/10/2023  4:12 PM           6851 parent-1.tgz

È possibile usare certificati e chiavi personalizzati passati come argomenti al comando o creare una gerarchia di dispositivi più complessa. Per altre informazioni sulla creazione di dispositivi annidati usando il comando az, vedere az iot edge devices create. Se non si ha familiarità con il modo in cui vengono usati i certificati in uno scenario del gateway, vedere la sezione relativa al certificato della guida pratica.

In questa esercitazione si usano argomenti inline per creare i dispositivi e i bundle di configurazione. È anche possibile usare un file di configurazione in formato YAML o JSON. Per un file di configurazione di esempio, vedere l'esempio sample_devices_config.yaml.

Configurare il runtime di IoT Edge

Oltre al provisioning dei dispositivi, i passaggi di configurazione stabiliscono comunicazioni attendibili tra i dispositivi nella gerarchia usando i certificati creati in precedenza. I passaggi iniziano anche a stabilire la struttura di rete della gerarchia. Il dispositivo di livello superiore mantiene la connettività Internet, consentendo di eseguire il pull delle immagini per il runtime dal cloud, mentre i dispositivi di livello inferiore instradano attraverso il dispositivo di livello superiore per accedere a queste immagini.

Per configurare il runtime di IoT Edge, è necessario applicare i bundle di configurazione ai dispositivi. Le configurazioni differiscono tra il dispositivo di livello superiore e un dispositivo di livello inferiore, quindi tenere presente il file di configurazione del dispositivo che si sta applicando a ogni dispositivo.

1. Copiare ogni file di archivio del bundle di configurazione nel dispositivo corrispondente. È possibile usare un'unità USB, un servizio come Azure Key Vault o una funzione come la copia sicura dei file. Scegliere uno di questi metodi che corrisponde meglio al proprio scenario.

   Ad esempio, per inviare il bundle di configurazione padre-1 alla home directory nella macchina virtuale padre-1, è possibile usare un comando simile all'esempio seguente:

   scp ./output/parent-1.tgz admin@parent-1-vm.westus.cloudapp.azure.com:~
   

2. In ogni dispositivo estrarre l'archivio del bundle di configurazione. Ad esempio, usare il comando tar per estrarre il file di archivio padre-1:

   tar -xzf ./parent-1.tgz
   

3. Impostare l'autorizzazione di esecuzione per lo script di installazione.

   chmod +x install.sh
   

4. In ogni dispositivo applicare il bundle di configurazione al dispositivo usando l'autorizzazione radice:

   sudo ./install.sh
   

   

   Per un'analisi più attenta delle modifiche apportate al file di configurazione del dispositivo, vedere Connettere i dispositivi Azure IoT Edge insieme per creare una gerarchia.

Per verificare che i dispositivi siano configurati correttamente, eseguire i controlli di configurazione e connettività nei dispositivi.

sudo iotedge check

admin@child-1-vm:~$ sudo iotedge check

Configuration checks (aziot-identity-service)
---------------------------------------------
√ keyd configuration is well-formed - OK
√ certd configuration is well-formed - OK
√ tpmd configuration is well-formed - OK
√ identityd configuration is well-formed - OK
√ daemon configurations up-to-date with config.toml - OK
√ identityd config toml file specifies a valid hostname - OK
√ host time is close to reference time - OK
√ preloaded certificates are valid - OK
√ keyd is running - OK
√ certd is running - OK
√ identityd is running - OK
√ read all preloaded certificates from the Certificates Service - OK
√ read all preloaded key pairs from the Keys Service - OK
√ check all EST server URLs utilize HTTPS - OK
√ ensure all preloaded certificates match preloaded private keys with the same ID - OK

Connectivity checks (aziot-identity-service)
--------------------------------------------
√ host can connect to and perform TLS handshake with iothub AMQP port - OK
√ host can connect to and perform TLS handshake with iothub HTTPS / WebSockets port - OK
√ host can connect to and perform TLS handshake with iothub MQTT port - OK

Configuration checks
--------------------
√ aziot-edged configuration is well-formed - OK
√ configuration up-to-date with config.toml - OK
√ container engine is installed and functional - OK
√ configuration has correct parent_hostname - OK
√ configuration has correct URIs for daemon mgmt endpoint - OK
√ container time is close to host time - OK
‼ DNS server - Warning
    Container engine is not configured with DNS server setting, which may impact connectivity to IoT Hub.
    Please see https://aka.ms/iotedge-prod-checklist-dns for best practices.
    You can ignore this warning if you are setting DNS server per module in the Edge deployment.
‼ production readiness: logs policy - Warning
    Container engine is not configured to rotate module logs which may cause it run out of disk space.
    Please see https://aka.ms/iotedge-prod-checklist-logs for best practices.
    You can ignore this warning if you are setting log policy per module in the Edge deployment.
‼ production readiness: Edge Agent's storage directory is persisted on the host filesystem - Warning
    The edgeAgent module is not configured to persist its /tmp/edgeAgent directory on the host filesystem.
    Data might be lost if the module is deleted or updated.
    Please see https://aka.ms/iotedge-storage-host for best practices.
‼ production readiness: Edge Hub's storage directory is persisted on the host filesystem - Warning
    The edgeHub module is not configured to persist its /tmp/edgeHub directory on the host filesystem.
    Data might be lost if the module is deleted or updated.
    Please see https://aka.ms/iotedge-storage-host for best practices.
√ Agent image is valid and can be pulled from upstream - OK
√ proxy settings are consistent in aziot-edged, aziot-identityd, moby daemon and config.toml - OK

Connectivity checks
-------------------
√ container on the default network can connect to upstream AMQP port - OK
√ container on the default network can connect to upstream HTTPS / WebSockets port - OK
√ container on the IoT Edge module network can connect to upstream AMQP port - OK
√ container on the IoT Edge module network can connect to upstream HTTPS / WebSockets port - OK
30 check(s) succeeded.
4 check(s) raised warnings. Re-run with --verbose for more details.
2 check(s) were skipped due to errors from other checks. Re-run with --verbose for more details.

Nel dispositivo di livello superiore, si prevede di visualizzare un output con diverse valutazioni passanti. Potrebbero essere visualizzati alcuni avvisi relativi ai criteri di log e, a seconda della rete, dei criteri DNS.

Distribuzione del modulo del dispositivo

La distribuzione del modulo per i dispositivi è stata applicata quando i dispositivi sono stati creati nell'hub IoT. Il comando az iot edge devices create ha applicato i file JSON di distribuzione per i dispositivi di livello superiore e inferiore. Al termine di queste distribuzioni, il dispositivo di livello inferiore usa il modulo Proxy API IoT Edge per eseguire il pull delle immagini necessarie.

Oltre ai moduli di runtime agente IoT Edge e hub IoT Edge, il dispositivo di livello superiore riceve il modulo del Registro di sistema Docker e il modulo Proxy dell'API IoT Edge.

Il modulo del Registro Docker punta a un Registro Azure Container esistente. In questo caso, REGISTRY_PROXY_REMOTEURL punta al Registro Contenitori Microsoft. Per impostazione predefinita, il Registro di sistema Docker è in ascolto sulla porta 5000.

Il modulo proxy dell'API IoT Edge instrada le richieste HTTP ad altri moduli, consentendo ai dispositivi di livello inferiore di eseguire il pull delle immagini del contenitore o il push dei BLOB nell'archiviazione. In questa esercitazione comunica sulla porta 443 ed è configurato per inviare la route delle richieste pull delle immagini del contenitore Docker al modulo del Registro di sistema Docker sulla porta 5000. Inoltre, tutte le richieste di caricamento dell'archiviazione BLOB instradano al modulo AzureBlobStorageonIoTEdge sulla porta 11002. Per altre informazioni sul modulo Proxy dell'API IoT Edge e su come configurarlo, vedere la guida pratica del modulo.

Per informazioni su come creare una distribuzione come questa tramite il portale di Azure o Azure Cloud Shell, vedere la sezione relativa ai dispositivi di livello superiore della guida pratica.

È possibile visualizzare lo stato dei moduli usando il comando:

az iot hub module-twin show --device-id <edge-device-id> --module-id '$edgeAgent' --hub-name <iot-hub-name> --query "properties.reported.[systemModules, modules]"

Questo comando restituisce tutte le proprietà segnalate da edgeAgent. Eccone alcuni utili per il monitoraggio dello stato del dispositivo: stato di runtime, ora di inizio del runtime, ora dell'ultima uscita del runtime, conteggio dei riavvii di runtime.

È anche possibile visualizzare lo stato dei moduli nel portale di Azure. Passare alla sezione Dispositivi dell'hub IoT per visualizzare i dispositivi e i moduli.

Visualizzare i dati generati

Il modulo Simulated Temperature Sensor ei chi è stato eseguito il push genera dati dell'ambiente di esempio. Invia messaggi che includono la temperatura e l'umidità dell'ambiente, la temperatura e la pressione dell'apparecchiatura e un timestamp.

È anche possibile visualizzarli tramite Azure Cloud Shell:

az iot hub monitor-events -n <iot-hub-name> -d <lower-layer-device-name>

Ad esempio:

az iot hub monitor-events -n my-iot-hub -d child-1

{
    "event": {
        "origin": "child-1",
        "module": "simulatedTemperatureSensor",
        "interface": "",
        "component": "",
        "payload": "{\"machine\":{\"temperature\":104.29281270901808,\"pressure\":10.48905461241978},\"ambient\":{\"temperature\":21.086561171611102,\"humidity\":24},\"timeCreated\":\"2023-04-17T21:50:30.1082487Z\"}"
    }
}

Risoluzione dei problemi

Eseguire il comando iotedge check per verificare la configurazione e risolvere gli errori.

È possibile eseguire iotedge check in una gerarchia annidata, anche se i computer downstream non hanno accesso diretto a Internet.

Quando si esegue iotedge check dal livello inferiore, il programma tenta di eseguire il pull dell'immagine dall'elemento padre attraverso la porta 443.

Il valore azureiotedge-diagnostics viene estratto dal registro contenitori collegato al modulo del registro. In questa esercitazione è impostato per impostazione predefinita su https://mcr.microsoft.com:

Se si usa un registro contenitori privato, assicurarsi che tutte le immagini (IoTEdgeAPIProxy, edgeAgent, edgeHub, Sensore temperatura simulato e diagnostica) siano presenti nel registro contenitori.

Se un dispositivo downstream ha un'architettura del processore diversa dal dispositivo padre, è necessaria l'immagine dell'architettura appropriata. È possibile usare un registro connesso oppure specificare l'immagine corretta per i moduli edgeAgent e edgeHub nel file config.toml del dispositivo downstream. Ad esempio, se il dispositivo padre è in esecuzione in un'architettura ARM32v7 e il dispositivo downstream è in esecuzione in un'architettura AMD64, è necessario specificare il tag di immagine della versione e dell'architettura corrispondente nel file del dispositivo downstream config.toml.

[agent.config]
image = "$upstream:443/azureiotedge-agent:1.5.0-linux-amd64"

"systemModules": {
   "edgeAgent": {
      "settings": {
            "image": "$upstream:443/azureiotedge-agent:1.5.0-linux-amd64"
      },
   },
   "edgeHub": {
      "settings": {
            "image": "$upstream:443/azureiotedge-hub:1.5.0-linux-amd64",
      }
   }
}

Pulire le risorse

È possibile eliminare le configurazioni locali e le risorse di Azure create in questo articolo per evitare addebiti.

Per eliminare le risorse:

1. Accedere al portale di Azure e selezionare Gruppi di risorse.

2. Selezionare il nome del gruppo di risorse contenente le risorse di test di IoT Edge.

3. Esaminare l'elenco delle risorse contenute nel gruppo di risorse. Per eliminarle tutte, è possibile selezionare Elimina gruppo di risorse. Se se ne vogliono eliminare solo alcune, è possibile selezionare ogni risorsa per eliminarle singolarmente.

Passaggi successivi

In questa esercitazione sono stati configurati due dispositivi IoT Edge come gateway, di cui uno è stato impostato come dispositivo padre dell'altro. È stato quindi eseguito il pull di un'immagine del contenitore nel dispositivo downstream tramite un gateway usando il modulo Proxy API IoT Edge. Per altre informazioni, vedere la guida pratica sull'uso del modulo proxy.

Per altre informazioni sull'uso dei gateway per creare livelli gerarchici di dispositivi IoT Edge, vedere l'articolo seguente.