Efficiënte implementatie van Docker-installatiekopieën voor connectiviteit met lage bandbreedte

In dit artikel wordt een oplossing beschreven voor het implementeren van ioT-edge-modules (internet-of-things) in containers tussen onregelmatige of lage bandbreedte internetverbinding.

Edge-verwerking is een belangrijk IoT-patroon (Internet of Things) voor het bieden van connectiviteit met lage latentie en het besparen van bandbreedte, zoals in mobiele scenario's. IoT-systemen richten doorgaans edge-apparaten in door softwarecontainerinstallatiekopieën te implementeren. Onderbroken containerimplementaties via onregelmatige internetverbinding met lage bandbreedte kunnen fouten veroorzaken in mobiele scenario's. IoT-scenario's met beperkte, onregelmatige of lage bandbreedte hebben betrouwbare en flexibele implementatiemogelijkheden nodig.

In dit voorbeeld wilde een groot logistiek bedrijf zijn wereldwijde productverzendingstracering verbeteren. Het bedrijf heeft goederen verzonden met verschillende grond-, lucht- en zeetransportmethoden naar veel landen, waaronder gebieden met onregelmatige, lage bandbreedte internetverbinding. Afhankelijk van het type goederen hadden productzendingen verschillende IoT-verzekeringen, veiligheid of traceringsapparaten geïnstalleerd, met verschillende mogelijkheden. Apparaten omvatten GPS-trackers, temperatuursensoren en hulpprogramma's voor gegevensopname.

Het bedrijf had problemen met het bijwerken van apparaten via hun onlangs ontwikkelde Azure IoT Edge-platform. De belangrijkste pijnpunten waren:

• Hoog bandbreedteverbruik bij het implementeren van bijgewerkte software op apparaten.
• Geen gestandaardiseerde geautomatiseerde implementatie op verschillende apparaten.
• Beperkte flexibiliteit van technologieselectie.

Om deze problemen op te lossen, heeft het ontwikkelteam een oplossing gemaakt die:

• Minimaliseert de grootte van de implementatie op elk apparaat, waardoor de bandbreedte wordt verminderd.
• Implementeert een gestandaardiseerde Docker-containerimplementatie van het IoT Edge-platform naar heterogene externe IoT-apparaten.
• Maakt betrouwbare implementatiebewaking mogelijk.
• Maakt gebruik van verschillende Azure DevOps- en cloudservices en maakt gebruik van de favoriete verouderde hulpprogramma's van de klant.

De oplossing heeft de betrouwbaarheid en tolerantie van het inrichtingsproces voor apparaten aanzienlijk verhoogd in omgevingen met beperkte connectiviteit. In dit artikel worden de details van de oplossing en het evaluatieproces voor oplossingsopties beschreven.

Vereisten van de klant

De klant had de volgende vereisten:

• De oplossing moet ondersteuning bieden voor onregelmatige cloudconnectiviteit met lage bandbreedte.
• Geïmplementeerde toepassingen moeten lokaal blijven worden uitgevoerd.
• Lokale medewerkers moeten functionaliteit offline of zonder een retourvertraging in de cloud gebruiken.
• Wanneer de verbinding is gemaakt, moet de oplossing de cloudverbinding efficiënt gebruiken.
• De oplossing moet prioriteit geven aan het verzenden van gegevens volgens consistent gedefinieerde bedrijfsregels voor alle producten.

Er zijn ook de volgende gedetailleerde vereisten:

• Afbeeldingsbestanden worden overgebracht over een lage bandbreedte, onregelmatige connectiviteitssatellietverbinding.
• De hoeveelheid gegevens die wordt overgedragen, moet worden geminimaliseerd.
• Het overdragen van bestanden naar apparaten maakt gebruik van de voorkeurstoepassing van derden van de klant.
• Apparaatworkloads maken gebruik van Docker-installatiekopieën in IoT Edge.
• Afbeeldingsgrootten variëren van tientallen MB tot meerdere GB.
• IoT Edge-modules worden geschreven in .NET Core 2.2.

Potentiële gebruikscases

Deze oplossing is geschikt voor IoT-scenario's waarbij softwarecontainers oplossingen leveren via lage bandbreedte, onregelmatige verbindingen. Voorbeelden zijn:

• Bewaking van olie, gas en mijnbouw op afstand
• Over-the-air auto-updates
• Overal waar een sterke verbinding niet gegarandeerd is

Architectuur

In scenario's met hoge bandbreedte haalt Azure IoT Edge rechtstreeks installatiekopieën op uit een dockerregister dat toegankelijk is via internet, ofwel een Docker-hub of een privéhub zoals Azure Container Registry. Deze functionaliteit is hetzelfde als het uitvoeren van de docker pull <image_name> opdracht.

Met mogelijk onregelmatige netwerktoegang, zoals een satellietinternetverbinding, is de Docker-pull-methode onbetrouwbaar. De voortgang wordt niet in de cache opgeslagen als de internetverbinding afneemt terwijl Docker de installatiekopie ophaalt. Wanneer de internetverbinding wordt hervat, moet Docker de installatiekopie opnieuw vanaf het begin ophalen.

De oplossing maakt gebruik van een alternatief implementatiemechanisme, binaire patching van Docker-installatiekopieën, om de bandbreedte te verminderen en te compenseren voor onregelmatige connectiviteit.

Gegevensstroom

1. Ontwikkelaars communiceren met de broncode van de Edge-module in een opslagplaats voor broncode.
2. Container Registry slaat de Docker-installatiekopieën van elke module op.
3. De manifestopslagplaats bevat de implementatiemanifesten voor alle werkstromen.
4. Elke module heeft een build-pijplijn voor Azure Pipelines die gebruikmaakt van een algemene Docker-build om automatisch modules te maken en te registreren.
5. Met de pijplijn voor installatiekopieën naar apparaat worden de Docker-installatiekopieën geïmplementeerd op de doelapparaten, zoals gedefinieerd door het manifestbestand.
6. De manifest-naar-apparaat-pijplijn pusht het implementatiemanifest naar de juiste Azure IoT Hub voor het apparaat dat wordt bijgewerkt.
7. Een oplossing voor snelle bestandsoverdracht van derden draagt de bestanden van een Azure Storage-account over naar het apparaat.
8. De IoT Edge-module Afbeeldingsreconstructie past de ontvangen patches op de apparaten toe.
9. IoT Hub ontvangt statusberichten van de module Afbeeldingsreconstructie en stelt het implementatiemanifest voor het apparaat in. De rest van de pijplijnstroom maakt gebruik van dit implementatiemanifest.
10. Azure Functions bewaakt de IoT Hub-berichtenstroom, werkt de SQL-database bij en geeft de gebruiker een melding over succes of mislukking.
11. Azure SQL Database houdt exemplaren bij op de doelapparaten en de Azure-services, tijdens en na de implementatie.

Onderdelen

• Azure IoT Edge voert containerworkloads uit op apparaten, wat connectiviteit met lage latentie biedt en bandbreedte bespaart.
• Azure IoT Hub is een beheerde, in de cloud gehoste service die fungeert als een centrale berichtenhub tussen IoT-toepassingen en de apparaten die ze beheren.
• Azure Container Registry is een privéregisterservice in de cloud voor het opslaan en beheren van persoonlijke Docker-containerinstallatiekopieën en gerelateerde artefacten.
• Azure Pipelines combineert continue integratie (CI) en continue levering (CD) om automatisch code te testen en te bouwen en naar elk doel te verzenden.
• Azure Functions is een serverloos rekenplatform waarmee door gebeurtenissen geactiveerde code wordt uitgevoerd zonder dat u infrastructuur hoeft in te richten of te beheren.
• Azure Storage biedt zeer schaalbare, veilige, goed presterende en rendabele opslag voor alle typen zakelijke gegevens, objecten en bestanden.
• Azure SQL Database is een volledig beheerde relationele databaseservice voor meerdere modellen die is gebouwd voor de cloud.
• Docker is een open platform voor het ontwikkelen, verzenden en uitvoeren van toepassingen in containers.

Alternatieven

Het ontwikkelingsteam heeft verschillende opties geëvalueerd voordat ze beslissen over de volledige deltaoverdrachtoplossing voor Docker-installatiekopieën. In de volgende secties worden de alternatieven en resultaten van de evaluatie beschreven.

Het team heeft de volgende evaluatiecriteria voor elke optie overwogen:

• Of de oplossing al dan niet voldoet aan de vereisten.
• Of er nu een lage, gemiddelde of hoge hoeveelheid logica moet worden geïmplementeerd op de apparaten.
• Of er nu een lage, gemiddelde of hoge hoeveelheid logica moet worden geïmplementeerd in Azure.
• Bandbreedte-efficiëntie of verhouding van overgedragen gegevens tot de totale grootte van een installatiekopie, voor het overdragen van een containerinstallatiekopie.

Bandbreedte-efficiëntie omvat scenario's waarbij:

• Er bestaan geen installatiekopieën op het apparaat.
• Er bestaat een installatiekopieën met dezelfde basis op het apparaat.
• Er bestaat een installatiekopieën van een eerdere toepassingsversie op het apparaat.
• Er bestaat een installatiekopie voor de toepassing die is gebouwd op een eerdere basisinstallatiekopie op het apparaat.

Het team heeft de volgende scenario's gebruikt om bandbreedte-efficiëntie te evalueren:

Scenario	Beschrijving
Afbeelding overdragen met basislaag al op het apparaat	Een nieuwe installatiekopieën overdragen wanneer een andere installatiekopieën die al op het apparaat staan, de basisinstallatiekopieën delen. Dit scenario vertegenwoordigt het implementeren van een nieuwe toepassing voor de eerste keer, wanneer er al een andere toepassing in hetzelfde besturingssysteem en framework bestaat.
De toepassingslaag bijwerken	Wijzig alleen de code voor de installatiekopieën van een bestaande toepassing. Dit scenario vertegenwoordigt een typische wijziging wanneer een gebruiker een nieuwe functie doorvoert.
De basisinstallatiekopie bijwerken	Wijzig de versie van de basisinstallatiekopie waarop de toepassing is gebouwd.

Optie Docker-lagen overdragen

Een Docker-containerinstallatiekopieën is een UnionFS-koppeling van alleen-lezen bestandssysteemverschillen, met een andere beschrijfbare laag voor wijzigingen die zijn aangebracht terwijl de container wordt uitgevoerd. De bestandssystemen worden lagen genoemd, die in feite mappen en bestanden zijn. Lagen stapelen om de basis te vormen van het hoofdbestandssysteem van de container. Omdat lagen alleen-lezen zijn, kunnen verschillende afbeeldingen dezelfde laag delen als ze de laag gemeen hebben.

Met de optie Docker-lagen overdragen worden de lagen tussen installatiekopieën opnieuw gebruikt en worden alleen nieuwe lagen naar het apparaat overgedragen. Deze optie is het handigst voor installatiekopieën die dezelfde basislaag delen, meestal het besturingssysteem of voor het bijwerken van versies van bestaande installatiekopieën.

Nadelen van deze methode zijn:

• De orchestrator moet informatie bijhouden over welke lagen er bestaan op welke apparaten.
• Wijzigingen in de basislaag zorgen ervoor dat de hashes van alle volgende lagen worden gewijzigd.
• Vergelijking vereist consistente laag-hashes.
• Er kunnen afhankelijkheden zijn van Docker-opslag en Docker-belasting.

Docker-clientoptie wijzigen

Deze optie is gericht op het wijzigen of verpakken van de Docker-client, zodat het downloaden van lagen wordt hervat na een onderbreking. Standaard hervat een Docker-pull een download als de internetverbinding binnen ongeveer 30 minuten na de onderbreking is hersteld. Anders wordt de client afgesloten en gaan alle downloadvoortgang verloren.

Deze methode is levensvatbaar, maar had complicaties, waaronder:

• Alle installatiekopieën op het apparaat moeten worden geregistreerd bij de Docker-daemon waarmee de installatiekopieën worden opgehaald om de bandbreedte-efficiëntie te maximaliseren.
• Het opensource Docker-project moet worden gewijzigd om deze functionaliteit te ondersteunen, wat een risico op afwijzing door opensource-onderhouders tot gevolg heeft.
• Voor het overdragen van gegevens via HTTP in plaats van de voorkeursoplossing voor snelle bestandsoverdracht van de klant is het ontwikkelen van aangepaste logica voor opnieuw proberen vereist.
• Alle lagen moeten opnieuw worden verzonden wanneer een basisinstallatiekopieën worden gewijzigd.

Optie voor bouwen op edge-apparaat

Met deze methode wordt de buildomgeving van de installatiekopieën naar de apparaten verplaatst. De volgende gegevens worden naar het apparaat verzonden:

• De broncode voor de toepassing die wordt gebouwd
• Een kopie van alle NuGet-pakketten waarvan de code afhankelijk is
• De Docker-basisinstallatiekopieën voor de .NET Core-buildomgeving en -runtime
• Metagegevens over de eindafbeelding

Een buildagent op het apparaat bouwt vervolgens de installatiekopieën en registreert deze bij Docker Manager van het apparaat.

Deze oplossing is geweigerd omdat:

• Er moet nog steeds een manier zijn om grote Docker-installatiekopieën naar de apparaten te verplaatsen. Installatiekopieën voor het bouwen van .NET-toepassingen zijn groter dan de app-installatiekopieën zelf.
• Deze methode werkt alleen voor toepassingen waar het team de broncode heeft, zodat deze geen installatiekopieën van derden kan gebruiken.
• Voor de optie moeten NuGet-pakketten worden verpakt en de verplaatsing ervan naar de apparaten worden bijgehouden.
• Als een installatiekopieën niet konden worden gebouwd op het apparaat, moet het team op afstand fouten opsporen in de buildomgeving en de gemaakte installatiekopieën. Externe foutopsporing vereist een hoog gebruik van de mogelijk beperkte internetverbinding.

Optie voor deltaoverdracht voor volledige installatiekopieën

De gekozen benadering behandelt een Docker-installatiekopieën als één binair bestand. De Docker-opdracht save exporteert de installatiekopieën als een .tar-bestand . De oplossing exporteert de bestaande en nieuwe Docker-installatiekopieën en berekent de binaire delta die, wanneer deze wordt toegepast, de bestaande installatiekopieën transformeert in de nieuwe.

De oplossing houdt de bestaande Docker-installatiekopieën op de apparaten bij en bouwt binaire deltapatches om de bestaande installatiekopieën om te zetten in de nieuwe installatiekopieën. Het systeem draagt alleen de deltapatches over via de internetverbinding met lage bandbreedte. Deze oplossing vereist een aantal aangepaste logica om de binaire patches te bouwen, maar de minste hoeveelheid gegevens is verzonden naar apparaten.

Evaluatieresultaten

In de volgende tabel ziet u hoe elk van de bovenstaande oplossingen wordt gemeten op basis van de evaluatiecriteria.

	Voldoet aan de vragen	Apparaatlogica	Azure-logica	Transport	Eerste afbeelding	Basis op apparaat	App-laag bijwerken	Basislaag bijwerken
Docker-lagen overdragen	Ja	Beperkt	Gemiddeld	FileCatalyst	100%	10.5%	22.4%	100%
Docker-client wijzigen	Ja	Gemiddeld	Beperkt	HTTP	100%	10.5%	22.4%	100%
Bouwen op edge-apparaat	Nee	Hoog	Gemiddeld	FileCatalyst	N.v.t.	N.v.t.	N.v.t.	N.v.t.
Deltaoverdracht voor volledige installatiekopieën	Ja	Laag	Hoog	FileCatalyst	100%	3.2%	0.01%	16.1%

Overwegingen

Met deze overwegingen worden pijlers van het Azure Well-Architected Framework geïmplementeerd, een set richtlijnen die de kwaliteit van de werkbelasting verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Prestatie-efficiëntie

Deze oplossing vermindert de bandbreedte die wordt verbruikt door updates voor IoT-apparaten aanzienlijk. In de volgende tabellen ziet u een uitsplitsing van de verschillen in overdrachtsefficiëntie.

Afbeelding Reconstruor als bron:

Naam van installatiekopie	Afbeeldingsgrootte	Patchgrootte	Gegevensreductie
Gegevensvisualisatie	228 MB	79,6 MB	65.1%
Gesimuleerde WCD	188 MB	1,5 MB	99.2%
Proxy	258 MB	29,9 MB	88.4%

Vorige versie als bron:

Naam van installatiekopie	Afbeeldingsgrootte	Patchgrootte	Gegevensreductie
Gegevensvisualisatie	228 MB	0,01 MB	99,9%
Gesimuleerde WCD	188 MB	0,5 MB	99.7%
Proxy	258 MB	0,04 MB	99,9%

Operationele uitmuntendheid

De volgende secties bieden een gedetailleerd overzicht van de oplossing.

Opslagplaats voor broncode

Ontwikkelaars communiceren met de broncode van de Edge-module in een opslagplaats voor broncode. De opslagplaats bestaat uit mappen die de code voor elke module bevatten, als volgt:

\- repository root
    - modulea
    - modulea.csproj
    - module.json
    - Program.cs
    - Dockerfile

\- moduleb
    - moduleb.csproj
    - module.json
    - Program.cs
    - Dockerfile

Het aanbevolen aantal broncodeopslagplaatsen is:

• Eén opslagplaats voor alle modules in alle werkstromen.
• Eén opslagplaats voor broncode voor elke workstream.

Container Registry-exemplaren

Container Registry slaat de Docker-installatiekopieën van elke module op. Er zijn twee mogelijke configuraties voor Container Registry:

• Eén Container Registry-exemplaar waarin alle installatiekopieën worden opgeslagen.
• Twee Container Registry-exemplaren, één voor het opslaan van de installatiekopieën voor ontwikkeling, testen en foutopsporing, en een andere met alleen installatiekopieën die zijn gemarkeerd als productieklaar.

Manifestopslagplaats

De manifestopslagplaats bevat de implementatiemanifesten voor alle werkstromen. De sjablonen bevinden zich in mappen op basis van hun werkstroom. In dit voorbeeld zijn de twee werkstromen gedeelde infrastructuur en de containertoepassing.

\- repository root
     - Workstream1
         - deployment.template.json
     - Workstream2
         - deployment.template.json

Build-pijplijn voor Docker-installatiekopieën

Elke module heeft een build-pijplijn voor Azure Pipelines. De pijplijn maakt gebruik van een algemene Docker-build om modules te maken en te registreren. De pijplijn is verantwoordelijk voor:

• Beveiligingsscans van de broncode.
• Beveiligingsscans van de basisinstallatiekopieën voor het bouwen van de Docker-installatiekopieën.
• Eenheidstests voor de module uitvoeren.
• De bron inbouwen in een Docker-installatiekopieën. De afbeeldingstag bevat de BUILD_BUILDID, zodat de afbeelding altijd kan worden gekoppeld aan de broncode die deze heeft gemaakt.
• De installatiekopieën naar een Container Registry-exemplaar pushen.
• Het deltabestand wordt gemaakt.
• Een handtekeningbestand voor de afbeelding maken en het bestand opslaan in een Azure-opslagaccount.

Alle pijplijnexemplaren zijn gebaseerd op één YAML-pijplijndefinitie. De pijplijn kan op de modules reageren met behulp van omgevingsvariabelen. Filters activeren elke pijplijn alleen wanneer wijzigingen in een bepaalde map worden doorgevoerd. Met dit filter wordt voorkomen dat alle modules worden gebouwd wanneer slechts één module wordt bijgewerkt.

Pijplijn voor installatiekopieën naar apparaat

Met de pijplijn voor installatiekopieën naar apparaat worden de Docker-installatiekopieën geïmplementeerd op de doelapparaten, zoals gedefinieerd door een manifestbestand. Als u de pijplijn handmatig activeert, wordt de implementatie gestart.

De pijplijndefinitie specificeert het uitvoeren van deze implementaties in een container. De pijplijnen ondersteunen variabele invoer voor de installatiekopieën waarop containers worden gebaseerd. Eén variabele kan implementaties voor alle pijplijnen beheren.

De installatiekopieën bevatten de code die bepaalt welke patches moeten worden gebouwd, de patches worden gebouwd en gedistribueerd naar de Azure-zijde van het hulpprogramma voor bestandsoverdracht.

Het hulpprogramma voor distributie van installatiekopieën heeft de volgende informatie nodig:

• Welke installatiekopieën moeten worden geïmplementeerd, geleverd door het manifest in de opslagplaats.
• Op welke apparaten moet worden geïmplementeerd, verstrekt door de gebruiker die de pijplijn activeert.
• Welke installatiekopieën zich al op de doelapparaten bevinden, geleverd door een Azure SQL-database.

De pijplijnuitvoer is:

• Patchbundels die naar de Azure-zijde van het hulpprogramma voor bestandsoverdracht worden verzonden, die naar de apparaten worden gedistribueerd.
• SQL-databasevermeldingen die aangeven welke installatiekopieën zijn overgebracht naar elk apparaat.
• SQL-databasevermeldingen voor de nieuwe implementatiesets. Deze vermeldingen bevatten de naam en het e-mailadres van de gebruiker die de implementatie heeft besteld.

Deze pijplijn voert de volgende stappen uit:

1. Bepaalt de benodigde installatiekopieën op basis van het implementatiemanifest.
2. Query's uitvoeren op SQL om te zien welke installatiekopieën zich al op de apparaten bevinden. Als alle installatiekopieën al aanwezig zijn, wordt de pijplijn beëindigd.
3. Bepaalt welke patchbundels moeten worden gemaakt. Het algoritme bepaalt welke startafbeelding de kleinste patchbundel genereert.
   • Invoer: Een .tar-bestand met de nieuwe installatiekopie die moet worden geïmplementeerd en handtekeningbestanden voor de bestaande installatiekopieën op de apparaten.
   • Uitvoer: Een rangschikking van de bestaande installatiekopieën om de kleinste patch te bepalen die moet worden gemaakt.
4. Hiermee maakt u de benodigde patchbundels voor elk apparaat. Bouwt vergelijkbare patches eenmaal en kopieert ze naar alle apparaten die ze nodig hebben.
5. Distribueert de patches naar het opslagaccount van het hulpprogramma voor bestandsoverdracht voor implementatie.
6. Hiermee wordt SQL bijgewerkt om de nieuwe installatiekopieën te markeren voor in transit elk van de doelapparaten.
7. Voegt de informatie over de implementatieset toe aan SQL, met de naam en het e-mailadres van de contactpersoon voor de persoon die de installatiekopieën implementeert.

Manifest-naar-apparaat-pijplijn

De manifest-naar-apparaat-pijplijn pusht het implementatiemanifest naar de juiste IoT Hub-verbinding voor het apparaat dat wordt bijgewerkt. Een gebruiker activeert de pijplijn handmatig en geeft een omgevingsvariabele op voor het IoT Hub-exemplaar dat moet worden gericht.

De pijplijn:

• Bepaalt welke installatiekopieën de implementatie nodig heeft.
• Query's uitvoeren op SQL om ervoor te zorgen dat de benodigde installatiekopieën zich allemaal op de doelapparaten bevinden. Zo niet, dan wordt de pijplijn beëindigd met een failed status.
• Pusht het nieuwe implementatiemanifest naar de juiste IoT Hub.

Snelle oplossing voor bestandsoverdracht

De klant wilde de snelle bestandsoverdrachtoplossing van derden, FileCatalyst, blijven gebruiken om de verbinding tussen Azure en hun IoT-apparaten te bieden. Deze oplossing is een uiteindelijk consistent hulpprogramma voor bestandsoverdracht, wat betekent dat een overdracht lang kan duren, maar uiteindelijk wordt voltooid zonder dat er bestandsgegevens verloren gaan.

De oplossing heeft een Azure Storage-account aan de Azure-zijde van de verbinding gebruikt en de bestaande vm voor bestandsoverdracht van de klant voor elk apparaat dat installatiekopieën ontvangt. De patchbundels worden overgedragen naar een Virtuele Linux-machine waarop IoT Hub wordt uitgevoerd.

Module Afbeeldingsreconstructie

De IoT Edge-module Afbeeldingsreconstructie past de ontvangen patches op de apparaten toe. Elk apparaat fungeert als host voor een eigen lokaal containerregister, met behulp van het opensource-register van Docker. Het reconstructieproces van de installatiekopie wordt uitgevoerd op de host-VM, die hetzelfde is als de vm voor bestandsoverdracht.

De module:

1. Ontvangt de patchbundel in een map die is gekoppeld aan de container.
2. Pak de inhoud van de patch uit om het configuratiebestand te lezen.
3. Haalt de basisinstallatiekopie uit het lokale containerregister op basis van hash.
4. Slaat de basisinstallatiekopieën op als een .tar-bestand .
5. Hiermee past u de patch toe op de basisinstallatiekopieën.
6. Laadt het .tar bestand met de nieuwe installatiekopie naar Docker.
7. Pusht de nieuwe installatiekopieën naar het lokale containerregister, met een configuratiebestand met een beschrijvende naam en tag.
8. Hiermee wordt een bericht verzonden naar IoT Hub.

Als het proces op enig moment mislukt, verzendt de module een foutbericht naar IoT Hub, zodat de gebruiker die de implementatie heeft geactiveerd, op de hoogte kan worden gesteld.

IoT Hub

Verschillende implementatieprocessen maken gebruik van IoT Hub. Naast het ontvangen van statusberichten van de module Afbeeldingsreconstructie, stelt IoT Hub het implementatiemanifest voor het apparaat in. De rest van de pijplijnstroom maakt gebruik van dit manifest.

Azure Functions

Azure Functions bewaakt de berichtenstroom die afkomstig is van IoT Hub en neemt actie in de cloud.

Voor een succesbericht:

• Met de functie wordt de status van de SQL-vermelding voor de installatiekopieën op het apparaat bijgewerkt van in transit naar succeeded.
• Als deze installatiekopieën het laatst binnenkomen in een implementatieset:
  • De functie geeft de gebruiker van het implementatieucces een melding.
  • De functie werkt de manifest-naar-apparaat-pijplijn bij om de nieuwe installatiekopieën te gaan gebruiken.

Voor een foutbericht:

• Met de functie wordt de status van de SQL-vermelding voor de installatiekopieën op het apparaat bijgewerkt van in transit naar failed.
• De functie meldt de gebruiker van de fout bij de overdracht van de installatiekopie.

SQL Database

Een SQL-database houdt exemplaren bij op de doelapparaten en de op Azure gebaseerde implementatieservices tijdens en na de implementatie. Azure Functions en Azure Pipelines maken beide gebruik van een privé NuGet-pakket dat is gemaakt voor interactie met de database.

IN SQL Database worden de volgende gegevens opgeslagen:

• Welke installatiekopieën zich op elk apparaat bevinden.
• Welke installatiekopieën op weg zijn naar elk apparaat.
• Welke installatiekopieën worden geïmplementeerd, behoren tot een set.
• De gebruiker die de implementaties heeft besteld.

Het doel van dit voorbeeld was om ervoor te zorgen dat het systeem de benodigde gegevens heeft gegenereerd voor toekomstige gegevensdashboards. Een query uitvoeren op IoT Hub kan de volgende gegevens bevatten over de manifest-naar-apparaat-pijplijn:

• De status van een implementatie.
• De afbeeldingen op een bepaald apparaat.
• De apparaten met een installatiekopieën.
• Tijdreeksgegevens over geslaagde en mislukte overdrachten.
• Query's van implementaties op basis van de gebruiker.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• Kanio Dimitrov | Principal Software Engineering Lead

Volgende stappen

• Uw eerste IoT Edge-module implementeren op een virtueel Linux-apparaat
• IoT Edge-modules ontwikkelen met Linux-containers

Verwante resources

• Azure IoT-referentiearchitectuur
• Een CI/CD-pijplijn ontwerpen met behulp van Azure DevOps
• Netwerkverbindingen met lage latentie voor de industrie