Effiziente Docker-Imagebereitstellung für Konnektivität mit unregelmäßiger Bandbreite

In diesem Artikel wird eine Lösung für die Bereitstellung von containerisierten IoT Edge-Modulen (Internet der Dinge) über Internetverbindungen mit unregelmäßiger oder geringer Bandbreite beschrieben.

Die Edgeverarbeitung ist ein wesentliches IoT-Muster für die Bereitstellung einer Verbindung mit niedriger Wartezeit und zur Erhaltung von Bandbreite, z. B. in mobilen Szenarien. IoT-Systeme stellen Edgegeräte in der Regel durch das Bereitstellen von Softwarecontainerimages bereit. Unterbrochene Containerbereitstellungen über Internetverbindungen mit unregelmäßiger und geringer Bandbreite können zu Fehlern in mobilen Szenarien führen. IoT-Szenarien, in denen eine eingeschränkte, unregelmäßige oder geringe Bandbreite verfügbar ist, benötigen zuverlässige und resiliente Bereitstellungsfunktion.

In diesem Beispiel wollte ein großes Logistikunternehmen seine weltweite Produktversandverfolgung verbessern. Das Unternehmen lieferte Waren mit verschiedenen Land-, Luft- und Seetransportmethoden an viele Orte, einschließlich Gebieten mit Internetkonnektivität mit unregelmäßiger und geringer Bandbreite. Je nach Art der Waren waren an Produktlieferungen verschiedene IoT-Versicherungs-, -Sicherheits- oder -Nachverfolgungsgeräte installiert, die über unterschiedliche Funktionen verfügen. Zu diesen Geräten gehören GPS-Tracker, Temperatursensoren und Datenerfassungstools.

Das Unternehmen hatte Probleme beim Aktualisieren seiner Geräte über seine kürzlich entwickelte Azure IoT Edge-Plattform. Die wichtigsten Probleme waren:

• Hoher Bandbreitenverbrauch beim Bereitstellen aktualisierter Software auf Geräten.
• Keine geräteübergreifende standardisierte automatisierte Bereitstellung.
• Eingeschränkte Flexibilität bei der Technologieauswahl.

Um diese Probleme zu beheben, hat das Entwicklungsteam eine Lösung mit folgenden Eigenschaften erstellt:

• Minimiert die Größe der Bereitstellung auf jedem Gerät, wodurch die Bandbreite reduziert wird.
• Implementiert eine standardisierte Docker-Containerbereitstellung von der IoT Edge-Plattform in heterogenen IoT-Remotegeräten.
• Ermöglicht eine zuverlässige Bereitstellungsüberwachung.
• Nutzt verschiedene Azure DevOps- und Clouddienste und verwendet die bevorzugten Legacytools des Kunden.

Die Lösung hat die Zuverlässigkeit und Resilienz des Gerätebereitstellungsprozesses in Umgebungen mit eingeschränkter Konnektivität erheblich erhöht. In diesem Artikel werden die Lösungsdetails und der Bewertungsprozess der Lösungsoptionen beschrieben.

Kundenanforderungen

Der Kunde hatte die folgenden Anforderungen:

• Die Lösung muss Cloudkonnektivität mit unregelmäßiger und geringer Bandbreite unterstützen.
• Bereitgestellte Anwendungen müssen weiterhin lokal ausgeführt werden.
• Lokale Mitarbeiter müssen Funktionen offline bzw. ohne Cloud-Roundtripverzögerung verwenden.
• Bei bestehender Verbindung muss die Lösung die Cloudverbindung effizient verwenden.
• Die Lösung muss das Senden von Daten gemäß konsistent definierten Geschäftsregeln produktübergreifend priorisieren.

Ferner wurden auch die folgenden detaillierten Anforderungen gestellt:

• Imagedateien werden über eine Satellitenverbindung mit geringer Bandbreite und nur zeitweiliger Konnektivität übertragen.
• Die Menge der übertragenen Daten sollte minimiert werden.
• Zur Übertragung von Dateien auf Geräte wird die bevorzugte Drittanbieteranwendung des Kunden verwendet.
• Geräteworkloads verwenden Docker-Images in IoT Edge.
• Die Imagegrößen rangieren von Dutzenden MBs bis hin zu mehreren GB.
• IoT Edge-Module werden in .NET Core 2.2 geschrieben.

Mögliche Anwendungsfälle

Diese Lösung eignet sich für IoT-Szenarien, in denen Softwarecontainer Lösungen über unregelmäßige Verbindungen mit geringer Bandbreite liefern. Beispiele:

• Remoteüberwachung in der Öl-, Gas- und Bergbauindustrie
• Over-the-Air-Updates für Autos
• Überall, wo eine stabile Verbindung nicht garantiert ist.

Aufbau

In Szenarien mit hoher Bandbreite pullt Azure IoT Edge Images direkt aus einer über das Internet zugänglichen Docker-Registrierung, entweder aus einem Docker-Hub oder aus einem privaten Hub wie der Azure Container Registry. Diese Funktionalität ist mit der Ausführung des Befehls docker pull <image_name> identisch.

Bei potenziell unregelmäßigem Netzwerkzugriff, wie z. B. einer Internetverbindung über Satellit, ist die Docker-Pullmethode unzuverlässig. Der Fortschritt wird nicht zwischengespeichert, wenn die Internetverbindung unterbrochen wird, während Docker das Image pullt. Wenn die Internetverbindung fortgesetzt wird, muss Docker damit beginnen, das Image wieder ganz von Anfang an neu zu pullen.

Die Lösung verwendet einen alternativen Bereitstellungsmechanismus – binäres Patching von Docker-Imagedateien – um Bandbreite zu reduzieren und unregelmäßige Konnektivität zu kompensieren.

Datenfluss

1. Entwickler interagieren mit dem Quellcode von Edgemodulen in einem Quellcoderepository.
2. Die Containerregistrierung speichert die Docker-Images jedes Moduls.
3. Das Manifestrepository enthält die Bereitstellungsmanifeste für alle Arbeitsstreams.
4. Jedes Modul verfügt über eine Azure Pipelines-Buildpipeline, die einen generischen Docker-Build verwendet, um Module automatisch zu erstellen und zu registrieren.
5. Die Image-zu-Gerät-Pipeline stellt die Docker-Images auf den beabsichtigten Geräten bereit, wie in der Manifestdatei definiert.
6. Die Manifest-zu-Gerät-Pipeline pusht das Bereitstellungsmanifest an den richtigen Azure IoT Hub für das Gerät, das aktualisiert wird.
7. Eine Drittanbieterlösung für schnelle Dateiübertragung überträgt die Dateien aus einem Azure Storage-Konto auf das Gerät.
8. Das IoT Edge-Modul für die Imagerekonstruktion wendet die empfangener Patches auf die Geräte an.
9. IoT Hub erhält Statusmeldungen aus dem Modul für die Imagerekonstruktion und legt das Bereitstellungsmanifest für das Gerät fest. Der restliche Pipelineflow verwendet dieses Bereitstellungsmanifest.
10. Azure Functions überwacht den IoT Hub-Nachrichtenstream, aktualisiert die SQL-Datenbank und benachrichtigt den Benutzer über Erfolg oder Fehler.
11. Azure SQL-Datenbank nachverfolgt Vorkommen auf den Zielgeräten und den Azure-basierten Diensten während und nach der Bereitstellung.

Komponenten

• Azure IoT Edge führt containerisierte Workloads auf Geräten aus, die Konnektivität mit niedriger Latenz bieten und Bandbreite sparen.
• Azure IoT Hub ist ein verwalteter, in der Cloud gehosteter Dienst, der als zentraler Nachrichtenhub zwischen IoT-Anwendungen und den von diesen gesteuerten Geräten fungiert.
• Azure Container Registry ist ein cloudbasierter, privater Registrierungsdienst zum Speichern und Verwalten privater Docker-Containerimages und verwandter Artefakte.
• Azure Pipelines kombiniert Continuous Integration (CI) und Continuous Delivery (CD), um Code automatisch zu testen und zu erstellen und an ein beliebiges Ziel zu liefern.
• Azure Functions ist eine serverlose Computeplattform, die die Ausführung ereignisgesteuerten Codes ermöglicht, ohne eine Infrastruktur bereitstellen oder verwalten zu müssen.
• Azure Storage bietet hoch skalierbaren, sicheren, performanten und kostengünstigen Speicher für alle Arten von Geschäftsdaten, Objekten und Dateien.
• Azure SQL-Datenbank ist ein vollständig verwalteter, relationaler Datenbankdienst für mehrere Modelle, der für die Cloud entwickelt wurde.
• Docker ist eine offene Plattform zum Entwickeln, Versenden und Ausführen containerisierter Anwendungen.

Alternativen

Das Entwicklungsteam hat mehrere Optionen ausgewertet, bevor es sich für die Lösung zum Übertragen des Deltas zwischen vollständigen Images entschieden hat. In den folgenden Abschnitten werden die Bewertungsalternativen und -ergebnisse beschrieben.

Das Team hat die folgenden Bewertungskriterien für jede Option berücksichtigt:

• Ob die Lösung die Anforderungen erfüllt oder nicht.
• Ob eine geringe, mittlere oder hohe Menge an Logik auf den Geräten implementiert werden muss.
• Ob eine geringe, mittlere oder hohe Menge an Logik in Azure implementiert werden muss.
• Bandbreiteneffizienz bzw. Verhältnis übertragener Daten zur Gesamtgröße des Images für die Übertragung eines Containerimages.

Die Bandbreiteneffizienz umfasste Szenarien mit folgenden Eigenschaften:

• Auf dem Gerät sind keine Images vorhanden.
• Auf dem Gerät ist ein Image mit derselben Basis vorhanden.
• Ein Image einer früheren Anwendungsversion ist auf dem Gerät vorhanden.
• Auf dem Gerät ist ein Image für die Anwendung, das auf einer früheren Version des Basisimages basiert, vorhanden.

Das Team hat die folgenden Szenarien verwendet, um die Bandbreiteneffizienz zu bewerten:

Option zum Übertragen von Docker-Ebenen

Ein Docker-Containerimage ist eine UnionFS-Einbindung von schreibgeschützten Dateisystemunterschieden mit einer weiteren schreibbaren Ebene für während der Ausführung des Containers vorgenommene/aufgetretene Änderungen. Die Dateisysteme werden als Ebenen bezeichnet, wobei es sich im Prinzip um Ordner und Dateien handelt. Ebenen werden gestapelt, um die Basis des Stammdateisystems des Containers zu bilden. Da Ebenen schreibgeschützt sind, können verschiedene Images dieselbe Ebene gemeinsam nutzen, wenn sie diese gemeinsam verwenden.

Die Option zum Übertragen von Docker-Ebenen verwendet die Ebenen zwischen Images wieder und überträgt nur neue Ebenen auf das Gerät. Diese Option wäre am nützlichsten für Images, die dieselbe Basisebene verwenden, normalerweise das Betriebssystem, oder zum Aktualisieren von Versionen bestehender Images.

Nachteile diese Methode umfassen:

• Der Orchestrator muss Informationen darüber verwalten, welche Ebenen auf welchen Geräten vorhanden sind.
• Änderungen an der Basisebene bewirken, dass sich die Hashes aller nachfolgenden Ebenen ändern.
• Vergleiche erfordern konsistente Ebenen-Hashs.
• Es könnte Abhängigkeiten von Docker save (speichern) und Docker load (laden) vorhanden sein.

Option zum Ändern des Docker-Clients

Diese Option konzentriert sich auf das Ändern oder Umschließen (Wrapping) des Docker-Clients, weshalb sie den Download von Ebenen nach einer Unterbrechung fortsetzt. Standardmäßig setzt ein Docker pull einen Download fort, wenn die Internetverbindung innerhalb von ca. 30 Minuten nach der Unterbrechung wiederhergestellt wird. Andernfalls wird der Client beendet, und der gesamte Downloadfortschritt geht verloren.

Diese Methode ist funktionsfähig, es traten jedoch Komplikationen auf, einschließlich:

• Alle Images auf dem Gerät müssen bei dem Docker-Daemon registriert sein, der die Images pullt, um die Bandbreiteneffizienz zu maximieren.
• Das Open-Source-Docker-Projekt müsste geändert werden, um diese Funktionalität zu unterstützen, was ein Risiko für die Ablehnung durch Open-Source-Betreuer darstellen würde.
• Die Übertragung von Daten über HTTP anstatt mit der bevorzugten schnellen Dateiübertragungslösung des Kunden würde die Entwicklung einer benutzerdefinierten Wiederholungslogik erfordern.
• Alle Ebenen müssen erneut übertragen werden, wenn sich ein Basisimage ändert.

Option zum Erstellen auf Edgegeräten

Dieser Ansatz verschiebt die Imagebuildumgebung auf die Geräte. Die folgenden Daten werden an das Gerät gesendet:

• Der Quellcode für die zu erstellende Anwendung
• Eine Kopie aller NuGet-Pakete, von denen der Code abhängig ist
• Die Docker-Basisimages für die .NET Core-Buildumgebung und -Runtime
• Metadaten über das endgültige Image

Ein Build-Agent auf dem Gerät erstellt dann das Image und registriert es beim Docker-Geräte-Manager.

Diese Lösung wurde abgelehnt, weil:

• Es müsste dennoch weiterhin eine Möglichkeit gegeben sein, um große Docker-Images auf Geräte zu verschieben. Images zum Erstellen von .NET-Anwendungen sind größer als die App-Images selbst.
• Diese Methode funktioniert nur für Anwendungen, bei denen das Team über den Quellcode verfügt, sodass keine Drittanbieterimages verwendet werden können.
• Die Option erfordert das Packen von NuGet-Paketen und das Nachverfolgen ihres Verschiebevorgangs auf die Geräte.
• Wenn ein Image nicht auf dem Gerät erstellt werden konnte, müsste das Team die Buildumgebung und das erstellte Image remote debuggen. Das Remotedebugging würde eine hohe Auslastung der potenziell eingeschränkten Internetverbindung erfordern.

Option zum Übertragen des Deltas zwischen vollständigen Images

Bei dem gewählten Ansatz wird ein Docker-Image als einzelne Binärdatei behandelt. Der Docker-Befehl save exportiert das Image als TAR-Datei. Die Lösung exportiert das vorhandene und neue Docker-Image und berechnet das binäre Delta, das bei seiner Anwenden das vorhandene Image in das neue transformiert.

Die Lösung nachverfolgt die vorhandenen Docker-Images auf den Geräten und erstellt binäre Delta-Patches, um die vorhandenen Images in die neuen Images zu transformieren. Das System überträgt nur die Delta-Patches über die Internetverbindung mit geringer Bandbreite. Diese Lösung erforderte etwas benutzerdefinierte Logik zum Erstellen der binären Patches, sendet aber die geringste Datenmenge an Geräte.

Auswertung der Ergebnisse

Die folgende Tabelle zeigt jede der oben genannten Lösungen, gemessen an den Auswertungskriterien.

Überlegungen

Diese Überlegungen setzen die Säulen des Azure Well-Architected Framework um, das aus einer Reihe von Leitprinzipien besteht, die die Workloadqualität verbessern. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Effiziente Leistung

Durch diese Lösung wurde die Bandbreite, die von Updates auf IoT-Geräten verbraucht wird, erheblich reduziert. Die folgenden Tabellen zeigen eine Aufschlüsselung der Unterschiede bei der Übertragungseffizienz.

Modul für die Imagerekonstruktion als Quelle:

Vorherige Version als Quelle:

Optimaler Betrieb

Die folgenden Abschnitte bieten eine ausführliche exemplarische Vorgehensweise für die Lösung.

Quellcoderepository

Entwickler interagieren mit dem Quellcode von Edgemodulen in einem Quellcoderepository. Das Repository besteht aus Ordnern, die den Code für jedes Modul enthalten, wie folgt:

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

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

Die empfohlene Anzahl von Quellcoderepositorys ist:

• Ein Repository für alle Module für alle Arbeitsstreams.
• Ein Quellcoderepository für jeden Arbeitsstream.

Container Registry-Instanzen

Die Containerregistrierung speichert die Docker-Images jedes Moduls. Es gibt zwei mögliche Konfigurationen für die Container Registry:

• Eine einzelne Container Registry-Instanz, die alle Images speichert.
• Zwei Container Registry-Instanzen, wovon eine die Entwicklungs-, Test- und Debuggingimages speichert, und die andere enthält nur Images, die als produktionsbereit gekennzeichnet sind.

Manifestrepository

Das Manifestrepository enthält die Bereitstellungsmanifeste für alle Arbeitsstreams. Die Vorlagen befinden sich in Ordnern, basierend auf ihrem jeweiligen Arbeitsstream. In diesem Beispiel handelt es sich bei den beiden Workstreams um eine freigegebene Infrastruktur und die containerisierte Anwendung.

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

Docker-Image-Buildpipeline

Jedes Modul verfügt über eine Azure Pipelines-Buildpipeline. Die Pipeline verwendet einen generischen „Docker build“-Befehl, um Module zu erstellen und zu registrieren. Die Pipeline ist verantwortlich für:

• Sicherheitsüberprüfung des Quellcodes.
• Sicherheitsüberprüfung des Basisimages zum Erstellen des Docker-Images.
• Ausführen von Komponententests für das Modul.
• Erstellen der Quelle in einem Docker-Image. Das Imagetag enthält die BUILD_BUILDID, sodass das Image immer wieder zurück mit dem Quellcode verknüpft werden kann, aus dem es erstellt wurde.
• Pushen des Images in eine Container Registry-Instanz.
• Erstellen der Deltadatei.
• Erstellen einer Signaturdatei für das Image und Speichern der Datei in einem Azure-Speicherkonto.

Alle Pipelineinstanzen basieren auf einer einzigen YAML-Pipelinedefinition. Die Pipeline kann mithilfe von Umgebungsvariablen auf die Module reagieren. Filter lösen jede Pipeline nur aus, wenn Änderungen in einen bestimmten Ordner committet werden. Durch diesen Filter wird das Erstellen aller Module vermieden, wenn nur eins von ihnen aktualisiert wird.

Image-zu-Gerät-Pipeline

Die Image-zu-Gerät-Pipeline stellt die Docker-Images auf den beabsichtigten Geräten bereit, wie in einer Manifestdatei definiert. Das Auslösen der Pipeline startet die Bereitstellung manuell.

Die Pipelinedefinition gibt an, dass diese Bereitstellungen in einem Container ausgeführt werden sollen. Die Pipelines unterstützen Variableneingaben für die Images, auf deren Basis Container erstellt werden sollen. Eine einzelne Variable kann Bereitstellungen für alle Pipelines steuern.

Dieses Image enthält den Code, der bestimmt, welche Patches erstellt werden sollten, der die Patches erstellt und sie auf die Azure-Seite des Dateiübertragungstools verteilt.

Das Imageverteilungstool benötigt die folgenden Informationen:

• Welche Images bereitgestellt werden sollen, angegeben im Manifest im Repository.
• Auf welchen Geräten die Bereitstellung erfolgen soll, angegeben vom Benutzer, der die Pipeline auslöst.
• Welche Images bereits auf den Zielgeräten vorhanden sind, angegeben von einer Azure SQL-Datenbank.

Die Pipelineausgaben sind:

• Patchbündel, die an die Azure-Seite des Dateiübertragungstools gesendet werden, um sie an die Geräte zu verteilen.
• SQL-Datenbankeinträge, die markieren, für welche Images mit der Übertragung an jedes Gerät begonnen wurde.
• SQL-Datenbankeinträge für die neuen Bereitstellungssätze. Diese Einträge umfassen den Namen und die E-Mail-Adresse des Benutzers, der die Bereitstellung bestellt hat.

Diese Pipeline führt folgende Schritte aus:

1. Bestimmen der erforderlichen Images, basierend auf dem Bereitstellungsmanifest.
2. Abfragen von SQL, um festzustellen, welche Images sich bereits auf den Zielgeräten befinden. Wenn alle Images bereits vorhanden sind, wird die Pipeline erfolgreich beendet.
3. Bestimmen, welche Patchbündel erstellt werden sollen. Der Algorithmus bestimmt, welches Startimage das kleinste Patchbündel generiert.
   • Eingaben: Eine TAR-Datei mit dem neuen bereitzustellenden Image sowie Signaturdateien für die vorhandenen Images auf den Geräten.
   • Ausgabe: Eine Rangfolge der vorhandenen Images, um den kleinsten zu erstellenden Patch zu bestimmen.
4. Erstellen der erforderlichen Patchbündel für jedes Gerät. Einmaliges Verteilen ähnlicher Patches und Kopieren der Patches auf alle Geräte, die sie benötigen.
5. Verteilen der Patches an das Speicherkonto des Dateiübertragungstools zur Bereitstellung.
6. Aktualisieren von SQL, um die neuen Images als in transit („wird übertragen“) zu jedem der Zielgeräte zu markieren.
7. Hinzufügen der Informationen zum Bereitstellungssatz zu SQL, zusammen mit den Namen und der Kontakt-E-Mail-Adresse für die Person, die das Image bereitstellt.

Manifest-zu-Gerät-Pipeline

Die Manifest-zu-Gerät-Pipeline pusht das Bereitstellungsmanifest an die geeignete Azure IoT Hub-Verbindung für das Gerät, das aktualisiert wird. Ein Benutzer löst die Pipeline manuell aus, und gibt eine Umgebungsvariable für die IoT Hub-Zielinstanz an.

Die Pipeline:

• Bestimmt, welche Images für die Bereitstellung benötigt werden.
• Fragt SQL ab, um sicherzustellen, dass sich die benötigten Images alle auf den Zielgeräten befinden. Wenn dies nicht der Fall ist, wird die Pipeline mit dem Status failed beendet.
• Pusht das neue Bereitstellungsmanifest an den geeigneten IoT Hub.

Schnelle Dateiübertragungslösung

Der Kunde wollte weiterhin seine schnelle Dateiübertragungslösung eines Drittanbieters namens FileCatalyst verwenden, um die Verbindung zwischen Azure und seinen IoT-Geräten bereitzustellen. Diese Lösung ist ein letztendlich konsistentes Dateiübertragungstool, was bedeutet, dass eine Übertragung lange dauern kann, aber letztendlich abgeschlossen wird, ohne Dateiinformationen zu verlieren.

Die Lösung verwendete ein Azure Storage-Konto auf der Azure-Seite der Verbindung und die vorhandene Dateiübertragungshost-VM des Kunden für jedes Gerät, das Images empfängt. Die Patchbündel werden an eine Linux-VM übertragen, die IoT Hub ausführt.

Modul für die Imagerekonstruktion

Das IoT Edge-Modul für die Imagerekonstruktion wendet die empfangener Patches auf die Geräte an. Jedes Gerät hostet eine eigene lokale Containerregistrierung mithilfe der Open-Source-Registrierung von Docker. Der Prozess der Imagerekonstruktion wird auf der Host-VM ausgeführt, die mit der Dateiübertragungs-VM identisch ist.

Das Modul führt die folgenden Aufgaben aus:

1. Empfangen des Patchbündels in einem Ordner, der in den Container eingebunden ist.
2. Entpacken (ZIP) des Patchinhalts, um die Konfigurationsdatei zu lesen.
3. Pullen des Basisimages aus der lokalen Containerregistrierung per Hash.
4. Speichern des Basisimages als TAR-Datei.
5. Anwenden des Patches auf das Basisimage.
6. Laden der TAR-Datei, die das neue Image enthält, in Docker.
7. Pushen des neuen Images in die lokale Containerregistrierung mit einer Konfigurationsdatei, einschließlich eines Anzeigenamens und Tags.
8. Senden einer Erfolgsmeldung an IoT Hub.

Wenn der Prozess zu einem beliebigen Zeitpunkt fehlschlägt, sendet das Modul eine Fehlermeldung an IoT Hub, damit der Benutzer, der die Bereitstellung ausgelöst hatte, benachrichtigt werden kann.

IoT Hub

Mehrere der Bereitstellungsprozesse verwenden IoT Hub. Neben dem Empfangen von Statusmeldungen von dem Modul für die Imagerekonstruktion legt IoT Hub das Bereitstellungsmanifest für das Gerät fest. Der restliche Pipelineflow verwendet dieses Manifest.

Azure-Funktionen

Azure Functions überwacht den Nachrichtenstrom, der von IoT Hub kommt, und führt Maßnahmen in der Cloud aus.

Bei einer Erfolgsmeldung:

• Die Funktion aktualisiert den Status des SQL-Eintrags für das Image auf dem Gerät von in transit auf succeeded.
• Wenn dies das letzte Image ist, das in einem Bereitstellungssatz eintrifft:
  • Die Funktion benachrichtigt den Benutzer über den Bereitstellungserfolg.
  • Die Funktion aktualisiert die Manifest-zu-Gerät-Pipeline, damit sie mit der Verwendung der neuen Images beginnt.

Bei einer Fehlermeldung:

• Die Funktion aktualisiert den Status des SQL-Eintrags für das Image auf dem Gerät von in transit auf failed.
• Die Funktion benachrichtigt den Benutzer über den Imageübertragungsfehler.

SQL-Datenbank

Eine SQL-Datenbank nachverfolgt Vorkommen auf den Zielgeräten und den Azure-basierten Bereitstellungsdiensten während und nach der Bereitstellung. Azure Functions und Azure Pipelines verwenden beide ein privates NuGet-Paket, das für die Interaktion mit der Datenbank erstellt wurde.

Die SQL-Datenbank speichert die folgenden Daten:

• Welche Images sich auf welchem Gerät befinden.
• Welche Images sich auf dem Weg zum jeweiligen Gerät befinden.
• Welche Images, die bereitgestellt werden, zu einem Satz gehören.
• Den Benutzer, der die Bereitstellungen bestellt hat.

Das Ziel für dieses Beispiel war es, sicherzustellen, dass das System die benötigten Daten für zukünftige Datendashboards generiert. Das Abfragen von IoT Hub kann die folgenden Daten über die Manifest-zu-Gerät-Pipeline bereitstellen:

• Den Zustand einer Bereitstellung.
• Die Images auf einem bestimmten Gerät.
• Die Geräte, die über ein Image verfügen.
• Zeitreihendaten zu erfolgreichen und fehlgeschlagenen Übertragungen.
• Abfragen von Bereitstellungen basierend auf dem Benutzer.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Kanio Dimitrov | Principal Software Engineering Lead

Nächste Schritte

• Bereitstellen Ihres ersten IoT Edge-Moduls auf einem virtuellen Linux-Gerät
• Entwickeln von IoT Edge-Modulen mit Linux-Containern

Zugehörige Ressourcen

• Azure IoT-Referenzarchitektur
• Entwerfen einer CI/CD-Pipeline mithilfe von Azure DevOps
• Netzwerkverbindungen mit geringer Latenz für die Branche