Anslut Azure IoT Edge-enheter för att skapa en hierarki
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.
Den här artikeln innehåller steg för att upprätta en betrodd anslutning mellan en IoT Edge-gateway och en underordnad IoT Edge-enhet. Den här konfigurationen kallas även kapslad kant.
I ett gatewayscenario kan en IoT Edge-enhet vara både en gateway och en nedströmsenhet. Flera IoT Edge-gatewayer kan lagerföras för att skapa en hierarki med enheter. Underordnade enheter (underordnade) kan autentisera och skicka eller ta emot meddelanden via sin gatewayenhet (överordnad).
Det finns två olika konfigurationer för IoT Edge-enheter i en gatewayhierarki, och den här artikeln behandlar båda. Den första är IoT Edge-enheten på översta lagret . När flera IoT Edge-enheter ansluter via varandra anses alla enheter som inte har en överordnad enhet men som ansluter direkt till IoT Hub vara i det översta lagret. Den här enheten ansvarar för att hantera begäranden från alla enheter under den. Den andra konfigurationen gäller för alla IoT Edge-enheter i ett lägre lager i hierarkin. Dessa enheter kan vara en gateway för andra underordnade IoT- och IoT Edge-enheter, men de måste också dirigera all kommunikation via sina egna överordnade enheter.
Vissa nätverksarkitekturer kräver att endast den översta IoT Edge-enheten i en hierarki kan ansluta till molnet. I den här konfigurationen kan alla IoT Edge-enheter i lägre lager i en hierarki bara kommunicera med sin gatewayenhet (överordnad) och eventuella underordnade enheter (underordnade).
Alla steg i den här artikeln bygger på Konfigurera en IoT Edge-enhet för att fungera som en transparent gateway, som konfigurerar en IoT Edge-enhet som en gateway för underordnade IoT-enheter. Samma grundläggande steg gäller för alla gatewayscenarier:
- Autentisering: Skapa IoT Hub-identiteter för alla enheter i gatewayhierarkin.
- Auktorisering: Konfigurera den överordnade/underordnade relationen i IoT Hub för att auktorisera underordnade enheter att ansluta till sin överordnade enhet på samma sätt som de skulle ansluta till IoT Hub.
- Gatewayidentifiering: Se till att den underordnade enheten kan hitta sin överordnade enhet i det lokala nätverket.
- Säker anslutning: Upprätta en säker anslutning med betrodda certifikat som ingår i samma kedja.
Förutsättningar
- En kostnadsfri eller standard-IoT-hubb.
- Minst två IoT Edge-enheter, en som ska vara den översta lagerenheten och en eller flera enheter på lägre nivå. Om du inte har tillgängliga IoT Edge-enheter kan du köra Azure IoT Edge på virtuella Ubuntu-datorer.
- Om du använder Azure CLI för att skapa och hantera enheter installerar du Azure IoT-tillägget.
Dricks
Den här artikeln innehåller detaljerade steg och alternativ som hjälper dig att skapa rätt gatewayhierarki för ditt scenario. En guidad självstudiekurs finns i Skapa en hierarki med IoT Edge-enheter med hjälp av gatewayer.
Skapa en gatewayhierarki
Du skapar en IoT Edge-gatewayhierarki genom att definiera överordnade/underordnade relationer för IoT Edge-enheterna i scenariot. Du kan ange en överordnad enhet när du skapar en ny enhetsidentitet, eller så kan du hantera över- och underordnade enheter för en befintlig enhetsidentitet.
Steget för att konfigurera överordnade/underordnade relationer ger underordnade enheter behörighet att ansluta till sin överordnade enhet på samma sätt som de skulle ansluta till IoT Hub.
Endast IoT Edge-enheter kan vara överordnade enheter, men både IoT Edge-enheter och IoT-enheter kan vara underordnade. En överordnad kan ha många barn, men ett underordnat barn kan bara ha en överordnad. En gatewayhierarki skapas genom att överordnade/underordnade uppsättningar länkas samman så att underordnad till en enhet är överordnad till en annan.
Som standard kan en överordnad enhet ha upp till 100 underordnade enheter. Du kan ändra den här gränsen genom att ange miljövariabeln MaxConnectedClients i den överordnade enhetens edgeHub-modul.
I Azure-portalen kan du hantera den överordnade/underordnade relationen när du skapar nya enhetsidentiteter eller genom att redigera befintliga enheter.
När du skapar en ny IoT Edge-enhet kan du välja överordnade och underordnade enheter från listan över befintliga IoT Edge-enheter i hubben.
- I Azure Portal, navigerar du till din IoT-hubb.
- Välj Enheter under menyn Enhetshantering .
- Välj Lägg till enhet och markera kryssrutan IoT Edge-enhet .
- Förutom att ange enhets-ID och autentiseringsinställningar kan du ange en överordnad enhet eller Välj underordnade enheter.
- Välj den enhet eller de enheter som du vill använda som överordnad eller underordnad.
Du kan också skapa eller hantera överordnade/underordnade relationer för befintliga enheter.
- I Azure Portal, navigerar du till din IoT-hubb.
- Välj Enheter på menyn Enhetshantering .
- Välj den IoT Edge-enhet som du vill hantera i listan.
- Välj kugghjulsikonen Ange en överordnad enhet eller Hantera underordnade enheter.
- Lägg till eller ta bort överordnade eller underordnade enheter.
Kommentar
Om du vill upprätta överordnade och underordnade relationer programmatiskt kan du använda C#, Java eller Node.js IoT Hub Service SDK.
Här är ett exempel på hur du tilldelar underordnade enheter med hjälp av C#SDK. Uppgiften RegistryManager_AddAndRemoveDeviceWithScope()
visar hur du programmatiskt skapar en hierarki med tre lager. En IoT Edge-enhet är i lager ett, som överordnad. En annan IoT Edge-enhet finns i lager två och fungerar som både underordnad och överordnad. Slutligen finns en IoT-enhet i lager tre, som den underordnade enheten på det lägsta lagret.
Generera certifikat
En konsekvent kedja av certifikat måste installeras mellan enheter i samma gatewayhierarki för att upprätta en säker kommunikation mellan dem. Varje enhet i hierarkin, oavsett om det är en IoT Edge-enhet eller en IoT-underordnad enhet, behöver en kopia av samma rotcertifikatutfärdarcertifikat. Varje IoT Edge-enhet i hierarkin använder sedan rotcertifikatutfärdarcertifikatet som rot för sitt Edge CA-certifikat.
Med den här konfigurationen kan varje underordnad IoT Edge-enhet verifiera identiteten för sin överordnade genom att verifiera att edgeHub som de ansluter till har ett servercertifikat som är signerat av det delade rotcertifikatutfärdarcertifikatet.
Mer information om IoT Edge-certifikatkrav finns i Förstå hur Azure IoT Edge använder certifikat.
Skapa eller begär följande certifikat:
- Ett rotcertifikatutfärdarcertifikat, som är det översta delade certifikatet för alla enheter i en viss gatewayhierarki. Det här certifikatet är installerat på alla enheter.
- Eventuella mellanliggande certifikat som du vill inkludera i rotcertifikatkedjan.
- Ett Edge CA-certifikat och dess privata nyckel som genereras av rotcertifikaten och mellanliggande certifikat. Du behöver ett unikt Edge CA-certifikat för varje IoT Edge-enhet i gatewayhierarkin.
Du kan använda antingen en självsignerad certifikatutfärdare eller köpa en från en betrodd kommersiell certifikatutfärdare som Baltimore, Verisign, Digicert eller GlobalSign.
Om du inte har egna certifikat att använda för testning skapar du en uppsättning rotcertifikat och mellanliggande certifikat och skapar sedan Edge CA-certifikat för varje enhet. I den här artikeln använder vi testcertifikat som genereras med hjälp av certifikatutfärdarcertifikat för test för exempel och självstudier. Följande kommandon skapar till exempel ett rotcertifikatutfärdarcertifikat, ett överordnat enhetscertifikat och ett underordnat enhetscertifikat.
# !!! For test only - do not use in production !!! # Create the the root CA test certificate ./certGen.sh create_root_and_intermediate # Create the parent (gateway) device test certificate # signed by the shared root CA certificate ./certGen.sh create_edge_device_ca_certificate "gateway" # Create the downstream device test certificate # signed by the shared root CA certificate ./certGen.sh create_edge_device_ca_certificate "downstream"
Varning
Använd inte certifikat som skapats av testskripten för produktion. De innehåller hårdkodade lösenord och upphör som standard efter 30 dagar. Certifikatutfärdarcertifikatutfärdartestet tillhandahålls i demonstrationssyfte för att hjälpa dig att förstå CA-certifikat. Använd dina egna rekommenderade säkerhetsmetoder för att skapa certifieringar och livslängdshantering i produktion.
Mer information om hur du skapar testcertifikat finns i Skapa democertifikat för att testa IoT Edge-enhetsfunktioner.
Du måste överföra certifikaten och nycklarna till varje 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. Kopiera filerna till önskad katalog för certifikat och nycklar. Använd
/var/aziot/certs
för certifikat och/var/aziot/secrets
för nycklar.
Mer information om hur du installerar certifikat på en enhet finns i Hantera certifikat på en IoT Edge-enhet.
Konfigurera överordnad enhet
Om du vill konfigurera den överordnade enheten öppnar du ett lokalt kommandogränssnitt eller ett fjärrkommandogränssnitt.
För att aktivera säkra anslutningar måste varje överordnad IoT Edge-enhet i ett gatewayscenario konfigureras med ett unikt Edge CA-certifikat och en kopia av rotcertifikatutfärdarcertifikatet som delas av alla enheter i gatewayhierarkin.
Kontrollera att dina certifikat uppfyller formatkraven.
Överför rotcertifikatutfärdarcertifikatet, det överordnade Edge CA-certifikatet och den överordnade privata nyckeln till den överordnade enheten.
Kopiera certifikaten och nycklarna till rätt kataloger. De önskade katalogerna för enhetscertifikat är
/var/aziot/certs
för certifikaten och/var/aziot/secrets
för nycklar.### Copy device certificate ### # If the device certificate and keys directories don't exist, create, set ownership, and set permissions sudo mkdir -p /var/aziot/certs sudo chown aziotcs:aziotcs /var/aziot/certs sudo chmod 755 /var/aziot/certs sudo mkdir -p /var/aziot/secrets sudo chown aziotks:aziotks /var/aziot/secrets sudo chmod 700 /var/aziot/secrets # Copy full-chain device certificate and private key into the correct directory sudo cp iot-edge-device-ca-gateway-full-chain.cert.pem /var/aziot/certs sudo cp iot-edge-device-ca-gateway.key.pem /var/aziot/secrets ### Root certificate ### # Copy root certificate into the /certs directory sudo cp azure-iot-test-only.root.ca.cert.pem /var/aziot/certs # Copy root certificate into the CA certificate directory and add .crt extension. # The root certificate must be in the CA certificate directory to install it in the certificate store. # Use the appropriate copy command for your device OS or if using EFLOW. # For Ubuntu and Debian, use /usr/local/share/ca-certificates/ sudo cp azure-iot-test-only.root.ca.cert.pem /usr/local/share/azure-iot-test-only.root.ca.cert.pem.crt # For EFLOW, use /etc/pki/ca-trust/source/anchors/ sudo cp azure-iot-test-only.root.ca.cert.pem /etc/pki/ca-trust/source/anchors/azure-iot-test-only.root.ca.pem.crt
Ändra ägarskap och behörigheter för certifikaten och nycklarna.
# Give aziotcs ownership to certificates # Read and write for aziotcs, read-only for others sudo chown -R aziotcs:aziotcs /var/aziot/certs sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \; # Give aziotks ownership to private keys # Read and write for aziotks, no permission for others sudo chown -R aziotks:aziotks /var/aziot/secrets sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \; # Verify permissions of directories and files sudo ls -Rla /var/aziot
Utdata från listan med rätt ägarskap och behörighet liknar följande:
azureUser@vm:/var/aziot$ sudo ls -Rla /var/aziot /var/aziot: total 16 drwxr-xr-x 4 root root 4096 Dec 14 00:16 . drwxr-xr-x 15 root root 4096 Dec 14 00:15 .. drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 certs drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 secrets /var/aziot/certs: total 20 drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 . drwxr-xr-x 4 root root 4096 Dec 14 00:16 .. -rw-r--r-- 1 aziotcs aziotcs 1984 Jan 14 00:24 azure-iot-test-only.root.ca.cert.pem -rw-r--r-- 1 aziotcs aziotcs 5887 Jan 14 00:27 iot-edge-device-ca-gateway-full-chain.cert.pem /var/aziot/secrets: total 16 drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 . drwxr-xr-x 4 root root 4096 Dec 14 00:16 .. -rw------- 1 aziotks aziotks 3243 Jan 14 00:28 iot-edge-device-ca-gateway.key.pem
Installera rotcertifikatutfärdarcertifikatet på den överordnade IoT Edge-enheten genom att uppdatera certifikatarkivet på enheten med hjälp av det plattformsspecifika kommandot.
# Update the certificate store # For Ubuntu or Debian - use update-ca-certificates sudo update-ca-certificates # For EFLOW or RHEL - use update-ca-trust sudo update-ca-trust
Mer information om hur du använder
update-ca-trust
i EFLOW finns i CBL-Mariner SSL CA-certifikathantering.
Kommandot rapporterar att ett certifikat har lagts till i /etc/ssl/certs
.
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Uppdatera den överordnade konfigurationsfilen
Du bör redan ha IoT Edge installerat på enheten. Om inte följer du stegen för att manuellt etablera en enda Linux IoT Edge-enhet.
Kontrollera att konfigurationsfilen
/etc/aziot/config.toml
finns på den överordnade enheten.Om konfigurationsfilen inte finns på enheten använder du följande kommando för att skapa den baserat på mallfilen:
sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
Du kan också använda mallfilen som referens för att lägga till konfigurationsparametrar i det här avsnittet.
Öppna IoT Edge-konfigurationsfilen med hjälp av ett redigeringsprogram. Använd till exempel redigeraren
nano
för att öppna/etc/aziot/config.toml
filen.sudo nano /etc/aziot/config.toml
Leta upp parametern värdnamn eller lägg till den i början av konfigurationsfilen. Uppdatera värdet till det fullständigt kvalificerade domännamnet (FQDN) eller IP-adressen för den överordnade IoT Edge-enheten. Till exempel:
hostname = "10.0.0.4"
För att aktivera gatewayidentifiering måste varje IoT Edge-gateway (överordnad) enhet ange en värdnamnsparameter som dess underordnade enheter ska använda för att hitta den i det lokala nätverket. Varje underordnade IoT Edge-enhet måste ange en parent_hostname parameter för att identifiera dess överordnade. I ett hierarkiskt scenario där en enda IoT Edge-enhet är både en överordnad och en underordnad enhet behöver den båda parametrarna.
Parametrarna värdnamn och trust_bundle_cert måste finnas i början av konfigurationsfilen före några avsnitt. Genom att lägga till parametern före definierade avsnitt ser du till att den tillämpas korrekt.
Använd ett värdnamn som är kortare än 64 tecken, vilket är teckengränsen för ett gemensamt servercertifikatnamn.
Var konsekvent med värdnamnsmönstret i en gatewayhierarki. Använd antingen FQDN eller IP-adresser, men inte båda. FQDN eller IP-adress krävs för att ansluta underordnade enheter.
Ange värdnamnet innan edgeHub-containern skapas. Om edgeHub körs börjar det inte gälla att ändra värdnamnet i konfigurationsfilen förrän containern har återskapats. Mer information om hur du verifierar att värdnamnet tillämpas finns i avsnittet verifiera överordnad konfiguration .
Leta upp certifikatparametern Förtroendepaket eller lägg till den i början av konfigurationsfilen.
Uppdatera parametern
trust_bundle_cert
med fil-URI:n till rotcertifikatutfärdarcertifikatet på enheten. Till exempel:trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
Leta upp eller lägg till avsnittet Edge CA-certifikat i konfigurationsfilen. Uppdatera certifikat-
cert
och privata nyckelparametrarnapk
med fil-URI-sökvägarna för det fullständiga certifikatet och nyckelfilerna på den överordnade IoT Edge-enheten. IoT Edge kräver att certifikatet och den privata nyckeln är i textbaserat PEM-format (privacy-enhanced mail). Till exempel:[edge_ca] cert = "file:///var/aziot/certs/iot-edge-device-ca-gateway-full-chain.cert.pem" pk = "file:///var/aziot/secrets/iot-edge-device-ca-gateway.key.pem"
Kontrollera att din IoT Edge-enhet använder rätt version av IoT Edge-agenten när den startas. Leta upp avsnittet Default Edge Agent och ange avbildningsvärdet för IoT Edge till version 1.5. Till exempel:
[agent] name = "edgeAgent" type = "docker" [agent.config] image = "mcr.microsoft.com/azureiotedge-agent:1.5"
Början av den överordnade konfigurationsfilen bör se ut ungefär som i följande exempel.
hostname = "10.0.0.4" trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem" [edge_ca] cert = "file:///var/aziot/certs/iot-edge-device-ca-gateway-full-chain.cert.pem" pk = "file:///var/aziot/secrets/iot-edge-device-ca-gateway.key.pem"
Spara och stäng konfigurationsfilen
config.toml
. Om du till exempel använder nanoredigeraren väljer du Ctrl+O - Skriv ut, Retur och Ctrl+X - Avsluta.Om du har använt andra certifikat för IoT Edge tidigare tar du bort filerna i följande två kataloger för att se till att dina nya certifikat tillämpas:
/var/lib/aziot/certd/certs
/var/lib/aziot/keyd/keys
Tillämpa ändringarna.
sudo iotedge config apply
Kontrollera om det finns några fel i konfigurationen.
sudo iotedge check --verbose
Kommentar
På en nyligen etablerad enhet kan du se ett fel som rör IoT Edge Hub:
× produktionsberedskap: Edge Hubs lagringskatalog sparas i värdfilsystemet – Fel
Det gick inte att kontrollera det aktuella tillståndet för edgeHub-containern
Det här felet förväntas på en nyligen etablerad enhet eftersom IoT Edge Hub-modulen inte körs. Lös felet genom att ange modulerna för enheten i IoT Hub och skapa en distribution. När du skapar en distribution för enheten startas modulerna på enheten, inklusive IoT Edge Hub-modulen.
Verifiera överordnad konfiguration
Värdnamnet måste vara ett kvalificerat domännamn (FQDN) eller IP-adressen för IoT Edge-enheten eftersom IoT Edge använder det här värdet i servercertifikatet när underordnade enheter ansluter. Värdena måste matcha eller så får du felmatchningsfel för IP-adressen.
För att verifiera värdnamnet måste du inspektera miljövariablerna för edgeHub-containern .
Visa en lista över IoT Edge-containrar som körs.
iotedge list
Kontrollera att edgeAgent - och edgeHub-containrar körs. Kommandoutdata bör likna följande exempel.
NAME STATUS DESCRIPTION CONFIG SimulatedTemperatureSensor running Up 5 seconds mcr.microsoft.com/azureiotedge-simulated-temperature-sensor:1.0 edgeAgent running Up 17 seconds mcr.microsoft.com/azureiotedge-agent:1.5 edgeHub running Up 6 seconds mcr.microsoft.com/azureiotedge-hub:1.5
Inspektera edgeHub-containern.
sudo docker inspect edgeHub
I utdata hittar du parametern EdgeDeviceHostName i avsnittet Env .
"EdgeDeviceHostName=10.0.0.4"
Kontrollera att parametervärdet EdgeDeviceHostName matchar
config.toml
inställningen värdnamn . Om den inte matchar kördes edgeHub-containern när du ändrade och tillämpade konfigurationen. Om du vill uppdatera EdgeDeviceHostName tar du bort containern edgeAgent .sudo docker rm -f edgeAgent
EdgeAgent- och edgeHub-containrarna återskapas och startas inom några minuter. När edgeHub-containern körs kontrollerar du containern och kontrollerar att parametern EdgeDeviceHostName matchar konfigurationsfilen.
Konfigurera nedströmsenhet
Om du vill konfigurera nedströmsenheten öppnar du ett lokalt kommandogränssnitt eller ett fjärrkommandogränssnitt.
För att aktivera säkra anslutningar måste varje IoT Edge-nedströmsenhet i ett gatewayscenario konfigureras med ett unikt Edge CA-certifikat och en kopia av rotcertifikatutfärdarcertifikatet som delas av alla enheter i gatewayhierarkin.
Kontrollera att dina certifikat uppfyller formatkraven.
Överför rotcertifikatutfärdarcertifikatet, det underordnade Edge CA-certifikatet och den underordnade privata nyckeln till den underordnade enheten.
Kopiera certifikaten och nycklarna till rätt kataloger. De önskade katalogerna för enhetscertifikat är
/var/aziot/certs
för certifikaten och/var/aziot/secrets
för nycklar.### Copy device certificate ### # If the device certificate and keys directories don't exist, create, set ownership, and set permissions sudo mkdir -p /var/aziot/certs sudo chown aziotcs:aziotcs /var/aziot/certs sudo chmod 755 /var/aziot/certs sudo mkdir -p /var/aziot/secrets sudo chown aziotks:aziotks /var/aziot/secrets sudo chmod 700 /var/aziot/secrets # Copy device full-chain certificate and private key into the correct directory sudo cp iot-device-downstream-full-chain.cert.pem /var/aziot/certs sudo cp iot-device-downstream.key.pem /var/aziot/secrets ### Root certificate ### # Copy root certificate into the /certs directory sudo cp azure-iot-test-only.root.ca.cert.pem /var/aziot/certs # Copy root certificate into the CA certificate directory and add .crt extension. # The root certificate must be in the CA certificate directory to install it in the certificate store. # Use the appropriate copy command for your device OS or if using EFLOW. # For Ubuntu and Debian, use /usr/local/share/ca-certificates/ sudo cp azure-iot-test-only.root.ca.cert.pem /usr/local/share/azure-iot-test-only.root.ca.cert.pem.crt # For EFLOW, use /etc/pki/ca-trust/source/anchors/ sudo cp azure-iot-test-only.root.ca.cert.pem /etc/pki/ca-trust/source/anchors/azure-iot-test-only.root.ca.pem.crt
Ändra ägarskap och behörigheter för certifikaten och nycklarna.
# Give aziotcs ownership to certificates # Read and write for aziotcs, read-only for others sudo chown -R aziotcs:aziotcs /var/aziot/certs sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \; # Give aziotks ownership to private keys # Read and write for aziotks, no permission for others sudo chown -R aziotks:aziotks /var/aziot/secrets sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;
Installera rotcertifikatutfärdarcertifikatet på den underordnade IoT Edge-enheten genom att uppdatera certifikatarkivet på enheten med hjälp av det plattformsspecifika kommandot.
# Update the certificate store # For Ubuntu or Debian - use update-ca-certificates sudo update-ca-certificates # For EFLOW or RHEL - use update-ca-trust sudo update-ca-trust
Mer information om hur du använder
update-ca-trust
i EFLOW finns i CBL-Mariner SSL CA-certifikathantering.
Kommandot rapporterar att ett certifikat har lagts till i /etc/ssl/certs
.
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Uppdatera underordnad konfigurationsfil
Du bör redan ha IoT Edge installerat på enheten. Om inte följer du stegen för att manuellt etablera en enda Linux IoT Edge-enhet.
Kontrollera att konfigurationsfilen
/etc/aziot/config.toml
finns på den underordnade enheten.Om konfigurationsfilen inte finns på enheten använder du följande kommando för att skapa den baserat på mallfilen:
sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
Du kan också använda mallfilen som referens för att lägga till konfigurationsparametrar i det här avsnittet.
Öppna IoT Edge-konfigurationsfilen med hjälp av ett redigeringsprogram. Använd till exempel redigeraren
nano
för att öppna/etc/aziot/config.toml
filen.sudo nano /etc/aziot/config.toml
Leta upp parametern parent_hostname eller lägg till den i början av konfigurationsfilen Varje underordnade IoT Edge-enhet måste ange en parent_hostname parameter för att identifiera dess överordnade. Uppdatera parametern
parent_hostname
till FQDN eller IP-adressen för den överordnade enheten och matcha det som angavs som värdnamnet i den överordnade enhetens konfigurationsfil. Till exempel:parent_hostname = "10.0.0.4"
Leta upp certifikatparametern Förtroendepaket eller lägg till den i början av konfigurationsfilen.
Uppdatera parametern
trust_bundle_cert
med fil-URI:n till rotcertifikatutfärdarcertifikatet på enheten. Till exempel:trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
Hitta eller lägg till avsnittet Edge CA-certifikat i konfigurationsfilen. Uppdatera certifikat-
cert
och privata nyckelparametrarnapk
med fil-URI-sökvägarna för det fullständiga certifikatet och nyckelfilerna på IoT Edge-nedströmsenheten. IoT Edge kräver att certifikatet och den privata nyckeln är i textbaserat PEM-format (privacy-enhanced mail). Till exempel:[edge_ca] cert = "file:///var/aziot/certs/iot-device-downstream-full-chain.cert.pem" pk = "file:///var/aziot/secrets/iot-device-downstream.key.pem"
Kontrollera att din IoT Edge-enhet använder rätt version av IoT Edge-agenten när den startas. Leta upp avsnittet Default Edge Agent och ange avbildningsvärdet för IoT Edge till version 1.5. Till exempel:
[agent] name = "edgeAgent" type = "docker" [agent.config] image: "mcr.microsoft.com/azureiotedge-agent:1.5"
Början av din nedströmskonfigurationsfil bör se ut ungefär som i följande exempel.
parent_hostname = "10.0.0.4" trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem" [edge_ca] cert = "file:///var/aziot/certs/iot-device-downstream-full-chain.cert.pem" pk = "file:///var/aziot/secrets/iot-device-downstream.key.pem"
Spara och stäng konfigurationsfilen
config.toml
. Om du till exempel använder nanoredigeraren väljer du Ctrl+O - Skriv ut, Retur och Ctrl+X - Avsluta.Om du har använt andra certifikat för IoT Edge tidigare tar du bort filerna i följande två kataloger för att se till att dina nya certifikat tillämpas:
/var/lib/aziot/certd/certs
/var/lib/aziot/keyd/keys
Tillämpa ändringarna.
sudo iotedge config apply
Kontrollera om det finns några fel i konfigurationen.
sudo iotedge check --verbose
Dricks
IoT Edge-kontrollverktyget använder en container för att utföra en del av diagnostikkontrollen. Om du vill använda det här verktyget på underordnade IoT Edge-enheter kontrollerar du att de har åtkomst till
mcr.microsoft.com/azureiotedge-diagnostics:latest
eller har containeravbildningen i ditt privata containerregister.Kommentar
På en nyligen etablerad enhet kan du se ett fel som rör IoT Edge Hub:
× produktionsberedskap: Edge Hubs lagringskatalog sparas i värdfilsystemet – Fel
Det gick inte att kontrollera det aktuella tillståndet för edgeHub-containern
Det här felet förväntas på en nyligen etablerad enhet eftersom IoT Edge Hub-modulen inte körs. Lös felet genom att ange modulerna för enheten i IoT Hub och skapa en distribution. När du skapar en distribution för enheten startas modulerna på enheten, inklusive IoT Edge Hub-modulen.
Isolera underordnade enheter i nätverket
Stegen hittills i den här artikeln konfigurerar IoT Edge-enheter som antingen en gateway eller en nedströmsenhet och skapar en betrodd anslutning mellan dem. Gatewayenheten hanterar interaktioner mellan den underordnade enheten och IoT Hub, inklusive autentisering och meddelanderoutning. Moduler som distribueras till underordnade IoT Edge-enheter kan fortfarande skapa egna anslutningar till molntjänster.
Vissa nätverksarkitekturer, som de som följer ISA-95-standarden, försöker minimera antalet internetanslutningar. I dessa scenarier kan du konfigurera underordnade IoT Edge-enheter utan direkt internetanslutning. Förutom att dirigera IoT Hub-kommunikation via deras gatewayenhet kan underordnade IoT Edge-enheter förlita sig på gatewayenheten för alla molnanslutningar.
Den här nätverkskonfigurationen kräver att endast IoT Edge-enheten i det översta lagret i en gatewayhierarki har direkta anslutningar till molnet. IoT Edge-enheter i de lägre lagren kan bara kommunicera med sina överordnade enheter eller underordnade enheter. Särskilda moduler på gatewayenheterna aktiverar det här scenariot, inklusive:
API-proxymodulen krävs på alla IoT Edge-gatewayer som har en annan IoT Edge-enhet under sig. Det innebär att den måste finnas på varje lager i en gatewayhierarki förutom det nedre lagret. Den här modulen använder en omvänd nginx-proxy för att dirigera HTTP-data via nätverkslager över en enda port. Den är mycket konfigurerbar via dess modultvillingar och miljövariabler, så den kan justeras så att den passar dina krav för gatewayscenariot.
Docker-registermodulen kan distribueras på IoT Edge-gatewayen på det översta lagret i en gatewayhierarki. Den här modulen ansvarar för att hämta och cachelagra containeravbildningar för alla IoT Edge-enheter i lägre lager. Alternativet för att distribuera den här modulen på det översta lagret är att använda ett lokalt register eller att manuellt läsa in containeravbildningar på enheter och ställa in modulens pull-princip på aldrig.
Azure Blob Storage på IoT Edge kan distribueras på IoT Edge-gatewayen på det översta lagret i en gatewayhierarki. Den här modulen ansvarar för att ladda upp blobar för alla IoT Edge-enheter i lägre lager. Möjligheten att ladda upp blobar möjliggör också användbara felsökningsfunktioner för IoT Edge-enheter i lägre lager, till exempel uppladdning av modulloggar och uppladdning av paket.
Konfiguration av nätverk
För varje gatewayenhet i det översta lagret måste nätverksoperatörerna:
Ange en statisk IP-adress eller ett fullständigt domännamn (FQDN).
Auktorisera utgående kommunikation från den här IP-adressen till ditt Azure IoT Hub-värdnamn via portarna 443 (HTTPS) och 5671 (AMQP).
Auktorisera utgående kommunikation från den här IP-adressen till ditt Azure Container Registry-värdnamn via port 443 (HTTPS).
API-proxymodulen kan bara hantera anslutningar till ett containerregister i taget. Vi rekommenderar att alla containeravbildningar, inklusive de offentliga avbildningar som tillhandahålls av Microsoft Container Registry (mcr.microsoft.com), lagras i ditt privata containerregister.
För varje gatewayenhet i ett lägre lager måste nätverksoperatörerna:
- Ange en statisk IP-adress.
- Auktorisera utgående kommunikation från den här IP-adressen till den överordnade gatewayens IP-adress via portarna 443 (HTTPS) och 5671 (AMQP).
Distribuera moduler till enheter på översta nivån
IoT Edge-enheten på det översta lagret i en gatewayhierarki har en uppsättning nödvändiga moduler som måste distribueras till den, förutom eventuella arbetsbelastningsmoduler som du kan köra på enheten.
API-proxymodulen har utformats för att anpassas för att hantera de vanligaste gatewayscenarierna. Den här artikeln innehåller ett exempel på hur du konfigurerar modulerna i en grundläggande konfiguration. Mer detaljerad information och exempel finns i Konfigurera API-proxymodulen för ditt gatewayhierarkiscenario.
I Azure Portal, navigerar du till din IoT-hubb.
Välj Enheter under menyn Enhetshantering .
Välj den IoT Edge-enhet på översta lagret som du konfigurerar i listan.
Välj Ange moduler.
I avsnittet IoT Edge-moduler väljer du Lägg till och sedan IoT Edge-modul.
Uppdatera följande modulinställningar:
Inställning Värde Namn på IoT-modul IoTEdgeAPIProxy
URI för avbildning mcr.microsoft.com/azureiotedge-api-proxy:latest
Omstartsprincip alltid Önskad status körs Om du vill använda en annan version eller arkitektur för API-proxymodulen hittar du de tillgängliga avbildningarna i Microsoft Artifact Registry.
På fliken Miljövariabler lägger du till en variabel med namnet
NGINX_DEFAULT_PORT
text med värdet443
.På fliken Alternativ för att skapa container uppdaterar du portbindningarna till referensport 443.
{ "HostConfig": { "PortBindings": { "443/tcp": [ { "HostPort": "443" } ] } } }
Dessa ändringar konfigurerar API-proxymodulen så att den lyssnar på port 443. För att förhindra portbindningskollisioner måste du konfigurera edgeHub-modulen så att den inte lyssnar på port 443. I stället dirigerar API-proxymodulen all edgeHub-trafik på port 443.
Välj Lägg till för att lägga till modulen i distributionen.
Välj Körningsinställningar och leta reda på edgeHub-modulen Alternativ för containerskapande. Ta bort portbindningen för port 443 och lämna bindningarna för portarna 5671 och 8883.
{ "HostConfig": { "PortBindings": { "5671/tcp": [ { "HostPort": "5671" } ], "8883/tcp": [ { "HostPort": "8883" } ] } } }
Välj Använd för att spara ändringarna i körningsinställningarna.
Ange följande värden för att lägga till Docker-registermodulen i distributionen.
I avsnittet IoT Edge-moduler väljer du Lägg till och sedan IoT Edge-modul.
Inställning Värde Namn på IoT-modul registry
URI för avbildning registry:latest
Omstartsprincip always
Önskad status running
Lägg till följande variabler på fliken Miljövariabler :
Namn Typ Värde REGISTRY_PROXY_REMOTEURL
Text URL:en för det containerregister som du vill att registermodulen ska mappas till. Exempel: https://myregistry.azurecr
Registermodulen kan bara mappas till ett containerregister, så vi rekommenderar att du har alla containeravbildningar i ett enda privat containerregister.REGISTRY_PROXY_USERNAME
Text Användarnamn för att autentisera till containerregistret. REGISTRY_PROXY_PASSWORD
Text Lösenord för att autentisera till containerregistret. På fliken Alternativ för att skapa container uppdaterar du portbindningarna till referensport 5000.
{ "HostConfig": { "PortBindings": { "5000/tcp": [ { "HostPort": "5000" } ] } } }
Välj Lägg till för att lägga till modulen i distributionen.
Välj Nästa: Vägar för att gå till nästa steg.
Om du vill aktivera enhets-till-moln-meddelanden från underordnade enheter för att nå IoT Hub inkluderar du en väg som skickar alla meddelanden till IoT Hub. Till exempel:
- Namn:
Route
- Värde:
FROM /messages/* INTO $upstream
- Namn:
Välj Granska + skapa för att gå till det sista steget.
Välj Skapa för att distribuera till enheten.
Distribuera moduler till enheter med lägre lager
IoT Edge-enheter i lägre lager i en gatewayhierarki har en nödvändig modul som måste distribueras till dem, förutom alla arbetsbelastningsmoduler som du kan köra på enheten.
Dirigera containeravbildningshämtningar
Innan du diskuterar den proxymodul som krävs för IoT Edge-enheter i gatewayhierarkier är det viktigt att förstå hur IoT Edge-enheter i lägre lager får sina modulbilder.
Om dina enheter på lägre nivå inte kan ansluta till molnet, men du vill att de ska hämta modulbilder som vanligt, måste gatewayhierarkins översta lagerenhet konfigureras för att hantera dessa begäranden. Den översta lagerenheten måste köra en Docker-registermodul som är mappad till ditt containerregister. Konfigurera sedan API-proxymodulen för att dirigera containerbegäranden till den. Dessa detaljer beskrivs i de tidigare avsnitten i den här artikeln. I den här konfigurationen ska enheterna på lägre nivå inte peka på molncontainerregister, utan till registret som körs i det översta lagret.
I stället för att anropa mcr.microsoft.com/azureiotedge-api-proxy:1.1
bör enheter på lägre nivå till exempel anropa $upstream:443/azureiotedge-api-proxy:1.1
.
Parametern $upstream pekar på den överordnade enheten för en enhet med lägre lager, så begäran dirigeras genom alla lager tills den når det översta lagret som har en proxymiljö som dirigerar containerbegäranden till registermodulen. Porten :443
i det här exemplet bör ersättas med den port som API-proxymodulen på den överordnade enheten lyssnar på.
API-proxymodulen kan bara dirigeras till en registermodul och varje registermodul kan bara mappas till ett containerregister. Därför måste alla avbildningar som enheter med lägre lager måste hämta lagras i ett enda containerregister.
Om du inte vill att enheter på lägre nivå ska göra pull-begäranden för moduler via en gatewayhierarki är ett annat alternativ att hantera en lokal registerlösning. Eller så kan du skicka modulbilderna till enheterna innan du skapar distributioner och sedan ange imagePullPolicy till aldrig.
Bootstrap IoT Edge-agenten
IoT Edge-agenten är den första körningskomponenten som startar på en IoT Edge-enhet. Du måste se till att alla underordnade IoT Edge-enheter kan komma åt edgeAgent-modulens avbildning när de startas, och sedan kan de komma åt distributioner och starta resten av modulbilderna.
När du går in i konfigurationsfilen på en IoT Edge-enhet för att ange dess autentiseringsinformation, certifikat och överordnade värdnamn uppdaterar du även containeravbildningen edgeAgent.
Om den översta gatewayenheten är konfigurerad för att hantera begäranden om containeravbildning ersätter mcr.microsoft.com
du med det överordnade värdnamnet och API-proxyns lyssnarport. I distributionsmanifestet kan du använda $upstream
som en genväg, men det kräver att edgeHub-modulen hanterar routning och att modulen inte har startats just nu. Till exempel:
[agent]
name = "edgeAgent"
type = "docker"
[agent.config]
image: "{Parent FQDN or IP}:443/azureiotedge-agent:1.5"
Om du använder ett lokalt containerregister eller tillhandahåller containeravbildningarna manuellt på enheten uppdaterar du konfigurationsfilen i enlighet med detta.
Konfigurera körnings- och distributionsproxymodul
API-proxymodulen krävs för att dirigera all kommunikation mellan molnet och eventuella underordnade IoT Edge-enheter. En IoT Edge-enhet i det nedre lagret i hierarkin, utan underordnade IoT Edge-enheter, behöver inte den här modulen.
API-proxymodulen har utformats för att anpassas för att hantera de vanligaste gatewayscenarierna. Den här artikeln beskriver kortfattat stegen för att konfigurera modulerna i en grundläggande konfiguration. Mer detaljerad information och exempel finns i Konfigurera API-proxymodulen för ditt gatewayhierarkiscenario.
I Azure Portal, navigerar du till din IoT-hubb.
Välj Enheter under menyn Enhetshantering .
Välj den IoT Edge-enhet på lägre nivå som du konfigurerar i listan.
Välj Ange moduler.
I avsnittet IoT Edge-moduler väljer du Lägg till och sedan IoT Edge-modul.
Uppdatera följande modulinställningar:
Inställning Värde Namn på IoT-modul IoTEdgeAPIProxy
URI för avbildning mcr.microsoft.com/azureiotedge-api-proxy:latest
Omstartsprincip always
Önskad status running
Om du vill använda en annan version eller arkitektur för API-proxymodulen hittar du de tillgängliga avbildningarna i Microsoft Artifact Registry.
På fliken Miljövariabler lägger du till en variabel med namnet
NGINX_DEFAULT_PORT
text med värdet443
.På fliken Alternativ för att skapa container uppdaterar du portbindningarna till referensport 443.
{ "HostConfig": { "PortBindings": { "443/tcp": [ { "HostPort": "443" } ] } } }
Dessa ändringar konfigurerar API-proxymodulen så att den lyssnar på port 443. För att förhindra portbindningskollisioner måste du konfigurera edgeHub-modulen så att den inte lyssnar på port 443. I stället dirigerar API-proxymodulen all edgeHub-trafik på port 443.
Välj Körningsinställningar.
Uppdatera inställningarna för edgeHub-modulen:
- I fältet Bild ersätter du
mcr.microsoft.com
med$upstream:443
. - I fältet Skapa alternativ tar du bort portbindningen för port 443 och lämnar bindningarna för portarna 5671 och 8883.
{ "HostConfig": { "PortBindings": { "5671/tcp": [ { "HostPort": "5671" } ], "8883/tcp": [ { "HostPort": "8883" } ] } } }
- I fältet Bild ersätter du
Uppdatera inställningarna för edgeAgent-modulen:
- I fältet Bild ersätter du
mcr.microsoft.com
med$upstream:443
.
- I fältet Bild ersätter du
Välj Använd för att spara ändringarna i körningsinställningarna.
Välj Nästa: Vägar för att gå till nästa steg.
Om du vill aktivera enhets-till-moln-meddelanden från nedströmsenheter för att nå IoT Hub inkluderar du en väg som skickar alla meddelanden till
$upstream
. Den överordnade parametern pekar på den överordnade enheten när det gäller enheter på lägre nivå. Till exempel:- Namn:
Route
- Värde:
FROM /messages/* INTO $upstream
- Namn:
Välj Granska + skapa för att gå till det sista steget.
Välj Skapa för att distribuera till enheten.
Verifiera anslutningen från underordnad till överordnad
Kontrollera TLS/SSL-anslutningen från den underordnade till den överordnade genom att köra följande
openssl
kommando på den underordnade enheten. Ersätt<parent hostname>
med det överordnade domännamnet eller IP-adressen.openssl s_client -connect <parent hostname>:8883 </dev/null 2>&1 >/dev/null
Kommandot bör kontrollera lyckad validering av den överordnade certifikatkedjan på ett liknande sätt som i följande exempel:
azureUser@child-vm:~$ openssl s_client -connect <parent hostname>:8883 </dev/null 2>&1 >/dev/null Can't use SSL_get_servername depth=3 CN = Azure_IoT_Hub_CA_Cert_Test_Only verify return:1 depth=2 CN = Azure_IoT_Hub_Intermediate_Cert_Test_Only verify return:1 depth=1 CN = gateway.ca verify return:1 depth=0 CN = <parent hostname> verify return:1 DONE
Meddelandet "Det går inte att använda SSL_get_servername" kan ignoreras.
Värdet
depth=0 CN =
ska matcha den värdnamnsparameter som anges i den överordnade konfigurationsfilenconfig.toml
.Om kommandot överskrider tidsgränsen kan det finnas blockerade portar mellan de underordnade och överordnade enheterna. Granska nätverkskonfigurationen och inställningarna för enheterna.
Varning
Om du inte använder ett fullständigt kedjecertifikat i gatewayens
[edge_ca]
avsnitt resulterar det i certifikatverifieringsfel från den underordnade enheten. Kommandot ovan skapar till exempelopenssl s_client ...
:Can't use SSL_get_servername depth=1 CN = gateway.ca verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = <parent hostname> verify return:1 DONE
Samma problem uppstår för TLS-aktiverade enheter som ansluter till den underordnade IoT Edge-enheten om det fullständiga enhetscertifikatet inte används och konfigureras på den underordnade enheten.
Integrera Microsoft Defender för IoT med IoT Edge-gateway
Underordnade enheter kan användas för att integrera Microsoft Defender för IoT:s mikroagent med IoT Edge-gatewayen med hjälp av nedströms enhetsproxy.
Läs mer om Defender for IoT-mikroagenten.
Så här integrerar du Microsoft Defender för IoT med IoT Edge med hjälp av nedströms enhetsproxy:
Logga in på Azure-portalen.
Navigera till enheter för enhetshantering i>IoT Hub>
Your Hub
>Välj din enhet.
Välj den
DefenderIotMicroAgent
modultvilling som du skapade från de här anvisningarna.Välj knappen för att kopiera anslutningssträngen (primärnyckel).
Klistra in niska veze i ett textredigeringsprogram och lägg till GatewayHostName i strängen. GatewayHostName är det fullständigt kvalificerade domännamnet eller IP-adressen för den överordnade enheten. Exempel:
HostName=nested11.azure-devices.net;DeviceId=downstream1;ModuleId=module1;SharedAccessKey=xxx;GatewayHostName=10.16.7.4
Öppna en terminal på den underordnade enheten.
Använd följande kommando för att placera niska veze kodad i utf-8 i defender for cloud-agentkatalogen i filen
connection_string.txt
i följande sökväg: :/etc/defender_iot_micro_agent/connection_string.txt
sudo bash -c 'echo "<connection string>" > /etc/defender_iot_micro_agent/connection_string.txt'
connection_string.txt
Ska nu finnas på följande sökvägsplats/etc/defender_iot_micro_agent/connection_string.txt
.Starta om tjänsten med det här kommandot:
sudo systemctl restart defender-iot-micro-agent.service
Gå tillbaka till enheten.
Aktivera anslutningen till IoT Hub och välj kugghjulsikonen.
Välj den överordnade enheten i listan som visas.
Kontrollera att port 8883 (MQTT) mellan den underordnade enheten och IoT Edge-enheten är öppen.
Nästa steg
Så kan en IoT Edge-enhet användas som gateway
Konfigurera API-proxymodulen för ditt gatewayhierarkiscenario