Publiceren en abonneren met Azure IoT Edge (preview)
Van toepassing op:
IoT Edge 1,2
U kunt een Azure IoT Edge MQTT-broker gebruiken om berichten te publiceren en te abonneren. In dit artikel wordt beschreven hoe u verbinding maakt met deze broker, berichten publiceert en zich abonneert via door de gebruiker gedefinieerde onderwerpen, en hoe u IoT Hub berichten gebruikt. De IoT Edge MQTT-broker is ingebouwd in IoT Edge hub. Zie de brokeringmogelijkheden van deIoT Edge hub voor meer informatie.
Notitie
IoT Edge MQTT-broker is momenteel beschikbaar als openbare preview.
Vereisten
Een Azure-account met een geldig abonnement
Azure CLI met de
azure-iotCLI-extensie geïnstalleerd. Zie de installatiestappen voor De Azure IoT-extensie voor Azure CLI voor meer informatie.Een IoT Hub SKU F1, S1, S2 of S3.
Zorg ervoor dat een IoT Edge-apparaat met versie 1.2 of hoger is geïmplementeerd, met inbegrip van edgeAgent- en edgeHub-modules versie 1.2 of hoger, met de functie MQTT Broker ingeschakeld en de edgeHub-poort 1883 die is gebonden aan de host om niet-TLS-verbindingen mogelijk te maken. U kunt de IoT Edge 1.2 automatisch implementeren in een Azure-VM door de stappen te volgen die in dit artikel worden beschreven. Omdat IoT Edge MQTT-broker momenteel in openbare preview is, moet u ook de volgende omgevingsvariabelen instellen op true in de edgeHub-module om de MQTT-broker in teschakelen:
Name Waarde experimentalFeatures__enabledtrueexperimentalFeatures__mqttBrokerEnabledtrueAls u snel een IoT Edge implementatie die voldoet aan deze criteria, samen met een open autorisatiebeleid op de , kunt u dit voorbeeld van een
test_topicimplementatiemanifest in bijlage gebruiken:Sla het implementatiebestand op in uw werkmap
Pas deze implementatie toe op IoT Edge apparaat met behulp van de volgende Azure CLI-opdracht. Zie Deploy Azure IoT Edge modules with Azure CLI (Modulesimplementeren met Azure CLI) voor meer informatie over deze opdracht.
az iot edge set-modules --device-id [device id] --hub-name [hub name] --content [deployment file path]
Mosquitto-clients die op het IoT Edge geïnstalleerd. In dit artikel wordt gebruikgemaakt van de populaire Mosquitto-clients MOSQUITTO_PUB en MOSQUITTO_SUB. In plaats daarvan kunnen andere MQTT-clients worden gebruikt. Voer de volgende opdracht uit om de Mosquitto-clients te installeren op een Ubuntu-apparaat:
sudo apt-get update && sudo apt-get install mosquitto-clientsInstalleer de Mosquitto-server niet, omdat dit kan leiden tot blokkering van de MQTT-poorten (8883 en 1883) en conflict met de IoT Edge hub.
Verbinding maken naar IoT Edge hub
Verbinding maken met IoT Edge Hub volgt dezelfde stappen als beschreven in het artikel Verbinding maken met IoT Hub met een algemene MQTT-client of in de conceptuele beschrijving van het artikel IoT Edge hub. Deze stappen zijn:
- Optioneel brengt de MQTT-client een beveiligde verbinding tot stand met de IoT Edge hub met behulp van Transport Layer Security (TLS)
- De MQTT-client verifieert zichzelf bij IoT Edge hub
- De IoT Edge hub autorisatie van de MQTT-client volgens het autorisatiebeleid
Beveiligde verbinding (TLS)
Transport Layer Security (TLS) wordt gebruikt om een versleutelde communicatie tot stand te brengen tussen de client en de IoT Edge hub.
Als u TLS wilt uitschakelen, gebruikt u poort 1883 (MQTT) en verbindt u de edgeHub-container met poort 1883.
Als een client op poort 8883 (MQTTS) verbinding maakt met de MQTT-broker, wordt een TLS-kanaal gestart om TLS in te kunnenschakelen. De broker verzendt de certificaatketen die de client moet valideren. Als u de certificaatketen wilt valideren, moet het basiscertificaat van de MQTT-broker worden geïnstalleerd als een vertrouwd certificaat op de client. Als het basiscertificaat niet wordt vertrouwd, wordt de clientbibliotheek geweigerd door de MQTT-broker met een certificaatverificatiefout. De stappen die u moet volgen om dit basiscertificaat van de broker op de client te installeren, zijn hetzelfde als in het geval van de transparante gateway en worden beschreven in de documentatie een downstreamapparaat voorbereiden.
Verificatie
Een MQTT-client moet eerst een CONNECT-pakket verzenden naar de MQTT-broker om een verbinding in zijn naam te initiëren. Dit pakket bevat drie soorten verificatiegegevens: een client identifier , een en een username password :
Het
client identifierveld is de naam van het apparaat of de modulenaam in IoT Hub. Hiervoor wordt de volgende syntaxis gebruikt:Voor een apparaat:
<device_name>Voor een module:
<device_name>/<module_name>
Als u verbinding wilt maken met de MQTT-broker, moet een apparaat of module worden geregistreerd in IoT Hub.
De broker staat geen verbindingen van meerdere clients met dezelfde referenties toe. De broker verbreekt de verbinding met de al verbonden client als een tweede client verbinding maakt met dezelfde referenties.
Het veld is afgeleid van de naam van het apparaat of de module en de IoTHub-naam van het apparaat met behulp van
usernamede volgende syntaxis:Voor een apparaat:
<iot_hub_name>.azure-devices.net/<device_name>/?api-version=2018-06-30Voor een module:
<iot_hub_name>.azure-devices.net/<device_name>/<module_name>/?api-version=2018-06-30
Het
passwordveld van het CONNECT-pakket is afhankelijk van de verificatiemodus:- Wanneer u verificatie met symmetrische sleutels gebruikt,
passwordis het veld een SAS-token. - Wanneer u zelf-ondertekende X.509-verificatie gebruikt,
passwordis het veld niet aanwezig. In deze verificatiemodus is een TLS-kanaal vereist. De client moet verbinding maken met poort 8883 om een TLS-verbinding tot stand te brengen. Tijdens de TLS-handshake vraagt de MQTT-broker een clientcertificaat aan. Dit certificaat wordt gebruikt om de identiteit van de client te verifiëren en daarom is het veld later niet meer nodig wanneerpasswordhet CONNECT-pakket wordt verzonden. Het verzenden van zowel een clientcertificaat als het wachtwoordveld leidt tot een fout en de verbinding wordt gesloten. MQTT-bibliotheken en TLS-clientbibliotheken hebben meestal een manier om een clientcertificaat te verzenden bij het starten van een verbinding. U ziet een stapsgewijs voorbeeld in de sectie X509-certificaat gebruiken voor clientverificatie.
- Wanneer u verificatie met symmetrische sleutels gebruikt,
Modules die zijn geïmplementeerd door IoT Edge maken gebruik van verificatie met symmetrische sleutels en kunnen de local IoT Edge-workload-API aanroepen om programmatisch een SAS-token op te halen, zelfs wanneer deze offline is.
Autorisatie
Zodra een MQTT-client is geverifieerd bij IoT Edge hub, moet deze zijn gemachtigd om verbinding te maken. Zodra er verbinding is, moet deze gemachtigd zijn om specifieke onderwerpen te publiceren of zich te abonneren. Deze autorisaties worden verleend door de IoT Edge hub op basis van het autorisatiebeleid. Het autorisatiebeleid is een set instructies die worden uitgedrukt als een JSON-structuur die via de dubbel naar de IoT Edge hub wordt verzonden. Bewerk een IoT Edge hub-dubbel om het autorisatiebeleid te configureren.
Notitie
Voor de openbare preview ondersteunt alleen de Azure CLI implementaties met MQTT Broker-autorisatiebeleid. De Azure Portal biedt momenteel geen ondersteuning voor het bewerken van IoT Edge hub-dubbel en het autorisatiebeleid.
Elke autorisatiebeleidsverklaring bestaat uit de combinatie van - of identities allow deny -effecten, operations , en resources :
identitieshet onderwerp van het beleid beschrijven. Deze moet worden toe teusernamewijs aan de die is verzonden door clients in hun CONNECT-pakket en moet de indeling of<iot_hub_name>.azure-devices.net/<device_name><iot_hub_name>.azure-devices.net/<device_name>/<module_name>hebben.allow``denyof-effecten definiëren of bewerkingen moeten worden toegestaan of weigeren.operationsde acties definiëren die moeten worden geautoriseerd.mqtt:connectenmqtt:publishzijn momenteel de driemqtt:subscribeondersteunde acties.resourcesdefinieer het object van het beleid. Dit kan een onderwerp of een onderwerppatroon zijn dat is gedefinieerd met MQTT-jokertekens.
Hieronder ziet u een voorbeeld van een autorisatiebeleid dat expliciet geen 'rogue_client'-client toestaat om verbinding te maken, waarmee Azure IoT-clients verbinding kunnen maken en 'sensor_1' toestemming heeft om naar het onderwerp te events/alerts publiceren.
{
"$edgeHub":{
"properties.desired":{
"schemaVersion":"1.2",
"routes":{
"Route1":"FROM /messages/* INTO $upstream"
},
"storeAndForwardConfiguration":{
"timeToLiveSecs":7200
},
"mqttBroker":{
"authorizations":[
{
"identities":[
"<iot_hub_name>.azure-devices.net/rogue_client"
],
"deny":[
{
"operations":[
"mqtt:connect"
]
}
]
},
{
"identities":[
"{{iot:identity}}"
],
"allow":[
{
"operations":[
"mqtt:connect"
]
}
]
},
{
"identities":[
"<iot_hub_name>.azure-devices.net/sensor_1"
],
"allow":[
{
"operations":[
"mqtt:publish"
],
"resources":[
"events/alerts"
]
}
]
}
]
}
}
}
}
Een aantal zaken waar u rekening mee moet houden bij het schrijven van uw autorisatiebeleid:
Hiervoor is
$edgeHubdubbelschemaversie 1.2 vereistStandaard worden alle bewerkingen geweigerd.
Autorisatie-instructies worden geëvalueerd in de volgorde waarin ze worden weergegeven in de JSON-definitie. Eerst kijkt u naar en selecteert u vervolgens de eerste instructies voor toestaan of
identitiesweigeren die overeenkomen met de aanvraag. In het geval van conflicten tussen instructies voor toestaan en weigeren, wint de deny-instructie.Er kunnen verschillende variabelen (bijvoorbeeld vervangingen) worden gebruikt in het autorisatiebeleid:
{{iot:identity}}vertegenwoordigt de identiteit van de momenteel verbonden client. Bijvoorbeeld een apparaat-id zoals<iot_hub_name>.azure-devices.net/myDeviceof een module-id zoals<iot_hub_name>.azure-devices.net/myEdgeDevice/SampleModule.{{iot:device_id}}vertegenwoordigt de identiteit van het apparaat dat momenteel is verbonden. Bijvoorbeeld een apparaat-id zoals of demyDeviceapparaat-id waarin een module wordt uitgevoerd, zoalsmyEdgeDevice.{{iot:module_id}}vertegenwoordigt de identiteit van de momenteel verbonden module. Deze variabele is leeg voor verbonden apparaten of een module-id zoalsSampleModule.{{iot:this_device_id}}vertegenwoordigt de identiteit van het IoT Edge apparaat met het autorisatiebeleid. BijvoorbeeldmyIoTEdgeDevice.
Autorisaties voor IoT Hub-onderwerpen worden iets anders verwerkt dan door de gebruiker gedefinieerde onderwerpen. Dit zijn de belangrijkste punten om te onthouden:
- Azure IoT-apparaten of -modules hebben een expliciete autorisatieregel nodig om verbinding te maken met IoT Edge hub MQTT-broker. Hieronder vindt u een standaard autorisatiebeleid voor verbinding.
- Azure IoT-apparaten of -modules hebben standaard toegang tot hun eigen IoT Hub-onderwerpen zonder expliciete autorisatieregel. Autorisaties zijn in dat geval echter het gevolg van bovenliggende/onderliggende relaties en deze relaties moeten worden ingesteld. IoT Edge modules worden automatisch ingesteld als kinderen van hun IoT Edge-apparaat, maar apparaten moeten expliciet worden ingesteld als kinderen van hun IoT Edge gateway.
Hier is een standaardautorisatiebeleid dat kan worden gebruikt om alle Azure IoT-apparaten of -modules in staat te stellen verbinding te maken met de broker:
{
"$edgeHub":{
"properties.desired":{
"schemaVersion":"1.2",
"mqttBroker":{
"authorizations":[
{
"identities": [
"{{iot:identity}}"
],
"allow":[
{
"operations":[
"mqtt:connect"
]
}
]
}
]
}
}
}
}
Nu u weet hoe u verbinding kunt maken met de IoT Edge MQTT-broker, gaan we kijken hoe deze kan worden gebruikt om berichten eerst te publiceren en te abonneren op door de gebruiker gedefinieerde onderwerpen, vervolgens op IoT Hub-onderwerpen en ten slotte naar een andere MQTT-broker.
Publiceren en abonneren op door de gebruiker gedefinieerde onderwerpen
In dit artikel gebruikt u één client met de naam sub_client die zich abonneert op een onderwerp en een andere client met de naam pub_client die naar een onderwerp publiceert. We gebruiken de verificatie met symmetrische sleutels, maar hetzelfde kan worden gedaan met X.509 zelf-ondertekende verificatie of X.509 CA-ondertekende verificatie.
Uitgevers- en abonnee-clients maken
Maak twee IoT-apparaten in IoT Hub en haal hun wachtwoorden op. Gebruik de Azure CLI vanuit uw terminal om het volgende te doen:
Maak twee IoT-apparaten in IoT Hub:
az iot hub device-identity create --device-id sub_client --hub-name <iot_hub_name> az iot hub device-identity create --device-id pub_client --hub-name <iot_hub_name>Stel het bovenliggende apparaat in op uw IoT Edge apparaat:
az iot hub device-identity parent set --device-id sub_client --hub-name <iot_hub_name> --pd <edge_device_id> az iot hub device-identity parent set --device-id pub_client --hub-name <iot_hub_name> --pd <edge_device_id>Haal hun wachtwoorden op door een SAS-token te genereren:
Voor een apparaat:
az iot hub generate-sas-token -n <iot_hub_name> -d <device_name> --key-type primary --du 3600waarbij 3600 de duur is van het SAS-token in seconden (bijvoorbeeld 3600 = 1 uur).
Voor een module:
az iot hub generate-sas-token -n <iot_hub_name> -d <device_name> -m <module_name> --key-type primary --du 3600waarbij 3600 de duur is van het SAS-token in seconden (bijvoorbeeld 3600 = 1 uur).
Kopieer het SAS-token. Dit is de waarde die overeenkomt met de sas-sleutel uit de uitvoer. Hier is een voorbeeld van de uitvoer van de bovenstaande Azure CLI-opdracht:
{ "sas": "SharedAccessSignature sr=example.azure-devices.net%2Fdevices%2Fdevice_1%2Fmodules%2Fmodule_a&sig=H5iMq8ZPJBkH3aBWCs0khoTPdFytHXk8VAxrthqIQS0%3D&se=1596249190" }
Uitgevers- en abonnee-clients machtigen
Als u de uitgever en abonnee wilt machtigen, bewerkt u IoT Edge hub-dubbel in een IoT Edge implementatie die het volgende autorisatiebeleid bevat.
Notitie
Momenteel kunnen implementaties die de MQTT-autorisatie-eigenschappen bevatten, alleen worden toegepast op IoT Edge apparaten met behulp van de Azure CLI.
{
"$edgeHub":{
"properties.desired":{
"schemaVersion":"1.2",
"mqttBroker":{
"authorizations":[
{
"identities": [
"{{iot:identity}}"
],
"allow":[
{
"operations":[
"mqtt:connect"
]
}
]
},
{
"identities": [
"<iot_hub_name>.azure-devices.net/sub_client"
],
"allow":[
{
"operations":[
"mqtt:subscribe"
],
"resources":[
"test_topic"
]
}
],
},
{
"identities": [
"<iot_hub_name>.azure-devices.net/pub_client"
],
"allow":[
{
"operations":[
"mqtt:publish"
],
"resources":[
"test_topic"
]
}
]
}
]
}
}
}
}
Verificatie met symmetrische sleutels zonder TLS
Abonneren
Verbinding maken uw sub_client MQTT-client naar de MQTT-broker en abonneer u op de door de volgende opdracht uit te voeren op test_topic uw IoT Edge apparaat:
mosquitto_sub \
-t "test_topic" \
-i "sub_client" \
-u "<iot_hub_name>.azure-devices.net/sub_client/?api-version=2018-06-30" \
-P "<sas_token>" \
-h "<edge_device_address>" \
-V mqttv311 \
-p 1883
waar <edge_device_address> = localhost in dit voorbeeld omdat de client wordt uitgevoerd op hetzelfde apparaat als IoT Edge.
In dit eerste voorbeeld wordt poort 1883 (MQTT) zonder TLS gebruikt. Hiervoor moet edgeHub-poort 1883 via de maakopties aan de host worden gebonden. Een voorbeeld wordt gegeven in de vereiste sectie. Een ander voorbeeld met poort 8883 (MQTTS) met TLS ingeschakeld, wordt weergegeven in de volgende sectie.
De sub_client MQTT-client is nu gestart en wacht op binnenkomende berichten op test_topic .
Publiceren
Verbinding maken uw pub_client MQTT-client naar de MQTT-broker en publiceert een bericht op dezelfde manier als hierboven door de volgende opdracht uit te voeren op uw IoT Edge-apparaat vanuit een andere test_topic terminal:
mosquitto_pub \
-t "test_topic" \
-i "pub_client" \
-u "<iot_hub_name>.azure-devices.net/pub_client/?api-version=2018-06-30" \
-P "<sas_token>" \
-h "<edge_device_address>" \
-V mqttv311 \
-p 1883 \
-m "hello"
waar <edge_device_address> = localhost in dit voorbeeld omdat de client wordt uitgevoerd op hetzelfde apparaat als IoT Edge.
Als de opdracht wordt uitgevoerd, ontvangt sub_client MQTT-client het bericht 'hello'.
Verificatie met symmetrische sleutels met TLS
Als u TLS wilt inschakelen, moet de poort worden gewijzigd van 1883 (MQTT) in 8883 (MQTTS) en moeten clients het basiscertificaat van de MQTT-broker hebben om de certificaatketen te kunnen valideren die is verzonden door de MQTT-broker. U kunt dit doen door de stappen in de sectie Beveiligde verbinding (TLS) te volgen.
Omdat de clients worden uitgevoerd op hetzelfde apparaat als de MQTT-broker in het bovenstaande voorbeeld, zijn dezelfde stappen van toepassing om TLS in teschakelen door:
- Het poortnummer wijzigen van 1883 (MQTT) in 8883 (MQTTS)
- Het CA-basiscertificaat doorgeven aan de mosquitto_pub en mosquitto_sub clients met behulp van een parameter die vergelijkbaar is met
--cafile /certs/certs/azure-iot-test-only.root.ca.cert.pem - Het doorgeven van de werkelijke hostnaam die is ingesteld in IoT Edge in plaats van via de hostnaamparameter die wordt doorgegeven aan de mosquitto_pub- en mosquitto_sub-clients om validatie van de certificaatketen
localhostmogelijk te maken
Publiceren en abonneren op IoT Hub onderwerpen
Met de Apparaat-SDK's van Azure IoT kunnen clients al IoT Hub-bewerkingen uitvoeren, maar het publiceren/abonneren op door de gebruiker gedefinieerde onderwerpen is niet toegestaan. IoT Hub kunnen worden uitgevoerd met behulp van MQTT-clients met behulp van semantiek voor publiceren en abonneren, zolang de protocollen van de IoT-hub primitief in acht worden genomen. We gaan de specifieke informatie door om te begrijpen hoe deze protocollen werken.
Stuur telemetriegegevens naar IoT Hub
Het verzenden van telemetriegegevens naar IoT Hub is vergelijkbaar met publiceren op een door de gebruiker gedefinieerd onderwerp, maar met behulp van een specifiek IoT Hub onderwerp:
- Voor een apparaat wordt telemetrie verzonden over het onderwerp:
devices/<device_name>/messages/events/ - Voor een module wordt telemetrie verzonden over het volgende onderwerp:
devices/<device_name>/modules/<module_name>/messages/events/
Maak daarnaast een route zoals voor het verzenden van telemetrie van de FROM /messages/* INTO $upstream IoT Edge MQTT-broker naar de IoT-hub. Zie Routes declareer voor meer informatie over routering.
Tweelingen krijgen
Het verkrijgen van de apparaat-/module-dubbel is geen typisch MQTT-patroon. De client moet een aanvraag indienen voor de dubbel die IoT Hub gaat verwerken.
Om tweelingen te ontvangen, moet de client zich abonneren op een IoT Hub onderwerp $iothub/twin/res/# . Deze onderwerpnaam wordt overgenomen van IoT Hub en alle clients moeten zich abonneren op hetzelfde onderwerp. Dit betekent niet dat apparaten of modules de dubbel van elkaar ontvangen. IoT Hub en IoT Edge hub weet waar de tweeling moet worden geleverd, zelfs als alle apparaten naar dezelfde onderwerpnaam luisteren.
Zodra het abonnement is gemaakt, moet de client om de tweeling vragen door een bericht te publiceren naar een IoT Hub onderwerp waarbij een $iothub/twin/GET/?rid=<request_id>/# <request_id> willekeurige id is. De IoT-hub verzendt vervolgens het antwoord met de aangevraagde gegevens over het onderwerp $iothub/twin/res/200/?rid=<request_id> , waarop de client zich abonneert. Op deze manier kan een client de aanvragen koppelen aan de antwoorden.
Dubbele patches ontvangen
Als u dubbele patches wilt ontvangen, moet een client zich abonneren op speciaal IoTHub-onderwerp $iothub/twin/PATCH/properties/desired/# . Zodra het abonnement is gemaakt, ontvangt de client de dubbele patches die zijn verzonden door IoT Hub over dit onderwerp.
Directe methoden ontvangen
Het ontvangen van een directe methode is vergelijkbaar met het ontvangen van volledige tweelingen met de toevoeging dat de client moet bevestigen dat deze de aanroep heeft ontvangen. Eerst abonneert de client zich op het speciale onderwerp van de IoT-hub. $iothub/methods/POST/# Zodra er een directe methode is ontvangen in dit onderwerp, moet de client de aanvraag-id extraheren uit het subonderwerp waarop de directe methode wordt ontvangen en ten slotte een bevestigingsbericht publiceren op een speciaal onderwerp voor rid IoT $iothub/methods/res/200/<request_id> Hub.
Directe methoden verzenden
Het verzenden van een directe methode is een HTTP-aanroep en gaat dus niet via de MQTT-broker. Zie Directe methoden begrijpen en aanroepen voor het verzenden van een directe methode naar de IoT-hub. Als u een directe methode lokaal naar een andere module wilt verzenden, bekijkt u dit voorbeeld van het aanroepen van de directe methode van azure IoT C# SDK.
Publiceren en abonneren tussen MQTT-brokers
Om twee MQTT-brokers te verbinden, bevat IoT Edge hub een MQTT-brug. Een MQTT-brug wordt vaak gebruikt om een MQTT-broker die wordt uitgevoerd, te verbinden met een andere MQTT-broker. Slechts een subset van het lokale verkeer wordt doorgaans naar een andere broker ge pusht.
Notitie
De IoT Edge hub bridge kan momenteel alleen worden gebruikt tussen geneste IoT Edge apparaten. Het kan niet worden gebruikt om gegevens naar IoT Hub te verzenden, omdat IoT Hub geen volledige MQTT-broker is. Zie Communiceren met uw IoT-hub met behulp van het MQTT-protocol voor meer informatie over de ondersteuning van IoT Hub MQTT-brokerfuncties. Zie een downstream Verbinding maken-IoT Edge IoT Edge naar een Azure IoT Edge-gateway voor meer informatie over het nesten van Azure IoT Edge-apparaten.
In een geneste configuratie fungeert de MQTT-brug van de IoT Edge-hub als een client van de bovenliggende MQTT-broker. Daarom moeten autorisatieregels worden ingesteld op de bovenliggende EdgeHub, zodat de onderliggende EdgeHub specifieke door de gebruiker gedefinieerde onderwerpen kan publiceren en zich erop kan abonneren.
De IoT Edge MQTT-brug wordt geconfigureerd via een JSON-structuur die via de dubbel naar de IoT Edge hub wordt verzonden. Bewerk een IoT Edge hub-dubbel om de MQTT-brug te configureren.
Notitie
Voor de openbare preview ondersteunt alleen de Azure CLI implementaties met MQTT Bridge-configuraties. De Azure Portal biedt momenteel geen ondersteuning voor het bewerken van IoT Edge hub-dubbel en de configuratie van de MQTT-brug.
De MQTT-brug kan worden geconfigureerd om een IoT Edge hub MQTT-broker te verbinden met meerdere externe brokers. Voor elke externe broker zijn de volgende instellingen vereist:
endpointis het adres van de externe MQTT-broker om verbinding mee te maken. Alleen bovenliggende IoT Edge worden momenteel ondersteund en worden gedefinieerd door de variabele$upstream.settingsdefinieert welke onderwerpen moeten worden overbrugd voor een eindpunt. Er kunnen meerdere instellingen per eindpunt zijn en de volgende waarden worden gebruikt om het te configureren:direction: om u te abonneren op de onderwerpen van de externe broker of om te publiceren naar de onderwerpeninoutvan de externe brokertopic: basisonderwerppatroon dat moet worden gematcht. MQTT-jokertekens kunnen worden gebruikt om dit patroon te definiëren. Verschillende voorvoegsels kunnen worden toegepast op dit onderwerppatroon op de lokale broker en externe broker.outPrefix: Voorvoegsel dat wordt toegepast op hettopicpatroon op de externe broker.inPrefix: Voorvoegsel dat wordt toegepast op hettopicpatroon op de lokale broker.
Hieronder vindt u een voorbeeld van een IoT Edge MQTT Bridge-configuratie die alle berichten die zijn ontvangen over onderwerpen van een bovenliggend IoT Edge-apparaat opnieuw op een onderliggend IoT Edge-apparaat in dezelfde onderwerpen, en alle berichten die worden verzonden over onderwerpen van een onderliggend IoT Edge-apparaat opnieuw naar een bovenliggend IoT Edge-apparaat op onderwerpen alerts/# /local/telemetry/# /remote/messages/# gepubliceerd.
{
"schemaVersion": "1.2",
"mqttBroker": {
"bridges": [{
"endpoint": "$upstream",
"settings": [{
"direction": "in",
"topic": "alerts/#"
},
{
"direction": "out",
"topic": "#",
"inPrefix": "/local/telemetry/",
"outPrefix": "/remote/messages/"
}
]
}]
}
}
Andere opmerkingen over de IoT Edge hub MQTT Bridge:
- Het MQTT-protocol wordt automatisch gebruikt als upstream-protocol wanneer de MQTT-broker wordt gebruikt en dat IoT Edge wordt gebruikt in een geneste configuratie, bijvoorbeeld met een
parent_hostnameopgegeven. Zie Cloudcommunicatie voor meer informatie over upstream-protocollen. Zie voor meer informatie over geneste configuraties Verbinding maken downstream IoT Edge naar een Azure IoT Edge-gateway.
Volgende stappen
Bijlage - Voorbeeldimplementatiemanifest
Hieronder ziet u het volledige implementatiemanifest dat u kunt gebruiken om de MQTT Broker in te IoT Edge. Het implementeert IoT Edge versie 1.2 met de functie MQTT Broker ingeschakeld, edgeHub-poort 1883 ingeschakeld en een open autorisatiebeleid op test_topic de .
{
"modulesContent":{
"$edgeAgent":{
"properties.desired":{
"schemaVersion":"1.1",
"runtime":{
"type":"docker",
"settings":{
"minDockerVersion":"v1.25",
"loggingOptions":"",
"registryCredentials":{
}
}
},
"systemModules":{
"edgeAgent":{
"type":"docker",
"settings":{
"image":"mcr.microsoft.com/azureiotedge-agent:1.2",
"createOptions":"{}"
}
},
"edgeHub":{
"type":"docker",
"status":"running",
"restartPolicy":"always",
"settings":{
"image":"mcr.microsoft.com/azureiotedge-hub:1.2",
"createOptions":"{\"HostConfig\":{\"PortBindings\":{\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}],\"443/tcp\":[{\"HostPort\":\"443\"}],\"1883/tcp\":[{\"HostPort\":\"1883\"}]}}}"
},
"env":{
"experimentalFeatures__mqttBrokerEnabled":{
"value":"true"
},
"experimentalFeatures__enabled":{
"value":"true"
},
"RuntimeLogLevel":{
"value":"debug"
}
}
}
},
"modules":{
}
}
},
"$edgeHub":{
"properties.desired":{
"schemaVersion":"1.2",
"routes":{
"Upstream":"FROM /messages/* INTO $upstream"
},
"storeAndForwardConfiguration":{
"timeToLiveSecs":7200
},
"mqttBroker":{
"authorizations":[
{
"identities":[
"{{iot:identity}}"
],
"allow":[
{
"operations":[
"mqtt:connect"
]
}
]
},
{
"identities":[
"{{iot:identity}}"
],
"allow":[
{
"operations":[
"mqtt:publish",
"mqtt:subscribe"
],
"resources":[
"test_topic"
]
}
]
}
]
}
}
}
}
}