Inzicht in automatische ioT Edge-implementaties voor één apparaat of op schaal

Van toepassing op:IoT Edge 1.4 checkmark IoT Edge 1.4

Belangrijk

IoT Edge 1.4 is de ondersteunde release. Raadpleeg IoT Edge bijwerken als u een eerdere versie hebt.

Met automatische implementaties en gelaagde implementaties kunt u modules op grote aantallen IoT Edge-apparaten beheren en configureren.

Azure IoT Edge biedt twee manieren om de modules te configureren die moeten worden uitgevoerd op IoT Edge-apparaten. De eerste methode is het implementeren van modules per apparaat. U maakt een implementatiemanifest en past dit vervolgens toe op een bepaald apparaat op naam. De tweede methode is het automatisch implementeren van modules op elk geregistreerd apparaat dat voldoet aan een set gedefinieerde voorwaarden. U maakt een implementatiemanifest en definieert vervolgens op welke apparaten het van toepassing is op basis van tags in de apparaatdubbel.

U kunt niet per apparaat en automatische implementaties combineren. Zodra u ioT Edge-apparaten met automatische implementaties (met of zonder gelaagde implementaties) hebt gericht, worden implementaties per apparaat niet meer ondersteund.

Dit artikel is gericht op het configureren en bewaken van vloot van apparaten, gezamenlijk aangeduid als automatische ioT Edge-implementaties.

De basisimplementatiestappen zijn als volgt:

  1. Een operator definieert een implementatiemanifest dat een set modules en de doelapparaten beschrijft.
  2. Als gevolg hiervan communiceert de IoT Hub-service met alle doelapparaten om ze te configureren met de gedeclareerde modules.
  3. De IoT Hub-service haalt de status op van de IoT Edge-apparaten en stelt deze beschikbaar voor de operator. Een operator kan bijvoorbeeld zien wanneer een Edge-apparaat niet is geconfigureerd of als een module mislukt tijdens runtime.
  4. Wanneer nieuw gerichte IoT Edge-apparaten online komen en verbinding maken met IoT Hub, worden ze geconfigureerd voor de implementatie.

In dit artikel wordt elk onderdeel beschreven dat betrokken is bij het configureren en bewaken van een implementatie. Zie IoT Edge-modules op schaal implementeren en bewaken voor een overzicht van het maken en bijwerken van een implementatie.

Implementatie

Met een automatische implementatie van IoT Edge worden installatiekopieën van IoT Edge-modules toegewezen die moeten worden uitgevoerd als exemplaren op een bepaalde set IoT Edge-apparaten. De geautomatiseerde implementatie configureert een IoT Edge-implementatiemanifest om een lijst met modules met de bijbehorende initialisatieparameters op te nemen. Een implementatie kan worden toegewezen aan één apparaat (op basis van apparaat-id) of aan een groep apparaten (op basis van tags). Zodra een IoT Edge-apparaat een implementatiemanifest ontvangt, downloadt en installeert het de containerinstallatiekopieën van de respectieve containeropslagplaatsen en configureert het deze dienovereenkomstig. Zodra een implementatie is gemaakt, kan een operator de implementatiestatus controleren om te zien of de doelapparaten juist zijn geconfigureerd.

Alleen IoT Edge-apparaten kunnen worden geconfigureerd met een implementatie. De volgende vereisten moeten op het apparaat staan voordat deze de implementatie kan ontvangen:

  • Het basisbesturingssysteem
  • Een containerbeheersysteem, zoals Moby of Docker
  • Inrichting van de IoT Edge-runtime

Distributiemanifest

Een implementatiemanifest is een JSON-document waarin de modules worden beschreven die moeten worden geconfigureerd op de beoogde IoT Edge-apparaten. Het bevat de configuratiemetagegevens voor alle modules, inclusief de vereiste systeemmodules (met name de IoT Edge-agent en IoT Edge-hub).

De configuratiemetagegevens voor elke module omvatten:

  • Versie
  • Type
  • Status (bijvoorbeeld actief of gestopt)
  • Beleid voor opnieuw opstarten
  • Installatiekopieën en containerregister
  • Routes voor gegevensinvoer en -uitvoer

Als de module-installatiekopieën worden opgeslagen in een privécontainerregister, bevat de IoT Edge-agent de registerreferenties.

Doelvoorwaarde

De doelapparaatvoorwaarde wordt continu geëvalueerd gedurende de levensduur van de implementatie. Nieuwe apparaten die aan de vereisten voldoen, worden opgenomen en alle bestaande apparaten die niet meer aan de vereisten voldoen, worden verwijderd. De implementatie wordt opnieuw geactiveerd als de service een wijziging in de doelvoorwaarde detecteert.

U hebt bijvoorbeeld een implementatie met een doelvoorwaarde tags.environment = 'prod'. Wanneer u de implementatie start, zijn er 10 productieapparaten. De modules zijn geïnstalleerd op deze 10 apparaten. De status van de IoT Edge-agent toont 10 apparaten, 10 geslaagde antwoorden, 0 mislukte antwoorden en 0 antwoorden in behandeling. Nu voegt u nog vijf apparaten toe met tags.environment = 'prod'. De service detecteert de wijziging en de status van de IoT Edge-agent toont nu 15 apparaten, 10 geslaagde antwoorden, 0 mislukte antwoorden en vijf antwoorden in behandeling terwijl deze wordt geïmplementeerd op de vijf nieuwe apparaten.

Als een implementatie geen doelvoorwaarde heeft, wordt deze toegepast op geen apparaten.

Gebruik een Boole-voorwaarde voor apparaatdubbeltags, gerapporteerde eigenschappen van apparaatdubbels of deviceId om de doelapparaten te selecteren. Als u een voorwaarde met tags wilt gebruiken, moet u een "tags":{} sectie in de apparaatdubbel toevoegen onder hetzelfde niveau als eigenschappen. Zie Apparaatdubbels begrijpen en gebruiken in IoT Hub voor meer informatie over tags in een apparaatdubbel. Zie IoT Hub-querytaaloperators en IS_DEFINED functie voor meer informatie over querybewerkingen.

Voorbeelden van doelvoorwaarden:

  • deviceId ='linuxprod1'
  • tags.environment ='prod'
  • tags.environment = 'prod' AND tags.location = 'westus'
  • tags.environment = 'prod' OR tags.location = 'westus'
  • tags.operator = 'John' AND tags.environment = 'prod' AND NOT deviceId = 'linuxprod1'
  • properties.reported.devicemodel = '4000x'
  • IS_DEFINED(tags.remote)
  • NIET IS_DEFINED(tags.location.building)
  • tags.environment != null
  • [geen]

Houd rekening met deze beperkingen wanneer u een doelvoorwaarde maakt:

  • In de apparaatdubbel kunt u alleen een doelvoorwaarde bouwen met behulp van tags, gerapporteerde eigenschappen of deviceId.
  • Dubbele aanhalingstekens zijn niet toegestaan in een gedeelte van de doelvoorwaarde. Gebruik enkele aanhalingstekens.
  • Enkele aanhalingstekens vertegenwoordigen de waarden van de doelvoorwaarde. Daarom moet u de enkele aanhalingsteken met een andere aanhalingsteken als deze deel uitmaakt van de apparaatnaam. Als u bijvoorbeeld een apparaat wilt instellen met de naam operator'sDevice, schrijft deviceId='operator''sDevice'u .
  • Cijfers, letters en de volgende tekens zijn toegestaan in doelvoorwaardewaarden: "()<>@,;:\\"/?={} \t\n\r.
  • De volgende tekens zijn niet toegestaan in doelvoorwaardesleutels:/;.

Prioriteit

Een prioriteit bepaalt of een implementatie moet worden toegepast op een doelapparaat ten opzichte van andere implementaties. Een implementatieprioriteit is een positief geheel getal binnen het bereik van 0 tot en met 2.147.483.647. Grotere getallen geven een hogere prioriteit aan. Als een IoT Edge-apparaat is gericht op meer dan één implementatie, is de implementatie met de hoogste prioriteit van toepassing. Implementaties met lagere prioriteiten worden niet toegepast en worden ook niet samengevoegd. Als een apparaat is gericht op twee of meer implementaties met gelijke prioriteit, is de laatst gemaakte implementatie (bepaald door de tijdstempel voor het maken) van toepassing.

Etiketten

Labels zijn tekenreekssleutel-waardeparen die u kunt gebruiken om implementaties te filteren en te groeperen. Een implementatie kan meerdere labels hebben. Labels zijn optioneel en hebben geen invloed op de configuratie van IoT Edge-apparaten.

Metrische gegevens

Standaard rapporteren alle implementaties over vier metrische gegevens:

  • Het doel toont de IoT Edge-apparaten die overeenkomen met de voorwaarde implementatiedoel.
  • Toegepast toont de beoogde IoT Edge-apparaten die niet zijn gericht op een andere implementatie met een hogere prioriteit.
  • Rapportage geslaagd toont de IoT Edge-apparaten die hun modules rapporteren als geïmplementeerd.
  • Rapportagefout toont de IoT Edge-apparaten die een of meer modules rapporteren die niet zijn geïmplementeerd. Als u de fout verder wilt onderzoeken, maakt u extern verbinding met deze apparaten en bekijkt u de logboekbestanden.

Daarnaast kunt u uw eigen aangepaste metrische gegevens definiëren om de implementatie te bewaken en te beheren.

Metrische gegevens bieden samenvattingsaantallen van de verschillende statussen die apparaten kunnen rapporteren als gevolg van het toepassen van een implementatieconfiguratie. Metrische gegevens kunnen query's uitvoeren op gerapporteerde eigenschappen van edgeHub-moduledubbels, zoals lastDesiredStatus of last Verbinding maken Time.

Bijvoorbeeld:

SELECT deviceId FROM devices
  WHERE properties.reported.lastDesiredStatus.code = 200

Het toevoegen van uw eigen metrische gegevens is optioneel en heeft geen invloed op de werkelijke configuratie van IoT Edge-apparaten.

Gelaagde implementatie

Gelaagde implementaties zijn automatische implementaties die samen kunnen worden gecombineerd om het aantal unieke implementaties te verminderen dat moet worden gemaakt. Gelaagde implementaties zijn handig in scenario's waarbij dezelfde modules opnieuw worden gebruikt in verschillende combinaties in veel automatische implementaties.

Gelaagde implementaties hebben dezelfde basisonderdelen als elke automatische implementatie. Ze richten zich op apparaten op basis van tags in de apparaatdubbels en bieden dezelfde functionaliteit rond labels, metrische gegevens en statusrapportage. Gelaagde implementaties hebben ook prioriteiten toegewezen. In plaats van de prioriteit te gebruiken om te bepalen welke implementatie op een apparaat wordt toegepast, bepaalt de prioriteit hoe meerdere implementaties op een apparaat worden gerangschikt. Als twee gelaagde implementaties bijvoorbeeld een module of route met dezelfde naam hebben, wordt de gelaagde implementatie met de hogere prioriteit toegepast terwijl de lagere prioriteit wordt overschreven.

De systeemruntimemodules, ook wel edgeAgent en edgeHub genoemd, zijn niet geconfigureerd als onderdeel van een gelaagde implementatie. Voor elk IoT Edge-apparaat waarop een gelaagde implementatie is gericht, moet er eerst een standaard automatische implementatie op worden toegepast. De automatische implementatie biedt de basis waarop gelaagde implementaties kunnen worden toegevoegd.

Een IoT Edge-apparaat kan één en slechts één standaard automatische implementatie toepassen, maar kan meerdere gelaagde automatische implementaties toepassen. Gelaagde implementaties die gericht zijn op een apparaat, moeten een hogere prioriteit hebben dan de automatische implementatie voor dat apparaat.

Denk bijvoorbeeld aan het volgende scenario van een bedrijf dat gebouwen beheert. Het bedrijf heeft IoT Edge-modules ontwikkeld voor het verzamelen van gegevens van beveiligingscamera's, bewegingssensoren en liften. Niet alle gebouwen kunnen echter alle drie de modules gebruiken. Met standaard automatische implementaties moet het bedrijf afzonderlijke implementaties maken voor alle modulecombinaties die hun gebouwen nodig hebben.

Screenshot of showing that standard automatic deployments need to accommodate every module combination.

Zodra het bedrijf overschakelt naar gelaagde automatische implementaties, kunnen ze echter dezelfde modulecombinaties maken voor hun gebouwen met minder implementaties om te beheren. Elke module heeft een eigen gelaagde implementatie en de apparaattags bepalen welke modules aan elk gebouw worden toegevoegd.

Screenshot that shows how layered automatic deployments simplify scenarios where the same modules are combined in different ways.

Configuratie van moduledubbel

Wanneer u met gelaagde implementaties werkt, kunt u, opzettelijk of anderszins, twee implementaties hebben met dezelfde module die is gericht op een apparaat. In die gevallen kunt u bepalen of de implementatie met een hogere prioriteit de moduledubbel moet overschrijven of eraan moet toevoegen. U hebt bijvoorbeeld een implementatie die dezelfde module toepast op 100 verschillende apparaten. 10 van deze apparaten bevinden zich echter in beveiligde faciliteiten en hebben aanvullende configuratie nodig om te communiceren via proxyservers. U kunt een gelaagde implementatie gebruiken om eigenschappen van moduledubbels toe te voegen waarmee deze 10 apparaten veilig kunnen communiceren zonder de bestaande moduledubbelgegevens van de basisimplementatie te overschrijven.

U kunt gewenste eigenschappen van moduledubbel toevoegen in het implementatiemanifest. In een standaardimplementatie voegt u eigenschappen toe in de sectie properties.desired van de moduledubbel. Maar in een gelaagde implementatie kunt u een nieuwe subset van gewenste eigenschappen declareren.

In een standaardimplementatie kunt u bijvoorbeeld de module voor de gesimuleerde temperatuursensor toevoegen met de volgende gewenste eigenschappen waarmee u gegevens in intervallen van vijf seconden moet verzenden:

"SimulatedTemperatureSensor": {
  "properties.desired": {
    "SendData": true,
    "SendInterval": 5
  }
}

In een gelaagde implementatie die is gericht op sommige of al deze apparaten, kunt u een eigenschap toevoegen waarmee de gesimuleerde sensor 1000 berichten moet verzenden en vervolgens moet stoppen. U wilt de bestaande eigenschappen niet overschrijven, dus u maakt een nieuwe sectie in de gewenste eigenschappen met de naam layeredProperties, die de nieuwe eigenschap bevat:

"SimulatedTemperatureSensor": {
  "properties.desired.layeredProperties": {
    "StopAfterCount": 1000
  }
}

Een apparaat waarop beide implementaties zijn toegepast, weerspiegelt de volgende eigenschappen in de moduledubbel voor de gesimuleerde temperatuursensor:

"properties": {
  "desired": {
    "SendData": true,
    "SendInterval": 5,
    "layeredProperties": {
      "StopAfterCount": 1000
    }
  }
}

Als u het properties.desired veld van de moduledubbel instelt in een gelaagde implementatie, properties.desired overschrijft u de gewenste eigenschappen voor die module in eventuele implementaties met een lagere prioriteit.

Gefaseerde implementatie

Een gefaseerde implementatie is een algemeen proces waarbij een operator wijzigingen implementeert in een verbrede set IoT Edge-apparaten. Het doel is om wijzigingen geleidelijk aan te brengen om het risico op grootschalige wijzigingen die fouten veroorzaken, te verminderen. Met automatische implementaties kunt u gefaseerde implementaties beheren in een vloot van IoT Edge-apparaten.

Een gefaseerde implementatie wordt uitgevoerd in de volgende fasen en stappen:

  1. Stel een testomgeving van IoT Edge-apparaten in door ze in te richten en een apparaatdubbeltag in te stellen, zoals tag.environment='test'. De testomgeving moet de productieomgeving spiegelen waarop de implementatie uiteindelijk wordt gericht.
  2. Maak een implementatie, inclusief de gewenste modules en configuraties. De doelvoorwaarde moet gericht zijn op de testomgeving van het IoT Edge-apparaat.
  3. Valideer de nieuwe moduleconfiguratie in de testomgeving.
  4. Werk de implementatie bij om een subset van IoT Edge-apparaten in productie op te nemen door een nieuwe tag toe te voegen aan de doelvoorwaarde. Zorg er ook voor dat de prioriteit voor de implementatie hoger is dan andere implementaties die momenteel op die apparaten zijn gericht.
  5. Controleer of de implementatie is geslaagd op de beoogde IoT Edge-apparaten door de implementatiestatus te bekijken.
  6. Werk de implementatie bij om alle resterende IoT Edge-apparaten te targeten.

Terugdraaiactie

Implementaties kunnen worden teruggedraaid als u fouten of onjuiste configuraties ontvangt. Omdat een implementatie de absolute moduleconfiguratie voor een IoT Edge-apparaat definieert, moet een extra implementatie ook worden gericht op hetzelfde apparaat met een lagere prioriteit, zelfs als het doel is om alle modules te verwijderen.

Als u een implementatie verwijdert, worden de modules niet van doelapparaten verwijderd. Er moet een andere implementatie zijn die een nieuwe configuratie definieert voor de apparaten, zelfs als het een lege implementatie is.

Het verwijderen van een implementatie kan echter modules van het doelapparaat verwijderen als het een gelaagde implementatie was. Een gelaagde implementatie werkt de onderliggende implementatie bij en voegt mogelijk modules toe. Als u een gelaagde implementatie verwijdert, wordt de update naar de onderliggende implementatie verwijderd, waardoor modules mogelijk worden verwijderd.

Een apparaat heeft bijvoorbeeld basisimplementatie A en gelaagde implementaties O en M toegepast (zodat de A-, O- en M-implementaties op het apparaat worden geïmplementeerd). Als gelaagde implementatie M wordt verwijderd, worden A en O toegepast op het apparaat en worden de modules die uniek zijn voor implementatie M verwijderd.

Voer terugdraaiacties uit in de volgende volgorde:

  1. Controleer of een tweede implementatie ook is gericht op dezelfde apparaatset. Als het doel van het terugdraaien is om alle modules te verwijderen, mag de tweede implementatie geen modules bevatten.
  2. Wijzig of verwijder de doelvoorwaardeexpressie van de implementatie die u wilt terugdraaien, zodat de apparaten niet langer voldoen aan de doelvoorwaarde.
  3. Controleer of het terugdraaien is geslaagd door de implementatiestatus weer te geven.
    • De teruggedraaide implementatie mag niet langer de status weergeven voor de apparaten die zijn teruggedraaid.
    • De tweede implementatie moet nu de implementatiestatus bevatten voor de apparaten die zijn teruggedraaid.

Volgende stappen