Naarmate de Internet of Things (IoT) steeds alomtegenwoordig wordt, fungeert het verplaatsen van verwerking naar de rand als een belangrijk model om te voldoen aan behoeften zoals connectiviteit met lage latentie en een hoge bandbreedte. Dit geldt met name voor scenario's met mobiliteit, die doorgaans worden gekenmerkt door onregelmatige connectiviteit met lage bandbreedte. Omdat u doorgaans edge-apparaten inrichten door installatie van softwarecontainers te implementeren, kunnen onderbrekingen van implementatieprocessen leiden tot fouten in mobiele scenario's. Als gevolg hiervan hebt u mogelijk een betrouwbare en flexibele implementatiemogelijkheid nodig voor situaties waarin u een beperkte, onregelmatige of lage bandbreedte hebt.
Dit artikel bevat een overzicht van het proces en de onderdelen die het CSE-team (Commercial Software Engineering) van Microsoft heeft gebruikt om een oplossing te bouwen voor dit scenario. Met deze oplossing konden Docker-containers worden geïmplementeerd op heterogene externe IoT-apparaten via onregelmatige internetverbinding met lage bandbreedte, zoals via satelliet, vanaf het IoT Edge-platform van de klant. Het CSE-team heeft dit bereikt door de grootte van de implementatie op elk apparaat te minimaliseren en door betrouwbare bewaking van deze implementaties in te stellen.
Potentiële gebruikscases
Deze oplossing is geschikt voor elk scenario waarin softwarecontainers worden gebruikt als onderdeel van de oplossing en connectiviteit onregelmatige met lage bandbreedte is. Voorbeelden hiervan zijn:
Mobiele scenario's
Over-the-air-updates voor auto's
Olie en gas en mining
Retail
Overal waar een sterke verbinding niet wordt gegarandeerd
Architectuur
In scenario's met een hoge bandbreedte haalt Azure IoT Edge rechtstreeks vanuit een Docker-register dat via internet toegankelijk is, ofwel een Docker-hub of een privé-account zoals de Azure Container Registry (ACR). Dit is dezelfde functionaliteit als het uitvoeren van de opdracht 'docker <image_name> pull' van een lokale computer.
Wanneer u echter gedwongen bent om te werken met mogelijk onregelmatige netwerktoegang, zoals een satelliet-internetverbinding, wordt de Docker-pullmethode onbetrouwbaar. Met name de voortgang wordt niet in de cache opgeslagen als de internetverbinding wordt verwijderd terwijl Docker de -afbeelding binnen haalt. Wanneer de internetverbinding wordt hervat, moet Docker dus vanaf het begin beginnen met het binnenhalen van de afbeelding.
In de volgende secties wordt een alternatief implementatiemechanisme beschreven dat de limieten compenseert die worden opgelegd door onregelmatige connectiviteit.
In het onderstaande diagram ziet u de architectuur op hoog niveau van deze oplossing.
Ontwerpvereisten
De klant had een oplossing nodig die ondersteuning zou bieden voor onregelmatige cloudconnectiviteit met lage bandbreedte, zodat geïmplementeerde toepassingen lokaal kunnen blijven worden uitgevoerd en lokale medewerkers functionaliteit kunnen gebruiken zonder een retourvertraging in de cloud en offline. Wanneer de oplossing is verbonden met de cloud, moet de cloudverbinding efficiënt worden gebruikt om de verzending van gegevens te prioriteren volgens bedrijfsregels die consistent worden gedefinieerd in producten.
Het CSE-team heeft de volgende gedetailleerde vereisten vastgesteld voor binaire patching van afbeeldingsbestanden:
Afbeeldingsbestanden moeten worden overgedragen via een lage bandbreedte (1Mbit/s), onregelmatige verbinding satellietverbinding.
De gegevens die worden overgedragen, moeten zoveel mogelijk worden geminimaliseerd.
De klant blijft liever een toepassing van derden gebruiken voor het overdragen van bestanden naar apparaten.
De workloads op een apparaat worden uitgevoerd in IoT Edge docker-afbeeldingen.
De grootte van de afbeelding varieert van tientallen MB tot verschillende GB (Windows basisafbeeldingen ~ zijn 5,5 GB).
IoT Edge modules worden geschreven in .NET Core 2.2.
Onderdelen
Azure
Van derden
Open source
Voorbeeld van een toepassing
Een groot logistiek bedrijf wilde het bijhouden van de wereldwijde productverzendingen verbeteren, zelfs via geografische gebieden met onregelmatige cloudconnectiviteit met lage bandbreedte. Op productverzendingen zijn verschillende IoT-apparaten geïnstalleerd voor verzekerings-, veiligheids- of traceringsdoeleinden, afhankelijk van het type goederen dat wordt verzonden. De mogelijkheden van deze apparaten, zoals GPS-trackers, temperatuursensoren en hulpprogramma's voor het vastleggen van andere relevante gegevenspunten, variëren van het ene apparaat naar het andere; en de goederen kunnen worden verzonden met behulp van verschillende transportmethoden (bijvoorbeeld grond, lucht en zee) en naar een groot aantal externe locaties.
De oplossing heeft de betrouwbaarheid en tolerantie van het inrichtingsproces aanzienlijk verhoogd in omgevingen met beperkte connectiviteit. In de onderstaande discussie worden het evaluatieproces voor opties, de details beschreven van de oplossing die het CSE-team voor deze klant heeft ontwikkeld en andere scenario's waarin deze oplossing nuttig kan zijn.
Klantscenario
De klant had problemen bij het bijwerken van hun apparaten via hun onlangs ontwikkelde IoT Edge-platform. CSE is in samenwerking met de klant om de volgende belangrijke problemen aan te pakken:
Hoog bandbreedteverbruik bij het implementeren van bijgewerkte software op apparaten.
Geen gestandaardiseerde geautomatiseerde implementatie op apparaten en geen manier om te weten welke apparaten welke updates hadden.
Beperkte flexibiliteit bij het selecteren van technologie.
Oplossingsevaluatie
Van de vier mogelijke oplossingen die CSE evalueerde, was er meer dan één levensvatbaar en beschikbaar. CSE heeft vastgesteld dat een volledige gegevensoverdracht van Docker-afbeeldingen de ideale oplossing is.
Evaluatiecriteria
CSE heeft rekening gehouden met het volgende:
Mogelijkheid van de oplossing om te voldoen aan vereisten
- Ja, nee
Complexiteit van IoT-apparaten (hoeveel logica er op de apparaten moet worden geïmplementeerd)
- Laag, Gemiddeld, Hoog
Azure-complexiteit (hoeveel logica er moet worden geïmplementeerd in Azure)
- Laag, Gemiddeld, Hoog
Bandbreedte-efficiëntie (verhouding tussen overgedragen gegevens en de totale grootte van de afbeelding) voor het overdragen van een afbeelding wanneer:
Er bestaan geen afbeeldingen op het apparaat.
Er bestaat een afbeelding met dezelfde basisafbeelding op het apparaat.
Er staat een afbeelding van een eerdere versie van een toepassing op het apparaat.
Op het apparaat staat een afbeelding voor de toepassing die is gebouwd op basis van een eerdere versie van de basisafbeelding.
Voor de evaluaties van bandbreedte-efficiëntie gebruikte CSE afbeeldingen om de volgende sets weer te geven.
| Scenario | Beschrijving |
|---|---|
| Nieuwe afbeelding overdragen – basislaag al op apparaat | Een nieuwe afbeelding overdragen terwijl er al een andere afbeelding op het apparaat staat die een basisafbeelding deelt. Dit vertegenwoordigt het voor het eerst implementeren van een nieuwe toepassing, terwijl er een andere toepassing in hetzelfde besturingssysteem en framework bestaat. |
| Bijwerken naar toepassingslaag | Alleen de code voor de afbeelding van een bestaande toepassing wijzigen. Dit is een typische wijziging wanneer een gebruiker een nieuwe functie doorteert. |
| Bijwerken naar basisafbeelding | Het wijzigen van de versie van de basisafbeelding op basis van de toepassing. |
Hier volgt een korte beschrijving van de vier opties en hun afwegingen.
Evaluatieopties die in aanmerking komen voor de oplossing
Docker-lagen overdragen
Een afbeelding is een Union File System-mount van verschillende bestandssysteemverschillen, die alleen-lezen zijn, met een extra beschrijfbare laag voor wijzigingen die zijn aangebracht terwijl de container wordt uitgevoerd. Deze verschillende bestandssystemen worden ook wel lagen genoemd. Dit zijn in feite alleen mappen en bestanden. Lagen worden gestapeld om de basis van het hoofdbestandssysteem van een container te vormen. Omdat lagen alleen-lezen zijn, kunnen verschillende afbeeldingen dezelfde laag delen als ze deze gemeenschappelijk hebben.
In deze oplossing worden lagen tussen afbeeldingen opnieuw gebruikt, waardoor alleen de nieuwe lagen naar het apparaat hoeven te worden overgeplaatst. Dit komt het meest voor bij afbeeldingen die dezelfde basislaag delen (meestal het besturingssysteem, zoals Ubuntu of Alpine) of in afbeeldingen die zijn bijgewerkte versies van bestaande installatie afbeeldingen.
Afwegingen voor deze methode zijn onder andere:
Informatie over de lagen waarop apparaten moeten worden onderhouden in de orchestrator.
Wijzigingen in de basislaag zorgen ervoor dat de hashes van alle volgende lagen worden gewijzigd.
Er zijn consistente laaghashes nodig om te vergelijken.
Dit kan afhankelijkheid van Docker-save en Docker-belasting introduceren.
Aangepaste Docker-client
Deze oplossing is gericht op het wijzigen of verpakken van de Docker-client, zodat het downloaden van de laag wordt hervat wanneer de internetverbinding wordt onderbroken. Standaard wordt een Docker-pull-bestand hervat als de internetverbinding binnen 30 minuten na de onderbreking ~ wordt hersteld. Anders wordt de client afgesloten en gaat alle voortgang van het downloaden verloren.
Hoewel dit een levensvatbare oplossing was, had dit problemen, waaronder:
Alle afbeeldingen op het apparaat moesten worden geregistreerd bij de Docker-daemon om de afbeeldingen op te halen om de bandbreedte efficiënter te maken.
Het opensource-Docker-project moet worden gewijzigd om deze gewijzigde functionaliteit te ondersteunen, wat een risico voor het project betekent als het voorstel is afgewezen door opensource-onderhouders.
Gegevens worden overgedragen via HTTP in plaats van de favoriete snelle oplossing voor bestandsoverdracht van de klant, waarvoor de ontwikkeling van aangepaste logica voor opnieuw proberen vereist is.
Alle lagen moesten opnieuw worden verzonden wanneer een basisafbeelding werd gewijzigd.
Aan de rand
Met deze aanpak wordt de omgeving voor het bouwen van afbeeldingen naar elk apparaat verplaatst. In dit scenario worden de volgende gegevens naar het apparaat verzonden:
De broncode voor de toepassing die wordt gebouwd
Een kopie van alle NuGet-pakketten waar de code afhankelijk van is
De Docker-basisafbeeldingen voor de .NET Core-buildomgeving en -runtime
Metagegevens over hoe de eindafbeelding eruit moet zien
Een Build Agent op het apparaat bouwt vervolgens de -afbeelding en registreert deze bij Device Docker Manager.
Deze oplossing is afgewezen omdat:
Er is nog steeds een manier nodig om grote Docker-afbeeldingen naar het apparaat te verplaatsen. Afbeeldingen voor het bouwen van de .NET-toepassing zijn groter dan de afbeeldingen die moeten worden uitgevoerd.
Deze methode werkt alleen voor .NET Core-toepassingen waarbij het team in bezit is van de broncode en er geen voordelen worden gerealiseerd als u afbeeldingen van derden gebruikt.
Hiermee wordt de noodzaak gemaakt om NuGet-pakketten naar het apparaat te verpakken en bij te houden.
Als een afbeelding niet kan worden gebouwd op het apparaat, moet het team op afstand fouten opsporen in de build-omgeving en de gemaakte afbeelding, wat veel telemetrie is om een mogelijk beperkte internetverbinding door te geven.
Volledige overdracht van delta van afbeelding
Bij deze benadering wordt een Docker-afbeelding als één binair bestand behandeld. Dit wordt bereikt door de opdracht Docker save te gebruiken om de afbeelding te exporteren als een .tar-bestand. Door twee Docker-afbeeldingen te exporteren, kunnen we de binaire delta berekenen die, wanneer deze wordt toegepast, de ene afbeelding in de andere transformeert.
In deze oplossing volgen we de bestaande Docker-afbeeldingen op onze apparaten en bouwen we binaire delta's om een bestaande afbeelding te transformeren naar de nieuwe afbeelding die wordt geïmplementeerd. Op deze manier dragen we alleen de delta over via de internetverbinding met lage bandbreedte.
Evaluatie-conclusie
In de volgende tabel ziet u elk van de bovenstaande oplossingen die zijn gemeten op basis van de evaluatiecriteria uit de eerste sectie.
| Oplossing | Voldoet aan vereisten? | Apparaatcomplexiteit | Azure-complexiteit | Transport | Eerste afbeelding | Basis bestaat op apparaat | Bijwerken naar toepassingslaag | Bijwerken naar basislaag |
|---|---|---|---|---|---|---|---|---|
| Docker-lagen overdragen | Yes | Beperkt | Normaal | FileCatalyst | 100% | 10.5% | 22.4% | 100% |
| Aangepaste Docker-client | Yes | Gemiddeld | Beperkt | HTTP | 100% | 10.5% | 22.4% | 100% |
| Op Edge | No | Hoog | Gemiddeld | FileCatalyst | N.v.t. | N.v.t. | N.v.t. | N.v.t. |
| Volledige Delta-overdracht voor afbeeldingen | Yes | Laag | Hoog | FileCatalyst | 100% | 3.2% | 0,01% | 16.1% |
Op basis van de bovenstaande gegevens heeft CSE de volledige overdrachtsmethode voor de delta van de afbeelding geselecteerd. Voor deze oplossing was enige aangepaste logica vereist om de binaire patches te bouwen, maar dit was de meest efficiënte optie wat betreft hoeveel gegevens er naar apparaten worden verzonden.
Overwegingen
Oplossingsdetails
Ontwikkelaars werken met de broncode voor hun modules in een opslagplaats voor broncode. De basisstructuur van de opslagplaats bestaat als volgt uit mappen die de code voor elke module bevatten:
\- repository root
- modulea
- modulea.csproj
- module.json
- Program.cs
- Dockerfile
\- moduleb
- moduleb.csproj
- module.json
- Program.cs
- Dockerfile
Het aantal broncode-opslagplaatsen is een kwestie van voorkeur; De twee aanbevolen patronen en wat CSE met deze klant heeft gebruikt, waren echter:
Eén opslagplaats voor alle modules die zijn ontwikkeld in alle workstreams.
Eén broncodeopslagplaats voor elke workstream.
Build-pijplijnen voor bronopslagplaats
Er is een Azure DevOps-build-pijplijn voor elke module. Deze pijplijnen zijn verantwoordelijk voor:
Beveiligingsscans van de broncode.
Beveiligingsscans van de basisafbeelding voor het bouwen van de Docker-afbeelding.
Eenheidstests uitvoeren voor de module.
De bron inbouwen in een Docker-afbeelding. De tag image bevat de BUILD BUILDID, zodat de afbeelding altijd kan worden gekoppeld aan de _ broncode waardoor deze is gemaakt.
De afbeelding naar een Azure Container Registry pushen.
Het Delta-bestand maken.
Een handtekeningbestand voor de afbeelding maken en opslaan in een Azure-opslagaccount.
Alle pijplijn-exemplaren kunnen worden gebaseerd op één YAML-pijplijndefinitie. De module kan worden gebruikt voor het gebruik van omgevingsvariabelen, met filters die aan elke pijplijn worden toegevoegd, zodat ze alleen worden geactiveerd wanneer wijzigingen in een bepaalde map worden doorgevoerd. Zo voorkomt u dat alle modules worden gebouwd wanneer slechts één van deze modules wordt bijgewerkt.
Zoals hieronder wordt weergegeven, wordt een algemene Docker-build die gebruikmaakt van de Azure DevOps Build Pipeline gebruikt om modules te maken en te registreren.
Azure Container Registry
Azure Container Registry (ACR) wordt gebruikt om de Docker-afbeeldingen van elke module op te slaan. Er zijn twee mogelijke configuraties voor ACR:
Eén ACR-exemplaar dat alle afbeeldingen op slaat
Een systeem met twee ACR-exemplaren: een systeem slaat de installatie van de installatie op voor ontwikkeling, testen en het debuggen van afbeeldingen; de andere bevat alleen afbeeldingen die zijn geverifieerd door aanvullende tests en zijn gemarkeerd als gereed voor productie.
Manifestopslagplaats
De manifestopslagplaats bevat de implementatiemanifests voor alle workstreams. De sjablonen worden in mappen geplaatst op basis van de werkstroom die ze vertegenwoordigen, zoals hieronder wordt weergegeven. Bij deze interactie zijn de twee workstreams een gedeelde infrastructuur en de containertoepassing (software).
\- repository root
- Workstream1
- deployment.template.json
- Workstream2
- deployment.template.json
Pijplijn van de manifestopslagplaats van afbeelding naar apparaat
Deze pijplijn is verantwoordelijk voor het implementeren van de afbeeldingen op verschillende doelapparaten, zoals gedefinieerd door een manifestbestand. U moet de pijplijn handmatig activeren om een implementatie te starten.
De definitie voor deze pijplijnen geeft aan dat dit implementatiewerk wordt uitgevoerd in een container. Azure DevOps ondersteunt het uitvoeren van build-pijplijnen binnen containers en ondersteunt variabele invoer voor welke afbeelding de container moet worden gebaseerd. Op deze manier kan één variabele de afbeelding bepalen waarop alle pijplijnen zijn gebaseerd.
Deze afbeelding bevat de code die nodig is om te bepalen welke patches moeten worden gebouwd, om die patches te bouwen en om deze te distribueren naar de Azure-zijde van het hulpprogramma voor bestandsoverdracht.
Voor de werking heeft het hulpprogramma voor het distribueren van afbeeldingen de volgende gegevens nodig:
Te gebruiken afbeelding(en) die moeten worden geïmplementeerd (geleverd door het manifest in de opslagplaats)
Apparaten die moeten worden geïmplementeerd in (geleverd door de gebruiker die de pijplijn activeert)
Afbeelding(en) die al op de doelapparaten staan (geleverd door een SQL-database in Azure)
De uitvoer van de pijplijn is:
Patchbundels die naar de Azure-zijde van het hulpprogramma voor bestandsoverdracht worden verzonden om te worden gedistribueerd naar de apparaten.
Een vermelding in SQL database die markeert welke afbeeldingen naar elk van de apparaten zijn overgeplaatst.
Een vermelding in SQL database die een nieuwe implementatieset vertegenwoordigt. Dit omvat informatie over wie de implementatie heeft besteld en een e-mailadres om contact mee op te nemen als er iets misgaat met de implementatie.
Dit proces bestaat uit de volgende stappen:
Bepaal welke afbeeldingen nodig zijn op basis van het distributiemanifest.
Query SQL om te zien welke afbeeldingen al op de doelapparaten staan. Als ze allemaal aanwezig zijn, wordt de pijplijn beëindigd.
Bepaal welke patchbundels moeten worden gemaakt.
Het algoritme dat de beginafbeelding bepaalt, genereert de kleinste patchbundel.
Invoer: .tar-bestand met de nieuwe afbeelding die wordt geïmplementeerd en handtekeningbestanden voor de bestaande afbeeldingen op de apparaten.
Uitvoer: een rangschikking van de bestaande afbeeldingen om de kleinste patch te bepalen die moet worden gemaakt.
Op basis van deze gerangschikte lijst kan worden bepaald welke patches voor elk apparaat moeten worden gemaakt. Vergelijkbare patches worden eenmaal gebouwd en vervolgens gekopieerd naar alle apparaten die ze nodig hebben.
Maak de benodigde patchbundels zoals bepaald in de vorige stap.
Distribueren van de patches naar het opslagaccount van het hulpprogramma voor bestandsoverdracht voor implementatie.
Werk SQL om de nieuwe afbeeldingen te markeren als 'in transit' naar elk van de doelapparaten.
Voeg de informatie over de implementatieset toe SQL het e-mailadres van de contactpersoon voor de persoon die de installatie afbeelding implementeert.
Manifestopslagplaats-manifest-naar-apparaat-pijplijn
Deze pijplijn verzendt het nieuwe implementatiemanifest naar de juiste IoT-hub voor het apparaat dat wordt bijgewerkt. Dit is een handmatig geactiveerde pijplijn. De pijplijn:
Hiermee bepaalt u welke installatie afbeeldingen nodig zijn voor de implementatie.
Query'SQL om ervoor te zorgen dat de benodigde afbeeldingen al op de doelapparaten staan.
- Als dat niet zo is, wordt de pijplijn hier beëindigd met de status Mislukt.
Pusht het nieuwe implementatiemanifest naar de juiste IoT-hub.
De IoT Hub waar de implementatie wordt pusht, is een omgevingsvariabele die wordt geconfigureerd wanneer de pijplijn wordt gemaakt.
Oplossing voor snelle bestandsoverdracht
Deze klant gebruikte al een snelle oplossing voor bestandsoverdracht, FileCatalyst genaamd, die ze het liefst wilden blijven gebruiken. Deze oplossing, ook wel bekend als een 'uiteindelijk consistent' hulpprogramma voor bestandsoverdracht, biedt de verbinding tussen Azure en hun IoT-apparaten. Het concept van uiteindelijk consistent betekent dat het weken kan duren voordat een overdracht van A naar B gaat, maar uiteindelijk wordt voltooid zonder verlies van bestandsgegevens. CSE heeft een Azure Storage-account aan de Azure-zijde van de verbinding en de bestaande virtuele machine voor bestandsoverdracht (VM) van de klant op elk van de apparaten gebruikt om afbeeldingen te ontvangen. Zodra de patchbundels op het apparaat binnenkomen, worden ze door bestaande processen overgedragen naar een Linux-VM. Hier wordt het bestand verplaatst naar de Linux-VM met IoT Hub.
Module voor het herbouwen van afbeeldingen
De module Image IoT Edge is verantwoordelijk voor het toepassen van ontvangen patches op de apparaten. Het werkt als:
De patchbundel ontvangen in een map die aan de container is bevestigd.
De inhoud uitsluiten om het configuratiebestand te lezen.
De basisafbeelding ophalen uit het lokale containerregister (door hash).
De basisafbeelding opslaan als een TAR-bestand.
De patch toepassen op de basisafbeelding.
Laad het nieuwe TAR-bestand met de nieuwe afbeelding naar Docker.
Push de nieuwe afbeelding naar de lokale Container Registry. Een gebruiksvriendelijke naam en tag zijn opgenomen in het configuratiebestand.
Het verzenden van een succesbericht naar IoT Hub.
Als het proces op enig moment mislukt, is deze module verantwoordelijk voor het verzenden van een foutbericht naar IoT Hub zodat de gebruiker die de implementatie heeft besteld, op de hoogte kan worden gesteld. De Azure-functie die de IoT Hub stream verwerkt deze afbeeldingen en onderneemt actie in de cloud zodra deze klaar zijn.
Lokaal containerregister
Elk apparaat host een eigen lokaal containerregister. In deze oplossing heeft CSE het opensource-register gebruikt dat wordt gedistribueerd door Docker. Dit proces wordt uitgevoerd op de host-VM, die ook wordt gebruikt als de bestaande VM voor bestandsoverdracht.
Azure IoT Hub
IoT Hub wordt gebruikt door verschillende andere implementatieprocessen. De IoT-hub ontvangt statusberichten van de afbeeldingsconfigingsmodules. Ook worden de implementatiemanifests voor de verschillende apparatensets en deze manifesten worden vervolgens gebruikt door de rest van de DevOps-stroom.
Azure Functions
Een Azure-functie wordt gebruikt om de berichtenstroom te bewaken die afkomstig is van de IoT-hub. Dit is verantwoordelijk voor het handelen op berichten die zijn verzonden door de modules Afbeeldingen herbouwen op elk apparaat.
In het geval van een geslaagd bericht:
De functie werkt de status van de SQL voor de afbeelding op het apparaat bij van 'in transit' naar 'geslaagd'.
Als dit de laatste afbeelding is die in een implementatieset aankomt:
De functie waarschuwt de gebruiker (met behulp van e-mailmeldingen die zijn geconfigureerd op de SQL server) over het slagen van de implementatie.
De functie activeert ook de manifest-naar-apparaat-pijplijn om de nieuwe afbeeldingen te gaan gebruiken.
In het geval van een foutbericht:
De SQL voor de afbeelding op de apparaatstatus wordt bijgewerkt van 'in transit' naar 'mislukt'.
De gebruiker wordt op de hoogte gesteld (met behulp van e-mailmeldingen die zijn geconfigureerd op de SQL server) van het niet overdragen van de afbeelding.
SQL-databases
Een SQL-database is verantwoordelijk voor het bijhouden van de status van wat er op de doelapparaten en de implementatieservices op basis van Azure plaatsvindt tijdens en na de implementatieprocessen.
Er is een privé-NuGet-pakket gemaakt voor interactie met de database die wordt gebruikt door zowel Azure Functions als Azure Pipelines.
De gegevens die momenteel worden opgeslagen, zijn:
Welke afbeeldingen op welk apparaat zijn geïnstalleerd.
Welke afbeeldingen onderweg zijn naar welk apparaat.
Welke installatie afbeeldingen worden geïmplementeerd, horen bij een set en wie die implementatie heeft besteld.
Deze kan worden gebruikt als gegevensbron voor een dashboard met het volgende:
De status van een implementatie.
De afbeeldingen op een bepaald apparaat.
De apparaten met een afbeelding.
Tijdreeksgegevens over geslaagde en mislukte overdrachten.
Query's van implementaties op basis van de gebruiker.
Het primaire doel tijdens deze klantbetrokkenheid was ervoor te zorgen dat het systeem de gegevens genereerde die in de toekomst nodig zouden zijn. Met de oplossing kunnen toekomstige dashboards query's uitvoeren IoT Hub om statistieken te krijgen over het uitvoeren van IoT Edge-apparaten. Dit biedt inzicht in het succes van de manifest-naar-apparaat-pijplijn.
Implementatieoverzicht
De implementatie van deze oplossing heeft de bandbreedte die wordt verbruikt door updates voor IoT-apparaten aanzienlijk verminderd. Hieronder vindt u een uitsplitsing van de verschillen in de efficiëntie van de overdracht.
Volgende stappen
Zie voor meer informatie over de processen en technologieën die worden gebruikt om deze oplossing te maken: