Självstudie: Skapa en hierarki med IoT Edge-enheter

Artikel
05/02/2024

Gäller för: IoT Edge 1.5 IoT Edge 1.4

Viktigt!

IoT Edge 1.5 LTS och IoT Edge 1.4 LTS stöds. IoT Edge 1.4 LTS upphör den 12 november 2024. Om du har en tidigare version läser du Uppdatera IoT Edge.

Du kan distribuera Azure IoT Edge-noder mellan nätverk ordnade i hierarkiska lager. Varje lager i en hierarki är en gatewayenhet som hanterar meddelanden och begäranden från enheter i lagret under den. Den här konfigurationen kallas även kapslad kant.

Du kan strukturera en hierarki med enheter så att endast det översta lagret har anslutning till molnet, och de lägre lagren kan bara kommunicera med angränsande uppströms- och nedströmslager. Den här nätverksskiktningen är grunden för de flesta industriella nätverk som följer ISA-95-standarden.

Den här självstudien beskriver hur du skapar en hierarki med IoT Edge-enheter, distribuerar IoT Edge-körningscontainrar till dina enheter och konfigurerar dina enheter lokalt. Du utför följande uppgifter:

Skapa och definiera relationerna i en hierarki med IoT Edge-enheter.
Konfigurera IoT Edge-körningen på enheterna i hierarkin.
Installera konsekventa certifikat i enhetshierarkin.
Lägg till arbetsbelastningar i enheterna i hierarkin.
Använd IoT Edge API Proxy-modulen för att på ett säkert sätt dirigera HTTP-trafik över en enda port från dina enheter på lägre nivå.

Dricks

Den här självstudien innehåller en blandning av manuella och automatiserade steg för att tillhandahålla en visning av kapslade IoT Edge-funktioner.

Om du vill ha en helt automatiserad titt på hur du konfigurerar en hierarki med IoT Edge-enheter följer du det skriptade Azure IoT Edge for Industrial IoT-exemplet. Det här skriptade scenariot distribuerar virtuella Azure-datorer som förkonfigurerade enheter för att simulera en fabriksmiljö.

Om du vill ha en djupgående titt på de manuella stegen för att skapa och hantera en hierarki med IoT Edge-enheter kan du läsa instruktionsguiden för IoT Edge-enhetsgatewayhierarkier.

I den här självstudien definieras följande nätverkslager:

Översta lagret: IoT Edge-enheter på det här lagret kan ansluta direkt till molnet.
Lägre lager: IoT Edge-enheter i lager under det översta lagret kan inte ansluta direkt till molnet. De måste gå igenom en eller flera mellanliggande IoT Edge-enheter för att skicka och ta emot data.

I den här självstudien används en tvåenhetshierarki för enkelhetens skull. Den översta lagerenheten representerar en enhet på det översta lagret i hierarkin som kan ansluta direkt till molnet. Den här enheten kallas för den överordnade enheten. Den lägre lagerenheten representerar en enhet i det nedre lagret i hierarkin som inte kan ansluta direkt till molnet. Du kan lägga till fler enheter för att representera din produktionsmiljö efter behov. Enheter i lägre lager kallas underordnade enheter.

Strukturen i självstudiehierarkin, som innehåller två enheter: den översta lagerenheten och den lägre lagerenheten

Kommentar

En underordnad enhet kan vara en underordnad enhet eller en gatewayenhet i en kapslad topologi.

Förutsättningar

Om du vill skapa en hierarki med IoT Edge-enheter behöver du:

En dator (Windows eller Linux) med internetanslutning.
Ett Azure-konto med en giltig prenumeration. Om du inte har en Azure-prenumeration kan du skapa ettkostnadsfritt konto innan du börjar.
En kostnadsfri eller standardnivå-IoT Hub i Azure.
Ett Bash-gränssnitt i Azure Cloud Shell med Azure CLI med Azure IoT-tillägget installerat. I den här självstudien används Azure Cloud Shell. Om du vill se dina aktuella versioner av Azure CLI-moduler och -tillägg kör du az version.
Två Linux-enheter för att konfigurera hierarkin. Om du inte har tillgängliga enheter kan du skapa virtuella Azure-datorer för varje enhet i hierarkin med hjälp av IoT Edge Azure Resource Manager-mallen. IoT Edge version 1.5 är förinstallerad med den här Resource Manager-mallen. Om du installerar IoT Edge på dina egna enheter kan du läsa Installera Azure IoT Edge för Linux eller Uppdatera IoT Edge.
För att förenkla nätverkskommunikationen mellan enheter bör de virtuella datorerna finnas i samma virtuella nätverk eller använda peering för virtuella nätverk.
Kontrollera att följande portar är öppna inkommande för alla enheter utom den lägsta lagerenheten: 443, 5671, 8883:
- 443: Används mellan överordnade och underordnade gränshubbar för REST API-anrop och för att hämta Docker-containeravbildningar.
- 5671, 8883: Används för AMQP och MQTT.
Mer information finns i hur du öppnar portar till en virtuell dator med Azure-portalen.

Dricks

Du använder SSH-handtaget och antingen FQDN eller IP-adressen för varje virtuell dator för konfiguration i senare steg, så håll reda på den här informationen. Du hittar IP-adressen och det fullständiga domännamnet på Azure-portalen. För IP-adressen navigerar du till din lista över virtuella datorer och noterar fältet Offentlig IP-adress. För det fullständiga domännamnet går du till varje virtuell dators översiktssida och letar efter fältet DNS-namn. För SSH-handtaget går du till varje virtuell dators anslutningssida .

Skapa IoT Edge-enhetshierarkin

IoT Edge-enheter utgör skikten i hierarkin. I den här självstudien skapas en hierarki med två IoT Edge-enheter: den översta lagerenheten och den lägre lagerenheten. Du kan skapa fler underordnade enheter efter behov.

Om du vill skapa och konfigurera hierarkin för IoT Edge-enheter använder du kommandot az iot edge devices create Azure CLI. Kommandot förenklar konfigurationen av hierarkin genom att automatisera och komprimera flera steg:

Skapar enheter i din IoT Hub
Anger överordnade och underordnade relationer för att auktorisera kommunikation mellan enheter
Tillämpar distributionsmanifestet på varje enhet
Genererar en kedja med certifikat för varje enhet för att upprätta säker kommunikation mellan dem
Genererar konfigurationsfiler för varje enhet

Skapa enhetskonfiguration

Du skapar en grupp kapslade gränsenheter med en överordnad enhet med en underordnad enhet. I den här självstudien använder vi grundläggande exempeldistributionsmanifest. Andra scenarioexempel finns i mallarna för konfigurationsexempel.

Innan du använder kommandot az iot edge devices create måste du definiera distributionsmanifestet för de översta och lägre nivåenheterna. Ladda ned deploymentTopLayer.json-exempelfilen till den lokala datorn.

Distributionsmanifestet för den översta nivån definierar IoT Edge API Proxy-modulen och deklarerar vägen från enheten på den nedre nivån till IoT Hub.
Ladda ned den deploymentLowerLayer.json exempelfilen till den lokala datorn.

Distributionsmanifestet för enhet på lägre nivå innehåller modulen för simulerad temperatursensor och deklarerar vägen till den översta lagerenheten. I avsnittet systemModules ser du att runtime-modulerna är inställda på att hämtas från $upstream:443 i stället för mcr.microsoft.com. Den lägre lagerenheten skickar Docker-avbildningsbegäranden till IoT Edge API Proxy-modulen på port 443, eftersom den inte direkt kan hämta avbildningarna från molnet. Den andra modulen som distribueras till enheten på lägre nivå, modulen Simulerad temperatursensor, gör också avbildningsbegäran till $upstream:443.

Mer information om hur du skapar ett distributionsmanifest på lägre nivå finns i Anslut Azure IoT Edge-enheter för att skapa en hierarki.

I Azure Cloud Shell använder du kommandot az iot edge create Azure CLI för att skapa enheter i IoT Hub och konfigurationspaket för varje enhet i hierarkin. Ersätt följande platshållare med lämpliga värden:

Platshållare	beskrivning
<hubbnamn>	Namnet på din IoT Hub.
<config-bundle-output-path>	Mappsökvägen där du vill spara konfigurationspaketen.
<parent-device-name>	Det överordnade enhets-ID:t på översta lagret .
<parent-deployment-manifest>	Manifestfilen för den överordnade enhetsdistributionen.
<parent-fqdn-or-ip>	Fullständigt domännamn för överordnad enhet (FQDN) eller IP-adress.
<child-device-name>	Underordnat enhets-ID för lägre lager .
<child-deployment-manifest>	Manifestfilen för den underordnade enhetsdistributionen.
<child-fqdn-or-ip>	Fullständigt domännamn för underordnad enhet (FQDN) eller IP-adress.

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>

Följande kommando skapar till exempel en hierarki med två IoT Edge-enheter i IoT Hub. En enhet på översta lagret med namnet parent-1 och en enhet med lägre lager med namnet child-1*. Kommandot sparar konfigurationspaketen för varje enhet i utdatakatalogen. Kommandot genererar också självsignerade testcertifikat och innehåller dem i konfigurationspaketet. Konfigurationspaketen installeras på varje enhet med hjälp av ett installationsskript.

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

När du har kört kommandot kan du hitta enhetskonfigurationspaketen i utdatakatalogen. Till exempel:

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

Du kan använda dina egna certifikat och nycklar som skickas som argument till kommandot eller skapa en mer komplex enhetshierarki. Mer information om hur du skapar kapslade enheter med kommandot az finns i az iot edge devices create. Om du inte känner till hur certifikat används i ett gatewayscenario kan du läsa guidens certifikatavsnitt.

I den här självstudien använder du infogade argument för att skapa enheter och konfigurationspaket. Du kan också använda en konfigurationsfil i YAML- eller JSON-format. En exempelkonfigurationsfil finns i exemplet sample_devices_config.yaml.

Konfigurera IoT Edge-körningen

Förutom etableringen av dina enheter upprättar konfigurationsstegen betrodd kommunikation mellan enheterna i hierarkin med hjälp av de certifikat som du skapade tidigare. Stegen börjar också att upprätta nätverksstrukturen i hierarkin. Den översta lagerenheten upprätthåller internetanslutningen, vilket gör att den kan hämta avbildningar för sin körning från molnet, medan enheter på lägre nivå dirigerar via den översta lagerenheten för att få åtkomst till dessa bilder.

För att konfigurera IoT Edge-körningen måste du tillämpa konfigurationspaketen på dina enheter. Konfigurationerna skiljer sig mellan den översta lagerenheten och en enhet med lägre lager, så tänk på den enhetskonfigurationsfil som du tillämpar på varje enhet.

Kopiera varje arkivfil för konfigurationspaket till motsvarande enhet. Du kan använda en USB-enhet, en tjänst som Azure Key Vault eller med en funktion som Säker filkopia. Välj någon av de här metoderna som bäst matchar ditt scenario.

Om du till exempel vill skicka konfigurationspaketet parent-1 till hemkatalogen på den virtuella datorn parent-1 kan du använda ett kommando som i följande exempel:
```
scp ./output/parent-1.tgz admin@parent-1-vm.westus.cloudapp.azure.com:~
```
Extrahera konfigurationspaketets arkiv på varje enhet. Använd till exempel tjärkommandot för att extrahera den överordnade-1-arkivfilen :
```
tar -xzf ./parent-1.tgz
```
Ange körningsbehörighet för installationsskriptet.
```
chmod +x install.sh
```
På varje enhet använder du konfigurationspaketet på enheten med rotbehörighet:
```
sudo ./install.sh
```
Om du vill titta närmare på vilka ändringar som görs i enhetens konfigurationsfil kan du läsa Anslut Azure IoT Edge-enheter tillsammans för att skapa en hierarki.

Kontrollera att enheterna är korrekt konfigurerade genom att köra konfigurations- och anslutningskontrollerna på dina enheter.

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.

På den översta lagerenheten förväntar du dig att se utdata med flera utvärderingar som skickas. Du kan se några varningar om loggprinciper och, beroende på ditt nätverk, DNS-principer.

Distribution av enhetsmodul

Moduldistributionen för dina enheter tillämpades när enheterna skapades i IoT Hub. Kommandot az iot edge devices create tillämpade JSON-distributionsfilerna för de översta och lägre nivåenheterna. När distributionerna har slutförts använder enheten på lägre nivå IoT Edge API Proxy-modulen för att hämta nödvändiga avbildningar.

Dessutom tar runtime-modulerna IoT Edge Agent och IoT Edge Hub emot den översta lagerenheten Docker-registermodulen och IoT Edge API Proxy-modulen.

Docker-registermodulen pekar på ett befintligt Azure Container Registry. I det här fallet REGISTRY_PROXY_REMOTEURL pekar på Microsoft Container Registry. Som standard lyssnar Docker-registret på port 5000.

IoT Edge API Proxy-modulen dirigerar HTTP-begäranden till andra moduler, vilket gör att enheter på lägre nivå kan hämta containeravbildningar eller push-överföra blobar till lagring. I den här självstudien kommunicerar den på port 443 och är konfigurerad för att skicka Docker-containeravbildningens pull-begäranden till docker-registermodulen på port 5000. Dessutom dirigerar alla bloblagringsöverföringsbegäranden till modulen AzureBlobStorageonIoTEdge på port 11002. Mer information om IoT Edge API Proxy-modulen och hur du konfigurerar den finns i modulens instruktioner.

Om du vill se hur du skapar en distribution som den här via Azure-portalen eller Azure Cloud Shell kan du läsa avsnittet enhet på översta nivån i guiden.

Du kan visa status för dina moduler med hjälp av kommandot :

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

Det här kommandot matar ut alla rapporterade egenskaper för edgeAgent. Här följer några användbara exempel för att övervaka enhetens status: körningsstatus, körningsstarttid, körnings senaste sluttid, antal omstarter av körning.

Du kan också se statusen för dina moduler på Azure-portalen. Gå till avsnittet Enheter i din IoT Hub för att se dina enheter och moduler.

Visa genererade data

Modulen Simulerad temperatursensor som du pushade genererar exempelmiljödata. Den skickar meddelanden som innehåller omgivningstemperatur och luftfuktighet, maskintemperatur och tryck samt en tidsstämpel.

Du kan också visa dessa meddelanden via Azure Cloud Shell:

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

Till exempel:

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\"}"
    }
}

Felsökning

iotedge check Kör kommandot för att verifiera konfigurationen och för att felsöka fel.

Du kan köra iotedge check i en kapslad hierarki, även om de underordnade datorerna inte har direkt internetåtkomst.

När du kör iotedge check från det nedre lagret försöker programmet hämta avbildningen från den överordnade via port 443.

Värdet azureiotedge-diagnostics hämtas från containerregistret som är länkat till registermodulen. Den här självstudien har angetts som standard till https://mcr.microsoft.com:

Name	Värde
`REGISTRY_PROXY_REMOTEURL`	`https://mcr.microsoft.com`

Om du använder ett privat containerregister kontrollerar du att alla avbildningar (IoTEdgeAPIProxy, edgeAgent, edgeHub, Simulerad temperatursensor och diagnostik) finns i containerregistret.

Om en nedströmsenhet har en annan processorarkitektur än den överordnade enheten behöver du lämplig arkitekturbild. Du kan använda ett anslutet register eller ange rätt avbildning för edgeAgent - och edgeHub-modulerna i den nedströms filen config.toml . Om den överordnade enheten till exempel körs på en ARM32v7-arkitektur och den underordnade enheten körs i en AMD64-arkitektur måste du ange taggen matchande version och arkitekturbild i filen config.toml för nedströmsenheten.

[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",
      }
   }
}

Rensa resurser

Du kan ta bort de lokala konfigurationerna och De Azure-resurser som du skapade i den här artikeln för att undvika avgifter.

Ta bort resurser:

Logga in på Azure Portal och välj Resursgrupper.
Välj namnet på resursgruppen som innehåller dina IoT Edge-testresurser.
Granska listan över resurser som ingår i din resursgrupp. Om du vill ta bort alla kan du välja Ta bort resursgrupp. Om du bara vill ta bort några av dem kan du välja varje resurs för att ta bort dem individuellt.

Nästa steg

I den här självstudien konfigurerade du två IoT Edge-enheter som gatewayer och anger en som den överordnade enheten för den andra. Sedan hämtade du en containeravbildning till den underordnade enheten via en gateway med hjälp av modulen IoT Edge API Proxy. Se instruktionsguiden för proxymodulens användning om du vill veta mer.

Mer information om hur du använder gatewayer för att skapa hierarkiska lager av IoT Edge-enheter finns i följande artikel.

Anslut Azure IoT Edge-enheter för att skapa en hierarki

Dela via