Wydajne wdrażanie obrazów platformy Docker na potrzeby łączności o niskiej przepustowości

W tym artykule opisano rozwiązanie do wdrażania konteneryzowanych modułów brzegowych internetu rzeczy (IoT) w sporadycznej lub niskiej przepustowości połączeń internetowych.

Przetwarzanie brzegowe to kluczowy wzorzec internetu rzeczy (IoT) zapewniający łączność o małych opóźnieniach i oszczędność przepustowości, na przykład w scenariuszach mobilnych. Systemy IoT zwykle aprowizację urządzeń brzegowych przez wdrożenie obrazów kontenerów oprogramowania. Przerwane wdrożenia kontenerów w przypadku sporadycznych połączeń internetowych o niskiej przepustowości mogą powodować błędy w scenariuszach mobilnych. Scenariusze IoT, które mają ograniczone, sporadycznie lub niską przepustowość, wymagają niezawodnych i odpornych możliwości wdrażania.

W tym przykładzie duża firma logistyczna chciała ulepszyć swoje światowe śledzenie przesyłek produktów. Firma dostarczała towary z różnymi metodami transportu naziemnego, lotniczego i morskiego do wielu mieszkańców, w tym z sporadycznymi połączeniami internetowymi o niskiej przepustowości. W zależności od typu towarów przesyłki produktów miały zainstalowane na nich różne urządzenia ubezpieczeniowe, bezpieczne lub śledzące IoT z różnymi możliwościami. Urządzenia obejmowały trackery GPS, czujniki temperatury i narzędzia do przechwytywania danych.

Firma miała problemy z aktualizowaniem urządzeń na niedawno opracowanej platformie Azure IoT Edge. Głównymi punktami bólu były:

• Wysokie zużycie przepustowości podczas wdrażania zaktualizowanego oprogramowania na urządzeniach.
• Nie ma ustandaryzowanego zautomatyzowanego wdrażania między urządzeniami.
• Ograniczona elastyczność wyboru technologii.

Aby rozwiązać te problemy, zespół deweloperów utworzył rozwiązanie, które:

• Minimalizuje rozmiar wdrożenia na każdym urządzeniu, zmniejszając przepustowość.
• Implementuje standardowe wdrożenie kontenera platformy Docker z platformy IoT Edge na heterogeniczne zdalne urządzenia IoT.
• Umożliwia niezawodne monitorowanie wdrożenia.
• Korzysta z różnych usług Azure DevOps i w chmurze oraz korzysta z preferowanych przez klienta narzędzi starszych.

Rozwiązanie znacznie zwiększyło niezawodność i odporność procesu aprowizacji urządzeń w środowiskach z ograniczoną łącznością. W tym artykule opisano szczegóły rozwiązania i proces oceny opcji rozwiązania.

Wymagania klienta

Klient miał następujące wymagania:

• Rozwiązanie musi obsługiwać sporadyczne połączenia w chmurze o niskiej przepustowości.
• Wdrożone aplikacje muszą nadal działać lokalnie.
• Pracownicy lokalni muszą korzystać z funkcji w trybie offline lub bez opóźnienia w rundy chmury.
• Po nawiązaniu połączenia rozwiązanie musi efektywnie korzystać z połączenia w chmurze.
• Rozwiązanie musi określać priorytety wysyłania danych zgodnie ze spójnie zdefiniowanymi regułami biznesowymi w różnych produktach.

Istnieją również następujące szczegółowe wymagania:

• Pliki obrazów są przesyłane przez połączenie satelitarne o niskiej przepustowości, sporadyczne połączenie satelitarne.
• Ilość przesyłanych danych powinna być zminimalizowana.
• Transferowanie plików na urządzenia korzysta z preferowanej przez klienta aplikacji innej firmy.
• Obciążenia urządzeń używają obrazów platformy Docker w usłudze IoT Edge.
• Rozmiary obrazów wahają się od dziesiątek MB do kilku GB.
• Moduły usługi IoT Edge są zapisywane na platformie .NET Core 2.2.

Potencjalne przypadki użycia

To rozwiązanie jest odpowiednie dla scenariuszy IoT, w których kontenery oprogramowania dostarczają rozwiązania za pośrednictwem niskiej przepustowości, sporadycznych połączeń. Oto kilka przykładów:

• Zdalne monitorowanie ropy naftowej, gazu i górnictwa
• Over-the-air automotive updates
• W dowolnym miejscu silne połączenie nie jest gwarantowane

Architektura

W scenariuszach o wysokiej przepustowości usługa Azure IoT Edge ściąga obrazy bezpośrednio z internetowego rejestru platformy Docker, centrum Platformy Docker lub prywatnego centrum, takiego jak Azure Container Registry. Ta funkcja jest taka sama jak uruchomienie docker pull <image_name> polecenia.

W przypadku potencjalnie sporadycznego dostępu do sieci, takiego jak połączenie satelitarne z Internetem, metoda ściągania platformy Docker jest zawodna. Postęp nie jest buforowany, jeśli połączenie internetowe spadnie, gdy platforma Docker ściąga obraz. Po wznowieniu połączenia internetowego platforma Docker musi ponownie ściągnąć obraz od początku.

Rozwiązanie korzysta z alternatywnego mechanizmu wdrażania, binarnego stosowania poprawek plików obrazów platformy Docker, aby zmniejszyć przepustowość i zrekompensować sporadyczne połączenia.

Przepływ danych

1. Deweloperzy korzystają z kodu źródłowego modułu brzegowego w repozytorium kodu źródłowego.
2. Usługa Container Registry przechowuje obrazy platformy Docker każdego modułu.
3. Repozytorium manifestu zawiera manifesty wdrożenia dla wszystkich strumieni roboczych.
4. Każdy moduł ma potok kompilacji usługi Azure Pipelines, który używa ogólnej kompilacji platformy Docker do automatycznego tworzenia i rejestrowania modułów.
5. Potok obraz-urządzenie wdraża obrazy platformy Docker na urządzeniach docelowych zgodnie z definicją w pliku manifestu.
6. Potok manifestu do urządzenia wypycha manifest wdrożenia do właściwej usługi Azure IoT Hub dla aktualizowanego urządzenia.
7. Rozwiązanie do szybkiego transferu plików innej firmy przenosi pliki z konta usługi Azure Storage na urządzenie.
8. Moduł Rekonstrukcja obrazu usługi IoT Edge stosuje odebrane poprawki na urządzeniach.
9. Usługa IoT Hub odbiera komunikaty o stanie z modułu Rekonstrukcja obrazu i ustawia manifest wdrożenia dla urządzenia. W pozostałej części przepływu potoku jest używany ten manifest wdrożenia.
10. Usługa Azure Functions monitoruje strumień komunikatów usługi IoT Hub, aktualizuje bazę danych SQL i powiadamia użytkownika o powodzeniu lub niepowodzeniu.
11. Usługa Azure SQL Database śledzi wystąpienia na urządzeniach docelowych i usługach opartych na platformie Azure podczas wdrażania i po ich wdrożeniu.

Składniki

• Usługa Azure IoT Edge uruchamia konteneryzowane obciążenia na urządzeniach, zapewniając łączność o małych opóźnieniach i oszczędzając przepustowość.
• Usługa Azure IoT Hub to zarządzana usługa hostowana w chmurze, która działa jako centralne centrum komunikatów między aplikacjami IoT i urządzeniami, które kontrolują.
• Azure Container Registry to oparta na chmurze, prywatna usługa rejestru służąca do przechowywania prywatnych obrazów kontenerów platformy Docker i powiązanych artefaktów oraz zarządzania nimi.
• Usługa Azure Pipelines łączy ciągłą integrację i ciągłe dostarczanie (CD), aby automatycznie testować i kompilować kod oraz dostarczać go do dowolnego miejsca docelowego.
• Azure Functions to bezserwerowa platforma obliczeniowa, która umożliwia uruchamianie kodu wyzwalanego przez zdarzenia bez konieczności aprowizowania infrastruktury ani zarządzania nią.
• Usługa Azure Storage oferuje wysoce skalowalny, bezpieczny, wydajny i ekonomiczny magazyn dla wszystkich typów danych biznesowych, obiektów i plików.
• Azure SQL Database to w pełni zarządzana wielomodelowa usługa relacyjnej bazy danych utworzona dla chmury.
• Docker to otwarta platforma do tworzenia, wysyłania i uruchamiania konteneryzowanych aplikacji.

Alternatywy

Zespół programistyczny ocenił kilka opcji przed podjęciem decyzji o pełnym rozwiązaniu do transferu różnicowego obrazu platformy Docker. W poniższych sekcjach opisano alternatywy i wyniki oceny.

Zespół uznał następujące kryteria oceny dla każdej opcji:

• Określa, czy rozwiązanie spełnia wymagania.
• Niezależnie od tego, czy na urządzeniach trzeba zaimplementować niską, średnią lub dużą ilość logiki.
• Niezależnie od tego, czy wymagana jest niska, średnia czy duża ilość logiki do zaimplementowania na platformie Azure.
• Wydajność przepustowości lub stosunek przesyłanych danych do całkowitego rozmiaru obrazu na potrzeby przesyłania obrazu kontenera.

Wydajność przepustowości obejmowała scenariusze, w których:

• Na urządzeniu nie istniały żadne obrazy.
• Na urządzeniu istniał obraz z tą samą bazą.
• Na urządzeniu istniał obraz poprzedniej wersji aplikacji.
• Na urządzeniu istniał obraz aplikacji utworzony na podstawie poprzedniego obrazu podstawowego.

Zespół wykorzystał następujące scenariusze do oceny wydajności przepustowości:

Opcja Przenieś warstwy platformy Docker

Obraz kontenera platformy Docker to instalacja systemu plików UnionFS różnic w systemie plików tylko do odczytu z inną warstwą zapisywalną dla zmian wprowadzonych podczas działania kontenera. Systemy plików są nazywane warstwami, które są zasadniczo folderami i plikami. Warstwy tworzą podstawę głównego systemu plików kontenera. Ponieważ warstwy są tylko do odczytu, różne obrazy mogą współdzielić tę samą warstwę, jeśli mają wspólną warstwę.

Opcja Przenieś warstwy platformy Docker ponownie używa warstw między obrazami i przenosi tylko nowe warstwy na urządzenie. Ta opcja byłaby najbardziej przydatna w przypadku obrazów, które współużytkować tę samą warstwę podstawową, zazwyczaj system operacyjny lub aktualizować wersje istniejących obrazów.

Wady tej metody obejmują:

• Orkiestrator musi przechowywać informacje o tym, które warstwy istnieją na jakich urządzeniach.
• Zmiany warstwy bazowej powodują zmianę skrótów wszystkich kolejnych warstw.
• Porównanie wymaga spójnych skrótów warstw.
• Mogą istnieć zależności dotyczące zapisywania platformy Docker i ładowania platformy Docker.

Modyfikowanie opcji klienta platformy Docker

Ta opcja koncentruje się na modyfikowaniu lub zawijaniu klienta platformy Docker, aby wznowić pobieranie warstwy po przerwie. Domyślnie ściąganie platformy Docker wznawia pobieranie, jeśli połączenie internetowe zostanie przywrócone w ciągu około 30 minut od przerwy. W przeciwnym razie klient kończy działanie i traci cały postęp pobierania.

Ta metoda jest opłacalna, ale miała komplikacje, w tym:

• Wszystkie obrazy na urządzeniu muszą być zarejestrowane w demonie platformy Docker, który ściąga obrazy, aby zmaksymalizować wydajność przepustowości.
• Projekt platformy Docker typu open source musiałby zostać zmodyfikowany w celu obsługi tej funkcji, co stanowi ryzyko odrzucenia przez osoby odpowiedzialne za oprogramowanie typu open source.
• Przesyłanie danych za pośrednictwem protokołu HTTP zamiast preferowanego przez klienta rozwiązania do szybkiego transferu plików wymagałoby opracowania niestandardowej logiki ponawiania prób.
• Wszystkie warstwy muszą zostać ponownie przetransmitowane po zmianie obrazu podstawowego.

Opcja kompiluj na urządzeniu brzegu

To podejście przenosi środowisko kompilacji obrazu do urządzeń. Następujące dane są wysyłane do urządzenia:

• Kod źródłowy tworzonej aplikacji
• Kopia wszystkich pakietów NuGet, od których zależy kod
• Podstawowe obrazy platformy Docker dla środowiska kompilacji i środowiska uruchomieniowego platformy .NET Core
• Metadane dotyczące obrazu końcowego

Agent kompilacji na urządzeniu następnie kompiluje obraz i rejestruje go w menedżerze platformy Docker urządzenia.

To rozwiązanie zostało odrzucone, ponieważ:

• Nadal trzeba będzie przenieść duże obrazy platformy Docker na urządzenia. Obrazy do kompilowania aplikacji platformy .NET są większe niż same obrazy aplikacji.
• Ta metoda działa tylko w przypadku aplikacji, w których zespół ma kod źródłowy, więc nie może używać obrazów innych firm.
• Opcja wymaga pakowania pakietów NuGet i śledzenia ich przenoszenia do urządzeń.
• Jeśli kompilacja obrazu nie powiodła się na urządzeniu, zespół musiałby zdalnie debugować środowisko kompilacji i utworzony obraz. Debugowanie zdalne wymagałoby wysokiego użycia potencjalnie ograniczonego połączenia internetowego.

Opcja transferu różnicowego pełnego obrazu

Wybrane podejście traktuje obraz platformy Docker jako pojedynczy plik binarny. Polecenie platformy Docker save eksportuje obraz jako plik .tar . Rozwiązanie eksportuje istniejące i nowe obrazy platformy Docker oraz oblicza różnicę binarną, która po zastosowaniu przekształca istniejący obraz w nowy.

Rozwiązanie śledzi istniejące obrazy platformy Docker na urządzeniach i tworzy binarne poprawki różnicowe, aby przekształcić istniejące obrazy w nowe obrazy. System przesyła tylko poprawki różnicowe w połączeniu internetowym o niskiej przepustowości. To rozwiązanie wymaga pewnej logiki niestandardowej do skompilowania poprawek binarnych, ale wysłało najmniejszą ilość danych do urządzeń.

Wyniki oceny

W poniższej tabeli pokazano, jak każde z powyższych rozwiązań mierzy się z kryteriami oceny.

Kwestie wymagające rozważenia

Te zagadnienia obejmują implementację filarów platformy Azure Well-Architected Framework— zestawu wytycznych, które zwiększają jakość obciążeń. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Efektywność wydajności

To rozwiązanie znacznie zmniejszyło przepustowość zużywaną przez aktualizacje urządzeń IoT. W poniższych tabelach przedstawiono podział różnic w wydajności transferu.

Rekonstruktor obrazu jako źródło:

Poprzednia wersja jako źródło:

Doskonałość operacyjna

Poniższe sekcje zawierają szczegółowy przewodnik po rozwiązaniu.

Repozytorium kodu źródłowego

Deweloperzy korzystają z kodu źródłowego modułu brzegowego w repozytorium kodu źródłowego. Repozytorium składa się z folderów zawierających kod dla każdego modułu w następujący sposób:

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

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

Zalecana liczba repozytoriów kodu źródłowego to:

• Jedno repozytorium dla wszystkich modułów we wszystkich strumieniach roboczych.
• Jedno repozytorium kodu źródłowego dla każdego strumienia roboczego.

Wystąpienia usługi Container Registry

Usługa Container Registry przechowuje obrazy platformy Docker każdego modułu. Istnieją dwie możliwe konfiguracje usługi Container Registry:

• Pojedyncze wystąpienie usługi Container Registry, które przechowuje wszystkie obrazy.
• Dwa wystąpienia usługi Container Registry— jeden do przechowywania obrazów programowania, testowania i debugowania, a drugi zawierający tylko obrazy oznaczone jako gotowe do produkcji.

Repozytorium manifestu

Repozytorium manifestu zawiera manifesty wdrożenia dla wszystkich strumieni roboczych. Szablony znajdują się w folderach na podstawie ich strumienia roboczego. W tym przykładzie dwa strumienie robocze są współdzieloną infrastrukturą i konteneryzowaną aplikacją.

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

Potok kompilacji obrazu platformy Docker

Każdy moduł ma potok kompilacji usługi Azure Pipelines. Potok używa ogólnej kompilacji platformy Docker do tworzenia i rejestrowania modułów. Potok jest odpowiedzialny za:

• Skanowanie zabezpieczeń kodu źródłowego.
• Skanowanie zabezpieczeń obrazu podstawowego w celu utworzenia obrazu platformy Docker.
• Uruchamianie testów jednostkowych dla modułu.
• Tworzenie źródła w obrazie platformy Docker. Tag obrazu zawiera BUILD_BUILDIDelement , więc obraz może być zawsze połączony z kodem źródłowym, który go uczynił.
• Wypychanie obrazu do wystąpienia usługi Container Registry.
• Tworzenie pliku różnicowego.
• Tworzenie pliku podpisu dla obrazu i zapisywanie pliku na koncie usługi Azure Storage.

Wszystkie wystąpienia potoku są oparte na jednej definicji potoku YAML. Potok może działać na modułach przy użyciu zmiennych środowiskowych. Filtry wyzwalają każdy potok tylko wtedy, gdy zmiany są zatwierdzane w określonym folderze. Ten filtr pozwala uniknąć kompilowania wszystkich modułów po zaktualizowaniu tylko jednego modułu.

Potok obraz-urządzenie

Potok obraz-urządzenie wdraża obrazy platformy Docker na urządzeniach docelowych zgodnie z definicją w pliku manifestu. Wyzwalanie potoku ręcznie uruchamia wdrożenie.

Definicja potoku określa uruchamianie tych wdrożeń w kontenerze. Potoki obsługują zmienne dane wejściowe obrazów w celu oparcia kontenerów. Pojedyncza zmienna może kontrolować wdrożenia dla wszystkich potoków.

Obraz zawiera kod, który określa poprawki do skompilowania, skompiluje poprawki i dystrybuuje je po stronie platformy Azure narzędzia do transferu plików.

Narzędzie do dystrybucji obrazów wymaga następujących informacji:

• Które obrazy do wdrożenia są dostarczane przez manifest w repozytorium.
• Do których urządzeń należy wdrożyć, udostępnianych przez użytkownika, który wyzwala potok.
• Które obrazy znajdują się już na urządzeniach docelowych udostępnianych przez bazę danych Azure SQL Database.

Dane wyjściowe potoku to:

• Pakiety poprawek wysyłane po stronie platformy Azure narzędzia do transferu plików, które mają być dystrybuowane do urządzeń.
• Wpisy bazy danych SQL oznaczające, które obrazy zaczęły przesyłać do każdego urządzenia.
• Wpisy bazy danych SQL dla nowych zestawów wdrażania. Te wpisy obejmują nazwę i adres e-mail użytkownika, który zamówił wdrożenie.

Ten potok wykonuje następujące czynności:

1. Określa potrzebne obrazy na podstawie manifestu wdrożenia.
2. Wysyła zapytania SQL, aby zobaczyć, które obrazy znajdują się już na urządzeniach. Jeśli wszystkie obrazy są już obecne, potok zakończy się pomyślnie.
3. Określa pakiety poprawek do utworzenia. Algorytm określa, który obraz początkowy generuje najmniejszy pakiet poprawek.
   • Dane wejściowe: plik .tar zawierający nowy obraz do wdrożenia i pliki podpisu dla istniejących obrazów na urządzeniach.
   • Dane wyjściowe: ranga istniejących obrazów w celu określenia najmniejszej poprawki do utworzenia.
4. Tworzy wymagane pakiety poprawek dla każdego urządzenia. Tworzy podobne poprawki raz i kopiuje je do wszystkich urządzeń, które ich potrzebują.
5. Dystrybuuje poprawki do konta magazynu narzędzi transferu plików na potrzeby wdrożenia.
6. Aktualizuje język SQL, aby oznaczyć nowe obrazy jako in transit każde z urządzeń docelowych.
7. Dodaje informacje o zestawie wdrożeń do programu SQL z nazwą i kontaktowym adresem e-mail dla osoby wdrażającej obraz.

Potok manifestu do urządzenia

Potok manifestu do urządzenia wypycha manifest wdrożenia do odpowiedniego połączenia usługi IoT Hub dla aktualizowanego urządzenia. Użytkownik wyzwala potok ręcznie i określa zmienną środowiskową wystąpienia usługi IoT Hub, która ma być docelowa.

Potok:

• Określa, które obrazy wymagają wdrożenia.
• Wysyła zapytania SQL, aby upewnić się, że potrzebne obrazy znajdują się na docelowych urządzeniach. Jeśli nie, potok kończy się stanem failed .
• Wypycha nowy manifest wdrożenia do odpowiedniego centrum IoT Hub.

Szybkie rozwiązanie do transferu plików

Klient chciał nadal korzystać z rozwiązania do szybkiego transferu plików innej firmy o nazwie FileCatalyst, aby zapewnić połączenie między platformą Azure i ich urządzeniami IoT. To rozwiązanie jest ostatecznie spójnym narzędziem do transferu plików, co oznacza, że transfer może zająć dużo czasu, ale ostatecznie zakończy się bez utraty informacji o pliku.

Rozwiązanie używało konta usługi Azure Storage po stronie połączenia, a istniejąca maszyna wirtualna hosta transferu plików klienta dla każdego urządzenia odbierającego obrazy. Pakiety poprawek są przenoszone do maszyny wirtualnej z systemem Linux z uruchomioną usługą IoT Hub.

Moduł Rekonstrukcja obrazu

Moduł Rekonstrukcja obrazu usługi IoT Edge stosuje odebrane poprawki na urządzeniach. Każde urządzenie hostuje własny lokalny rejestr kontenerów przy użyciu rejestru open source platformy Docker. Proces rekonstrukcji obrazu jest uruchamiany na maszynie wirtualnej hosta, która jest taka sama jak maszyna wirtualna transferu plików.

Moduł:

1. Odbiera pakiet poprawek w folderze zainstalowanym w kontenerze.
2. Rozpakowuje zawartość poprawki, aby odczytać plik konfiguracji.
3. Ściąga obraz podstawowy z lokalnego rejestru kontenerów według skrótu.
4. Zapisuje obraz podstawowy jako plik .tar .
5. Stosuje poprawkę do obrazu podstawowego.
6. Ładuje plik .tar zawierający nowy obraz do platformy Docker.
7. Wypycha nowy obraz do lokalnego rejestru kontenerów z plikiem konfiguracji zawierającym przyjazną nazwę i tag.
8. Wysyła komunikat o powodzeniu do usługi IoT Hub.

Jeśli proces zakończy się niepowodzeniem w dowolnym momencie, moduł wyśle komunikat o błędzie do usługi IoT Hub, aby użytkownik, który wyzwolił wdrożenie, mógł zostać powiadomiony.

Usługa IoT Hub

Kilka procesów wdrażania korzysta z usługi IoT Hub. Oprócz odbierania komunikatów o stanie z modułu Rekonstrukcja obrazu usługa IoT Hub ustawia manifest wdrożenia dla urządzenia. W pozostałej części przepływu potoku jest używany ten manifest.

Azure Functions

Usługa Azure Functions monitoruje strumień komunikatów pochodzący z usługi IoT Hub i podejmuje działania w chmurze.

Aby uzyskać komunikat o powodzeniu:

• Funkcja aktualizuje stan wpisu SQL dla obrazu na urządzeniu z in transit do succeeded.
• Jeśli ten obraz jest ostatnim, który ma pojawić się w zestawie wdrożeniowym:
  • Funkcja powiadamia użytkownika o powodzeniu wdrożenia.
  • Funkcja aktualizuje potok manifestu do urządzenia, aby rozpocząć korzystanie z nowych obrazów.

W przypadku komunikatu o błędzie:

• Funkcja aktualizuje stan wpisu SQL dla obrazu na urządzeniu z in transit do failed.
• Funkcja powiadamia użytkownika o niepowodzeniu transferu obrazów.

SQL Database

Baza danych SQL śledzi wystąpienia na urządzeniach docelowych i usługach wdrażania opartych na platformie Azure podczas wdrażania i po ich wdrożeniu. Usługi Azure Functions i Azure Pipelines używają zarówno prywatnego pakietu NuGet utworzonego do interakcji z bazą danych.

Usługa SQL Database przechowuje następujące dane:

• Które obrazy znajdują się na każdym urządzeniu.
• Które obrazy są na drodze do każdego urządzenia.
• Obrazy, które są wdrażane, należą do zestawu.
• Użytkownik, który zamówił wdrożenia.

Celem tego przykładu było upewnienie się, że system wygenerował potrzebne dane dla przyszłych pulpitów nawigacyjnych danych. Wykonywanie zapytań dotyczących usługi IoT Hub może dostarczyć następujące dane dotyczące potoku manifest-urządzenie:

• Stan wdrożenia.
• Obrazy na danym urządzeniu.
• Urządzenia, które mają obraz.
• Dane szeregów czasowych dotyczące pomyślnych i zakończonych niepowodzeniem transferów.
• Zapytania dotyczące wdrożeń na podstawie użytkownika.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• Kanio Dimitrov | Główny lider inżynierii oprogramowania

Następne kroki

• Wdrażanie pierwszego modułu usługi IoT Edge na wirtualnym urządzeniu z systemem Linux
• Opracowywanie modułów usługi IoT Edge za pomocą kontenerów systemu Linux

Powiązane zasoby

• Architektura referencyjna usługi Azure IoT
• Projektowanie potoku ciągłej integracji/ciągłego wdrażania przy użyciu usługi Azure DevOps
• Połączenia sieciowe o małych opóźnieniach dla branży