Hatékony Docker-rendszerkép-üzembe helyezés alacsony sávszélességű kapcsolatokhoz

Ez a cikk a tárolóalapú internetkapcsolat (IoT) peremmoduljainak időszakos vagy alacsony sávszélességű internetkapcsolatokon történő üzembe helyezésére szolgáló megoldást ismerteti.

Az edge-feldolgozás kulcsfontosságú internetkapcsolati (IoT-) minta, amely alacsony késésű kapcsolatot biztosít, és megőrzi a sávszélességet, például mobil forgatókönyvekben. Az IoT-rendszerek általában szoftvertároló lemezképek üzembe helyezésével építenek ki peremeszközöket. A tárolótelepítések időszakos, alacsony sávszélességű internetkapcsolatok miatt megszakadt telepítések meghibásodást okozhatnak a mobil forgatókönyvekben. A korlátozott, időszakos vagy alacsony sávszélességű IoT-forgatókönyvek megbízható és rugalmas üzembehelyezési képességeket igényelnek.

Ebben a példában egy nagy logisztikai vállalat javítani akarta világszerte a termékszállítmányok nyomon követését. A vállalat különböző földi, légi és tengeri szállítási módszerekkel szállított árut számos területre, beleértve az időszakos, alacsony sávszélességű internetkapcsolattal rendelkező területeket is. Az áruk típusától függően a termékszállítmányok különböző IoT-biztosítási, biztonsági vagy nyomkövető eszközöket telepítettek rájuk, különböző képességekkel. Az eszközök között gps-nyomkövetők, hőmérséklet-érzékelők és adatrögzítési eszközök is találhatók.

A vállalatnak problémái vannak az eszközök nemrégiben kifejlesztett Azure IoT Edge-platformon való frissítésével. A főbb fájdalompontok a következőek voltak:

• Nagy sávszélesség-használat a frissített szoftverek eszközökre való telepítésekor.
• Nincs szabványosított automatizált üzembe helyezés az eszközökön.
• A technológia kiválasztásának korlátozott rugalmassága.

A problémák megoldásához a fejlesztői csapat olyan megoldást hozott létre, amely:

• Minimálisra csökkenti az üzembe helyezés méretét az egyes eszközökön, csökkentve a sávszélességet.
• Szabványos Docker-tároló üzembe helyezését valósítja meg az IoT Edge platformról heterogén távoli IoT-eszközökre.
• Lehetővé teszi a megbízható üzembe helyezés monitorozását.
• Kihasználja a különböző Azure DevOps- és felhőszolgáltatásokat, és az ügyfél által előnyben részesített örökölt eszközöket használja.

A megoldás jelentősen megnövelte az eszközkiépítési folyamat megbízhatóságát és rugalmasságát korlátozott kapcsolati környezetekben. Ez a cikk a megoldás részleteit és a megoldásbeállítások kiértékelési folyamatát ismerteti.

Ügyfélkövetelmények

Az ügyfélnek a következő követelményei voltak:

• A megoldásnak támogatnia kell az időszakos, alacsony sávszélességű felhőkapcsolatot.
• Az üzembe helyezett alkalmazásoknak továbbra is helyileg kell futniuk.
• A helyi személyzetnek offline vagy felhőbeli oda-vissza utazás késleltetése nélkül kell használnia a funkciókat.
• Csatlakozáskor a megoldásnak hatékonyan kell használnia a felhőkapcsolatot.
• A megoldásnak rangsorolnia kell az adatok küldését a termékek között konzisztensen meghatározott üzleti szabályok szerint.

A következő részletes követelmények is teljesültek:

• A rendszer a képfájlokat alacsony sávszélességű, időszakosan csatlakoztatható műholdas kapcsolaton keresztül továbbítja.
• Az átvitt adatok mennyiségét minimálisra kell csökkenteni.
• A fájlok eszközökre történő átvitele az ügyfél által előnyben részesített külső alkalmazást használja.
• Az eszköz számítási feladatai Docker-rendszerképeket használnak az IoT Edge-ben.
• A képméretek több tíz MB-tól több GB-ig terjednek.
• Az IoT Edge-modulok a .NET Core 2.2-ben vannak megírva.

Lehetséges használati esetek

Ez a megoldás olyan IoT-forgatókönyvekhez használható, ahol a szoftvertárolók alacsony sávszélességű, időszakos kapcsolatokon keresztül biztosítanak megoldásokat. Ide sorolhatóak például a kövekezők:

• Távoli olaj-, gáz- és bányászati monitorozás
• Levegőn áti autóipari frissítések
• Bárhol, ahol az erős kapcsolat nem garantált

Architektúra

Nagy sávszélességű forgatókönyvek esetén az Azure IoT Edge közvetlenül egy internetről elérhető Docker-beállításjegyzékből, egy Docker-központból vagy egy privát központból, például az Azure Container Registryből kér le képeket. Ez a funkció megegyezik a parancs futtatásával docker pull <image_name> .

A Docker lekéréses módszere nem megbízható, ha esetleg időszakos hálózati hozzáféréssel, például műholdas internetkapcsolattal rendelkezik. A rendszer nem gyorsítótárazza a folyamatot, ha az internetkapcsolat megszakad, miközben a Docker lekérte a képet. Amikor az internetkapcsolat folytatódik, a Dockernek az elejétől újra meg kell kezdenie a rendszerkép lekérését.

A megoldás egy alternatív üzembehelyezési mechanizmust, a Docker-rendszerképfájlok bináris javítását használja a sávszélesség csökkentésére és az időszakos kapcsolatok kompenzálására.

Adatfolyam

1. A fejlesztők egy forráskódtár peremmodul-forráskódját használják.
2. A Tárolóregisztrációs adatbázis tárolja az egyes modulok Docker-rendszerképeit.
3. A jegyzékadattár tartalmazza az összes workstream üzembehelyezési jegyzékfájlját.
4. Minden modul rendelkezik egy Azure Pipelines-buildelési folyamatsal, amely egy általános Docker-buildet használ a modulok automatikus létrehozásához és regisztrálásához.
5. A rendszerkép-eszköz folyamat telepíti a Docker-lemezképeket a céleszközökre a jegyzékfájl által meghatározott módon.
6. A jegyzék-eszköz folyamat leküldi az üzembehelyezési jegyzékfájlt a megfelelő Azure IoT Hubra a frissítendő eszközhöz.
7. Egy külső gyors fájlátviteli megoldás átviszi a fájlokat egy Azure Storage-fiókból az eszközre.
8. A Képrekonstrukció IoT Edge modul a kapott javításokat alkalmazza az eszközökön.
9. Az IoT Hub állapotüzeneteket fogad az Image Reconstruction modultól, és beállítja az eszköz üzembehelyezési jegyzékét. A folyamat többi része ezt az üzembehelyezési jegyzéket használja.
10. Az Azure Functions figyeli az IoT Hub üzenetstreamet, frissíti az SQL-adatbázist, és értesíti a felhasználót a sikeres vagy sikertelen működésről.
11. Az Azure SQL Database nyomon követi a céleszközök és az Azure-alapú szolgáltatások előfordulásait az üzembe helyezés során és után.

Összetevők

• Az Azure IoT Edge tárolóalapú számítási feladatokat futtat az eszközökön, így alacsony késésű kapcsolatot és sávszélességet biztosít.
• Az Azure IoT Hub egy felügyelt, felhőalapú szolgáltatás, amely központi üzenetközpontként működik az IoT-alkalmazások és az általuk felügyelt eszközök között.
• Az Azure Container Registry egy felhőalapú, privát beállításjegyzék-szolgáltatás, amely privát Docker-tárolólemezképeket és kapcsolódó összetevőket tárol és kezel.
• Az Azure Pipelines a folyamatos integrációt (CI) és a folyamatos kézbesítést (CD) kombinálva automatikusan teszteli és fejleszti a kódot, és bármilyen célhoz eljuttatja.
• Az Azure Functions egy kiszolgáló nélküli számítási platform, amely lehetővé teszi az eseményvezérelt kód futtatását infrastruktúra kiépítése és kezelése nélkül.
• Az Azure Storage rendkívül skálázható, biztonságos, hatékony és költséghatékony tárolást biztosít minden típusú üzleti adathoz, objektumhoz és fájlhoz.
• Az Azure SQL Database egy teljes mértékben felügyelt, többmodelles relációs adatbázis-szolgáltatás, amely a felhőhöz készült.
• A Docker egy nyílt platform tárolóalapú alkalmazások fejlesztésére, szállítására és futtatására.

Alternatívák

A fejlesztői csapat több lehetőséget is kiértékelt, mielőtt a docker-rendszerképek teljes deltaátviteli megoldásáról döntött. A következő szakaszok a kiértékelési alternatívákat és az eredményeket ismertetik.

A csapat az alábbi értékelési kritériumokat vette figyelembe az egyes lehetőségekhez:

• Azt jelzi, hogy a megoldás megfelel-e a követelményeknek.
• Azt, hogy alacsony, közepes vagy nagy mennyiségű logikát kell-e implementálni az eszközökön.
• Azt, hogy alacsony, közepes vagy nagy mennyiségű logikát kell-e implementálni az Azure-ban.
• A sávszélesség hatékonysága vagy az átvitt adatok aránya egy lemezkép teljes méretéhez egy tárolólemezkép átviteléhez.

A sávszélesség hatékonysága olyan forgatókönyveket tartalmazott, ahol:

• Az eszközön nem voltak képek.
• Ugyanazzal a bázissal rendelkező kép volt az eszközön.
• Az eszközön egy korábbi alkalmazásverzió képe volt.
• Az eszközön egy korábbi alaprendszerképre épülő alkalmazás képe volt.

A csapat a következő forgatókönyveket használta a sávszélesség hatékonyságának kiértékeléséhez:

Docker-rétegek átvitele beállítás

A Docker-tárolólemezképek az írásvédett fájlrendszerbeli különbségek UnionFS-csatlakoztatását alkotják, és egy másik írható réteggel rendelkeznek a tároló futása közben végrehajtott módosításokhoz. A fájlrendszereket rétegeknek nevezzük, amelyek alapvetően mappák és fájlok. A rétegverem a tároló gyökér fájlrendszerének alapját képezi. Mivel a rétegek írásvédettek, a különböző képek ugyanazt a réteget használhatják, ha közös a réteg.

Az átviteli Docker-rétegek beállítás újra felhasználja a rétegeket a képek között, és csak az új rétegeket továbbítja az eszközre. Ez a beállítás az azonos alapréteggel rendelkező képek, általában az operációs rendszer vagy a meglévő rendszerképek verzióinak frissítéséhez lenne a legléremesebb.

Ennek a módszernek a hátrányai a következők:

• A vezénylőnek meg kell őriznie az információkat arról, hogy mely rétegek mely eszközökön léteznek.
• Az alapréteg változásai miatt az összes további réteg kivonata megváltozik.
• Az összehasonlításhoz konzisztens rétegkivonatok szükségesek.
• Lehetnek függőségek a Docker mentéséhez és a Docker betöltéséhez.

Docker-ügyfél beállításainak módosítása

Ez a beállítás a Docker-ügyfél módosítására vagy burkolására összpontosít, így megszakítás után újraindul a rétegletöltés. Alapértelmezés szerint a Docker-lekérés folytatja a letöltést, ha az internetkapcsolat a megszakítástól számított 30 percen belül helyreáll. Ellenkező esetben az ügyfél kilép, és elveszíti az összes letöltési folyamatot.

Ez a módszer életképes, de komplikációk voltak, például:

• Az eszközön lévő összes képet regisztrálni kell a képeket lekérő Docker-démonnal a sávszélesség hatékonyságának maximalizálása érdekében.
• A nyílt forráskódú Docker-projektet módosítani kell ennek a funkciónak a támogatásához, ami a nyílt forráskódú karbantartók általi elutasítás kockázatát jelentheti.
• Az adatok HTTP-en keresztüli átvitele az ügyfél által előnyben részesített gyors fájlátviteli megoldás helyett egyéni újrapróbálkozási logikát igényelne.
• Az alaprendszerkép módosításakor minden réteget újra kell adni.

Buildelés peremeszközre lehetőség

Ezzel a módszerrel áthelyezi a rendszerkép-összeállítási környezetet az eszközökre. A rendszer a következő adatokat küldi el az eszköznek:

• A létrehozandó alkalmazás forráskódja
• Az összes NuGet-csomag másolata, amelytől a kód függ
• A Docker alaprendszerképe a .NET Core buildkörnyezetéhez és futtatókörnyezetéhez
• Metaadatok a végfelhasználói rendszerképről

Egy buildügynök az eszközön, majd létrehozza a rendszerképet, és regisztrálja azt az eszköz Docker Managerében.

Ezt a megoldást a rendszer a következő miatt utasította el:

• A nagyméretű Docker-rendszerképeket továbbra is át kell helyezni az eszközökre. A .NET-alkalmazások létrehozásához használható képek nagyobbak, mint maguk az alkalmazásképek.
• Ez a módszer csak olyan alkalmazások esetében működik, ahol a csapat rendelkezik a forráskóddal, így nem használhat külső lemezképeket.
• A beállításhoz NuGet-csomagok csomagolására és az eszközökre való mozgás nyomon követésére van szükség.
• Ha egy rendszerkép nem tudott az eszközre építeni, a csapatnak távolról kell hibakeresést végeznie a buildkörnyezetben és a létrehozott lemezképben. A távoli hibakereséshez a potenciálisan korlátozott internetkapcsolat magas kihasználtsága szükséges.

Teljes képátviteli lehetőség

A választott módszer egyetlen bináris fájlként kezeli a Docker-rendszerképeket. A Docker-parancs save exportálja a képet .tar fájlként. A megoldás exportálja a meglévő és az új Docker-rendszerképeket, és kiszámítja azt a bináris különbözetet, amely alkalmazásakor a meglévő rendszerképet átalakítja az újba.

A megoldás nyomon követi a meglévő Docker-lemezképeket az eszközökön, és bináris delta-javításokat hoz létre a meglévő képek új lemezképekké alakításához. A rendszer csak a különbözeti javításokat továbbítja az alacsony sávszélességű internetkapcsolaton keresztül. Ez a megoldás egyéni logikát igényelt a bináris javítások létrehozásához, de a legkevesebb adatot küldte el az eszközöknek.

A kiértékelés eredménye

Az alábbi táblázat bemutatja, hogy a fenti megoldások hogyan mértek az értékelési kritériumok alapján.

Megfontolások

Ezek a szempontok az Azure Well-Architected Framework alappilléreit valósítják meg, amelyek a számítási feladatok minőségét javító vezérelveket ismertetik. További információ: Microsoft Azure Well-Architected Framework.

Teljesítmény hatékonysága

Ez a megoldás jelentősen csökkentette az IoT-eszközök frissítései által felhasznált sávszélességet. Az alábbi táblázatok az átviteli hatékonyság különbségeinek lebontását mutatják be.

Képrekonstruktor forrásként:

Előző verzió forrásként:

Működés eredményessége

A következő szakaszok részletesen ismertetik a megoldást.

Forráskódtár

A fejlesztők egy forráskódtár peremmodul-forráskódját használják. Az adattár az egyes modulok kódját tartalmazó mappákból áll, az alábbiak szerint:

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

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

A forráskódtárak javasolt száma:

• Egy adattár az összes modulhoz az összes workstreamben.
• Minden munkafolyamathoz egy forráskódtár.

Tárolóregisztrációs adatbázis példányai

A Tárolóregisztrációs adatbázis tárolja az egyes modulok Docker-rendszerképeit. A Tárolóregisztrációs adatbázisnak két lehetséges konfigurációja van:

• Egyetlen Container Registry-példány, amely az összes lemezképet tárolja.
• Két Container Registry-példány, az egyik a fejlesztési, tesztelési és hibakeresési rendszerképek tárolására szolgál, a másik pedig csak az éles üzemre készként megjelölt képeket tartalmazza.

Jegyzéktár

A jegyzékadattár tartalmazza az összes workstream üzembehelyezési jegyzékfájlját. A sablonok a munkastreamjük alapján mappákban találhatók. Ebben a példában a két munkafolyamat megosztott infrastruktúra és a tárolóalapú alkalmazás.

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

Docker-rendszerképek buildelési folyamata

Minden modulhoz tartozik egy Azure Pipelines-buildfolyamat. A folyamat egy általános Docker-buildet használ a modulok létrehozásához és regisztrálásához. A folyamat felelős a következőért:

• A forráskód biztonsági vizsgálata.
• A Docker-rendszerkép létrehozásához használt alaprendszerkép biztonsági vizsgálata.
• Egységtesztek futtatása a modulhoz.
• A forrás létrehozása Docker-rendszerképbe. A képcímke tartalmazza a BUILD_BUILDID, így a rendszerkép mindig csatolható az azt tartalmazó forráskódhoz.
• A rendszerkép leküldése egy Container Registry-példányba.
• A deltafájl létrehozása.
• Hozzon létre egy aláírási fájlt a rendszerképhez, és mentse a fájlt egy Azure Storage-fiókba.

Minden folyamatpéldány egyetlen YAML-folyamatdefiníción alapul. A folyamat környezeti változók használatával képes a modulokra reagálni. A szűrők csak akkor aktiválják az egyes folyamatokat, ha a módosítások véglegesítése egy adott mappában történik. Ez a szűrő elkerüli az összes modul összeállítását, ha csak egy modul frissül.

Kép–eszköz folyamat

A rendszerkép-eszköz folyamat üzembe helyezi a Docker-lemezképeket a megcélzott eszközökön egy jegyzékfájlban meghatározott módon. A folyamat manuális aktiválása elindítja az üzembe helyezést.

A folyamatdefiníció azt határozza meg, hogy ezeket az üzemelő példányokat egy tárolóban futtassa. A folyamatok támogatják a lemezképek változó bemenetét a tárolók alapozásához. Egyetlen változó vezérelheti az összes folyamat üzembe helyezését.

A rendszerkép tartalmazza azt a kódot, amely meghatározza, hogy mely javításokat kell létrehozni, buildeli a javításokat, és elosztja őket a fájlátviteli eszköz Azure-oldalán.

A képterjesztési eszköznek a következő információkra van szüksége:

• Az adattárban található jegyzék által biztosított üzembe helyezendő rendszerkép(ek).
• A folyamatot aktiváló felhasználó által biztosított, üzembe helyezendő eszközök.
• Melyik rendszerkép(ek) vannak már a megcélzott eszközökön, amelyeket egy Azure SQL-adatbázis biztosít.

A folyamat kimenetei a következők:

• A fájlátviteli eszköz Azure-oldalára küldött javításcsomagok, amelyeket az eszközökre kell terjeszteni.
• AZ SQL-adatbázis azon bejegyzései, amelyek jelzik, hogy mely rendszerképek kezdtek átvinni az egyes eszközökre.
• SQL-adatbázisbejegyzések az új üzembehelyezési csoportokhoz. Ezek a bejegyzések tartalmazzák az üzembe helyezést elrendelő felhasználó nevét és e-mail-címét.

Ez a folyamat a következő lépéseket hajtja végre:

1. A szükséges rendszerképeket az üzembehelyezési jegyzék alapján határozza meg.
2. Lekérdezi az SQL-t, hogy lássa, mely képek vannak már az eszközökön. Ha az összes rendszerkép már jelen van, a folyamat sikeresen leáll.
3. Meghatározza, hogy mely javításcsomagokat kell létrehozni. Az algoritmus meghatározza, hogy melyik kezdő kép hozza létre a legkisebb javításcsomagot.
   • Bemenetek: Egy .tar fájl, amely tartalmazza az üzembe helyezendő új lemezképet, valamint aláírási fájlokat a meglévő lemezképekhez az eszközökön.
   • Kimenet: A meglévő képek rangsora a legkisebb létrehozandó javítás meghatározásához.
4. Létrehozza az egyes eszközökhöz szükséges javításcsomagokat. Egyszer készít hasonló javításokat, és minden olyan eszközre átmásolja őket, amelyekre szüksége van.
5. Elosztja a javításokat a fájlátviteli eszköz tárfiókjába az üzembe helyezéshez.
6. Frissítések SQL-t, hogy megjelölje az új lemezképeket in transit az egyes célzott eszközökre vonatkozóan.
7. Hozzáadja az üzembehelyezési csoport adatait az SQL-hez a rendszerképet üzembe helyező személy nevével és e-mail-címével.

Jegyzék-eszköz folyamat

A jegyzék-eszköz folyamat leküldi az üzembehelyezési jegyzékfájlt a frissítendő eszköz megfelelő IoT Hub-kapcsolatára. A felhasználó manuálisan aktiválja a folyamatot, és meghatároz egy környezeti változót az IoT Hub-példány számára.

A folyamat:

• Meghatározza, hogy mely rendszerképekre van szüksége az üzembe helyezéshez.
• Lekérdezi az SQL-t, hogy a szükséges rendszerképek mind a megcélzott eszközökön legyenek. Ha nem, a folyamat állapottal failed végződik.
• Leküldi az új üzembehelyezési jegyzékfájlt a megfelelő IoT Hubra.

Gyors fájlátviteli megoldás

Az ügyfél továbbra is a külső, FileCatalyst nevű gyors fájlátviteli megoldással akarta biztosítani a kapcsolatot az Azure és az IoT-eszközeik között. Ez a megoldás egy végül konzisztens fájlátviteli eszköz, ami azt jelenti, hogy az átvitel hosszú időt vehet igénybe, de végül a fájladatok elvesztése nélkül befejeződik.

A megoldás egy Azure Storage-fiókot használt a kapcsolat Azure-oldalán, valamint az ügyfél meglévő fájlátviteli gazdagépét minden lemezképet fogadó eszközhöz. A javításcsomagok átkerülnek egy IoT Hubot futtató Linux rendszerű virtuális gépre.

Képrekonstrukciós modul

A Képrekonstrukció IoT Edge modul a kapott javításokat alkalmazza az eszközökön. Minden eszköz saját helyi tárolóregisztrációs adatbázist üzemeltet a Docker nyílt forráskódú beállításjegyzékével. A képrekonstrukciós folyamat a gazdagép virtuális gépén fut, amely megegyezik a fájlátviteli virtuális géppel.

A modul:

1. Megkapja a javításcsomagot a tárolóhoz csatlakoztatott mappában.
2. Bontsa ki a javítás tartalmát a konfigurációs fájl olvasásához.
3. Kivonattal lekéri az alaprendszerképet a helyi tárolóregisztrációs adatbázisból.
4. Az alaprendszerképet .tar fájlként menti.
5. Alkalmazza a javítást az alaprendszerképre.
6. Betölti az új képet tartalmazó .tar fájlt a Dockerbe.
7. Leküldi az új lemezképet a helyi tárolóregisztrációs adatbázisba egy rövid nevet és címkét tartalmazó konfigurációs fájllal.
8. Sikeres üzenetet küld az IoT Hubnak.

Ha a folyamat bármikor meghiúsul, a modul hibaüzenetet küld az IoT Hubnak, így az üzembe helyezést kezdeményező felhasználó értesítést kaphat.

IoT Hub

Az üzembehelyezési folyamatok közül több is az IoT Hubot használja. Az IoT Hub a Képrekonstrukció modul állapotüzeneteinek fogadása mellett beállítja az eszköz üzembehelyezési jegyzékét. A folyamat többi része ezt a jegyzékfájlt használja.

Azure Functions

Az Azure Functions figyeli az IoT Hubról érkező üzenetfolyamot, és a felhőben hajt végre műveleteket.

Sikeres üzenet esetén:

• A függvény frissíti az eszközön lévő rendszerkép SQL-bejegyzésének állapotát.in transitsucceeded
• Ha ez a rendszerkép az utolsó, amely egy üzembe helyezési csoportban jelenik meg:
  • A függvény értesíti a felhasználót az üzembe helyezés sikerességéről.
  • A függvény frissíti a jegyzék-eszköz folyamatot az új rendszerképek használatának megkezdéséhez.

Hibaüzenet esetén:

• A függvény frissíti az eszközön lévő rendszerkép SQL-bejegyzésének állapotát.in transitfailed
• A függvény értesíti a felhasználót a képátviteli hibáról.

SQL Database

Az SQL-adatbázis nyomon követi a céleszközökön és az Azure-alapú üzembehelyezési szolgáltatásokban az üzembe helyezés során és után előforduló eseményeket. Az Azure Functions és az Azure Pipelines egyaránt egy privát NuGet-csomagot használ, amelyet az adatbázis kezeléséhez hoztak létre.

Az SQL Database a következő adatokat tárolja:

• Mely képek vannak az egyes eszközökön.
• Mely képek vannak útban az egyes eszközökhöz.
• Az üzembe helyezett rendszerképek egy készlethez tartoznak.
• Az üzembe helyezéseket elrendelő felhasználó.

Ebben a példában az volt a cél, hogy a rendszer létrehozza a szükséges adatokat a jövőbeli adat irányítópultokhoz. Az IoT Hub lekérdezése a következő adatokat szolgáltathatja az eszköz-jegyzékfolyamatról:

• Az üzembe helyezés állapota.
• A képek egy adott eszközön.
• A képpel rendelkező eszközök.
• A sikeres és sikertelen átvitelek idősoradatai.
• Üzembe helyezési lekérdezések felhasználó alapján.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

• Kanio Dimitrov | Fő szoftvermérnöki vezető

Következő lépések

• Az első IoT Edge-modul üzembe helyezése virtuális Linux-eszközön
• IoT Edge-modulok fejlesztése Linux-tárolókkal

Kapcsolódó erőforrások

• Az Azure IoT referenciaarchitektúrája
• CI/CD-folyamat tervezése az Azure DevOps használatával
• Kis késésű hálózati kapcsolatok az iparág számára