Jelikož se Internet věcí (IoT) stávají větší všudypřítomný, přesune se zpracování na Edge jako klíčový model, který řeší potřeby, jako je připojení s nízkou latencí a zachování šířky pásma. To je obzvláště pravdivé ve scénářích, které se týkají mobility, které jsou běžně charakteristické při připojení přerušované a nízké šířky pásma. Vzhledem k tomu, že budete obvykle zřizovat hraniční zařízení nasazením imagí softwarového kontejneru, přerušení procesů nasazení mohou způsobit selhání v mobilních scénářích. V důsledku toho možná budete potřebovat spolehlivou a odolnou možnost nasazení v situacích, kdy máte omezené, přerušované nebo nízké šířky pásma.
Tento článek shrnuje proces a komponenty, které tým společnosti Microsoft pro technický software Engineering (na více systémů) použil k sestavení řešení pro řešení tohoto scénáře. Toto řešení povolilo nasazení kontejnerů Docker pro heterogenní vzdálených zařízení IoT napříč přerušovanými internetovými připojeními s malou šířkou pásma, jako je například družicová platforma, od zákazníka pro IoT Edge. Tým s použitím tohoto rozšíření dosahuje minimalizací velikosti nasazení na každé zařízení a povolením spolehlivého monitorování těchto nasazení.
Potenciální případy použití
Toto řešení je vhodné pro všechny scénáře, kdy se kontejnery softwaru používají jako součást řešení a připojení je přerušované s malou šířkou pásma. Mezi příklady patří následující:
Mobilní scénáře
Vysoce doduchové aktualizace pro automobil
Ropný plyn a těžba
Retail
Jakékoli silné připojení není zaručené.
Architektura
Ve scénářích s vysokou šířkou pásma Azure IoT Edge načítat image přímo z registru Docker přístupného přes Internet, buď z dokovacího centra, nebo z privátního zařízení, jako je Azure Container Registry (ACR). Jedná se o stejné funkce jako při spuštění příkazu "docker pull <image_name> " z místního počítače.
Pokud ale budete nuceně pracovat s potenciálně přerušovaným síťovým přístupem, jako je satelitní připojení k Internetu, bude metoda vyžádání obsahu Docker nespolehlivá. Konkrétně se postup nebude ukládat do mezipaměti, pokud připojení k Internetu poklesne, zatímco Docker načte image. Takže po obnovení připojení k Internetu musí Docker začít navrátit Image od začátku.
V následujících částech najdete popis alternativního mechanismu nasazení, který kompenzuje limity vynucené přerušovaným připojením.
Následující diagram znázorňuje architekturu vysoké úrovně tohoto řešení.
Požadavky pro návrh
Zákazník potřeboval řešení, které by podporovalo přerušované cloudové připojení s nízkou šířkou pásma. díky tomu můžou nasazené aplikace i nadále běžet místně a umožní místním pracovníkům používat funkce bez zpoždění přenosu do cloudu a současně i v offline režimu. Při připojení ke cloudu je řešení potřebné k efektivnímu používání cloudového připojení k určení priorit odesílání dat podle obchodních pravidel, která jsou konzistentně definovaná napříč produkty.
Tým rozšíření identifikoval následující podrobné požadavky na binární opravy souborů obrázků:
Soubory obrázků musí být přenesené přes malou šířku pásma (1Mbit/s), satelitní připojení s přerušovaným připojením.
Přenesená data by se měla co nejvíce minimalizovat.
Zákazník upřednostňuje, aby dál používal aplikaci třetí strany pro přenos souborů do zařízení.
Zatížení v zařízení se spustí v IoT Edge používání imagí Docker.
velikost obrázku bude v rozsahu od desítkových MB až po několik GB (Windows základní image jsou ~ 5,5 GB).
IoT Edge moduly budou napsány v .NET Core 2,2.
Komponenty
Azure
Třetí strana
Open source
Příklad případu použití
Hlavní logistická společnost chtěla zlepšit sledování svých celosvětových zásilek produktů, a to i přes geografické oblasti s přerušovaným připojením cloudu s nízkou šířkou pásma. Dodávky produktů v závislosti na tom, jaký typ zboží se dodávají, mají na tyto počítače nainstalovanou řadu zařízení IoT pro účely pojištění, bezpečnosti nebo sledování. Možnosti těchto zařízení, jako jsou sledovací pulty GPS, snímače teploty a nástroje pro zaznamenávání dalších relevantních datových bodů, které se liší od jednoho zařízení k druhému. a zboží by bylo možné dodávat pomocí nejrůznějších metod dopravy (například pozemního, leteckého a mořského) a široké škály vzdálených národních prostředí.
Řešení významně zvýšilo spolehlivost a odolnost procesu zřizování v prostředích s omezeným připojením. Následující diskuze popisuje proces vyhodnocení možností, podrobnosti řešení, které tým rozšíření vyvinul pro tohoto zákazníka, a další scénáře, ve kterých může být toto řešení užitečné.
Scénář zákazníka
Zákazník má problémy s aktualizací svých zařízení v nedávno vyvinuté platformě IoT Edge. Rozpracovanému týmu bylo ve spolupráci s zákazníkem řešit následující hlavní bolesti.
Vysoká spotřeba šířky pásma při nasazování aktualizovaného softwaru do zařízení.
Žádná standardizovaná automatizovaná nasazení napříč zařízeními a žádný způsob, jak zjistit, která zařízení měla aktualizace.
Omezená flexibilita při výběru technologie.
Vyhodnocení řešení
Ze čtyř možných vyhodnocených rozšíření pro řešení bylo více než jedna z nich životaschopná a dostupná. Rozšíření imagí zjistilo, že jako ideální řešení se považuje úplný datový přenos dat z doku.
Kritéria hodnocení
Rozšíření se považuje za následující:
Schopnost řešení splnit požadavky
- Ano, ne
Složitost zařízení IoT (kolik logiky je potřeba na zařízeních implementovat)
- Nízká, střední, vysoká
Složitost Azure (kolik logiky je potřeba implementovat v Azure)
- Nízká, střední, vysoká
Efektivita šířky pásma (poměr přenesených dat do celkové velikosti obrázku) pro přenos obrázku v těchto případech:
V zařízení neexistují žádné image.
V zařízení existuje obrázek se stejným základním obrázkem.
Obrázek představující předchozí verzi aplikace je na zařízení.
Obrázek aplikace sestavená na předchozí verzi základní Image je na zařízení.
Pro vyhodnocení efektivity šířky pásma, bitové kopie využité obrázky, které reprezentují následující sady.
| Scénář | Popis |
|---|---|
| Přenést nový obrázek – základní vrstva již na zařízení | Probíhá přesun nového obrázku, zatímco na zařízení je již jiná bitová kopie, která sdílí základní image. To představuje nasazení nové aplikace poprvé, zatímco existuje jiná aplikace ve stejném operačním systému a rozhraní. |
| Aktualizovat na aplikační vrstvu | Změna pouze kódu pro existující obrázek aplikace. To představuje typickou změnu, když uživatel potvrdí novou funkci. |
| Aktualizovat na základní image | Změna verze základní image, na které je aplikace založená. |
Následuje krátký popis čtyř možností a jejich kompromisů.
Možnosti hodnocení považované za řešení
Přenos vrstev Docker
Image je připojení systému souborů typu Union různých rozdílů systému souborů, které jsou jen pro čtení, a další zapisovatelné vrstvy pro všechny změny provedené v době, kdy je kontejner spuštěný. Tyto různé systémy souborů jsou známé jako vrstvy, které jsou v podstatě pouze složky a soubory. Vrstvy jsou skládané tak, aby tvořily základ kořenového systému souborů kontejneru. Vzhledem k tomu, že vrstvy jsou jen pro čtení, můžou různé image sdílet stejnou vrstvu, pokud mají společné.
V tomto řešení se znovu používají vrstvy mezi imagemi, takže stačí přenést nové vrstvy do zařízení. To by bylo nejčastější v obrázcích, které sdílejí stejnou základní vrstvu (obvykle operační systém, například Ubuntu nebo Alpine), nebo v bitových kopiích, které mají aktualizované verze existujících imagí.
Mezi kompromisy této metody patří:
Informace o tom, které vrstvy existují, ve kterých zařízeních musí být udržována v nástroji Orchestrator.
Změny základní vrstvy způsobí změnu hodnot hash všech dalších vrstev.
K porovnání jsou potřeba konzistentní hodnoty hash vrstvy.
Může zavádět závislost na zatížení Docker Save a Docker.
Změněný klient Docker
Toto řešení se zaměřuje na úpravu nebo zabalení klienta Docker tak, aby obnovil stahování vrstvy při přerušení připojení k Internetu. Ve výchozím nastavení bude stažení Docker pokračovat v stahování, pokud se v průběhu ~ 30 minut od přerušení obnoví připojení k Internetu. V opačném případě se klient ukončí a veškerý průběh stahování bude ztracen.
I když se jednalo o životaschopné řešení, mělo by to být komplikace, včetně:
Všechny Image v zařízení, které musí být zaregistrované pomocí démona Docker, se při přijímání imagí použijí k maximalizaci efektivity šířky pásma.
Otevřený zdrojový Docker projekt by se musel upravit tak, aby podporoval tuto upravenou funkci, což předvádí riziko pro projekt, pokud byl návrh zamítli Open Source údržbou.
Data by se přenesla přes protokol HTTP místo řešení s upřednostněným rychlým přenosem souborů od zákazníka, což by vyžadovalo vývoj vlastní logiky opakování.
Všechny vrstvy, které je potřeba znovu přenést při změně základní image.
Na hraničních zařízeních
Tento přístup přesune prostředí pro sestavení imagí do každého zařízení. V tomto scénáři se do zařízení odesílají tato data:
Zdrojový kód pro sestavenou aplikaci
kopie všech balíčků NuGet, na kterých má kód závislost
Základní image Docker pro prostředí sestavení .NET Core a modul runtime
Metadata o tom, co by měl vypadat na konci obrázku
Agent sestavení v zařízení pak vytvoří image a zaregistruje ji pomocí Správce Docker zařízení.
Toto řešení bylo odmítnuto z těchto důvodů:
Museli bychom potřebovat způsob, jak přesunout velké image Docker do zařízení. Obrázky pro sestavení aplikace .NET jsou větší než ty, aby je bylo možné spustit.
Tato metoda bude fungovat jenom pro aplikace .NET Core, kde má tým vlastní zdrojový kód, a při použití imagí třetích stran se neuplatní žádné výhody.
vytvoří nutnost zabalit a sledovat přesuny NuGet balíčků do zařízení.
Pokud se image na zařízení nepovede sestavit, tým by musel vzdáleně ladit prostředí buildu a vytvořenou image, což je spousta telemetrie, která překročí potenciálně omezené připojení k Internetu.
Přenos rozdílu úplného obrázku
Tento přístup zachází s imagí Docker jako s jedním binárním souborem. Toho dosáhnete pomocí příkazu Docker Save pro export obrázku jako souboru. tar. Exportováním dvou imagí Docker můžeme vypočítat binární rozdíl, který při použití provede transformaci jednoho obrázku na druhý.
V tomto řešení sledujeme existující image Docker na našich zařízeních a sestavíte binární rozdíly, které transformují existující image na nasazenou novou bitovou kopii. Tímto způsobem přenášíme jenom rozdíl mezi internetovým připojením s malou šířkou pásma.
Závěr vyhodnocení
V následující tabulce jsou uvedena všechna výše uvedená řešení měřená proti kritériím hodnocení z první části.
| Řešení | Splněné požadavky? | Složitost zařízení | Složitost Azure | Přenos | První obrázek | Na zařízení existuje základna. | Aktualizovat na aplikační vrstvu | Aktualizovat na základní vrstvu |
|---|---|---|---|---|---|---|---|---|
| Přenos vrstev Docker | Ano | Nízká | Střední | Katalyzátor | 100 % | 10,5% | 22,4% | 100 % |
| Změněný klient Docker | Ano | Střední | Nízká | HTTP | 100 % | 10,5% | 22,4% | 100 % |
| Na hraničních zařízeních | Ne | Vysoká | Střední | Katalyzátor | N/A | N/A | N/A | N/A |
| Přenos rozdílu úplného obrázku | Ano | Nízká | Vysoká | Katalyzátor | 100 % | 3,2% | 0,01 % | 16,1% |
Na základě výše uvedených podrobností zabere rozšíření s použitím úplného převodu na rozdílovou image. Toto řešení vyžadovalo některé vlastní logiky pro sestavování binárních oprav, ale byla to nejúčinnější možnost z pohledu množství dat, která se odesílají do zařízení.
Požadavky
Podrobnosti řešení
Vývojáři budou pracovat se zdrojovým kódem pro své moduly v úložišti zdrojového kódu. Základní struktura úložiště se skládá ze složek, které obsahují kód pro každý modul, následovně:
\- repository root
- modulea
- modulea.csproj
- module.json
- Program.cs
- Dockerfile
\- moduleb
- moduleb.csproj
- module.json
- Program.cs
- Dockerfile
Počet úložišť zdrojového kódu je v podstatě preference; Existují však dva doporučené vzory a v jakém rozšíření pro tohoto zákazníka bylo:
Jedno úložiště pro všechny moduly vyvinuté ve všech workstreams.
Jedno úložiště zdrojového kódu pro každý workstream.
Zdrojové kanály sestavení úložiště
k dispozici je Azure DevOps kanál sestavení pro každý modul. Tyto kanály zodpovídá za:
Kontrola zabezpečení zdrojového kódu.
Kontrola zabezpečení základní image pro sestavení image Docker.
Spouštění testů jednotek pro modul.
Vytvoření zdroje do image Docker. Značka image obsahuje _ BUILDID sestavení, aby bitová kopie mohla být vždy propojena zpět se zdrojovým kódem, který jej vytvořil.
Vložení obrázku do instance Azure Container Registry.
Vytváří se rozdílový soubor.
Vytvoří se soubor podpisu pro image a uloží se do účtu úložiště Azure.
Všechny instance kanálu můžou být založené na jedné definici kanálu YAML. Modul lze zpracovat při použití proměnných prostředí s filtry přidanými do každého kanálu, aby byly aktivovány pouze v případě, že jsou změny potvrzeny v určité složce. Tím se vyhnete vytváření všech modulů, když se aktualizuje jenom jedna z nich.
jak vidíte níže, k vytváření a registraci modulů se používá obecné sestavení docker, které využívá Azure DevOps kanál sestavení.
Azure Container Registry
Azure Container Registry (ACR) se používá k ukládání imagí Docker jednotlivých modulů. Pro ACR existují dvě možné konfigurace:
Jedna instance ACR, která ukládá všechny image
ACR systém: jeden ukládá vývoj, testování a ladění imagí; druhý obsahuje jenom image ověřované dalším testováním a označené jako připravené pro produkční prostředí.
Úložiště manifestu
Úložiště manifestu obsahuje manifesty nasazení pro všechny workstreams. Šablony jsou umístěny do složek v závislosti na workstream, které představují, zobrazené níže. V této zapojení jsou dvě workstreams sdílená infrastruktura a aplikace kontejnerů (software).
\- repository root
- Workstream1
- deployment.template.json
- Workstream2
- deployment.template.json
Kanál úložiště manifestu – zařízení s bitovou kopií
Tento kanál zodpovídá za nasazení imagí do různých cílových zařízení, která jsou definována souborem manifestu. Pokud chcete spustit nasazení, musíte kanál aktivovat ručně.
Definice těchto kanálů určuje, že tato činnost nasazení je spuštěná v kontejneru. Azure DevOps podporuje spouštění kanálů sestavení uvnitř kontejnerů a podporuje vstup proměnných, pro který image založí kontejner. Tímto způsobem může jedna proměnná řídit image, na které jsou založeny všechny kanály.
Tato image obsahuje kód potřebný k určení, které opravy se mají sestavit, k vytvoření těchto oprav a jejich distribuci do Azure straně nástroje pro přenos souborů.
K provozu Nástroj pro distribuci obrázků potřebuje následující informace:
Image, které se mají nasadit (poskytované manifestem v úložišti)
Zařízení, která se mají nasadit (od uživatele, který aktivuje kanál)
Image již na cílových zařízeních (poskytované databází SQL v Azure)
Výstupy kanálu jsou:
Balíčky oprav, které se odesílají do Azure straně nástroje pro přenos souborů k distribuci do zařízení.
položka v SQL databáze, která označuje, které image začaly přenášet do každého zařízení.
položka v SQL databáze představující novou sadu nasazení. To zahrnuje informace o tom, kdo nařídil nasazení a e-mailovou adresu pro kontakt, pokud došlo k potížím s nasazením.
Tento proces zahrnuje následující kroky:
Určete, které image jsou nutné na základě manifestu nasazení.
dotaz SQL k zobrazení, které image jsou již na cílových zařízeních. Pokud jsou všechny přítomné, kanál se úspěšně ukončí.
Určete, které balíčky oprav je třeba vytvořit.
Algoritmus, který určuje počáteční obrázek, vygeneruje nejmenší opravu balíčku.
Vstupy:. tar File obsahující nově nasazenou image a soubory signatur pro existující image na zařízeních.
Output (výstup): rozsah stávajících imagí pro určení nejmenší opravy, která se má vytvořit.
Z tohoto seznamu seřazeného rozsahu se dá určit, které opravy se mají pro každé zařízení sestavit. Podobné opravy jsou postavené jednou a pak se zkopírují do všech zařízení, která je potřebují.
Vytvořte potřebné sady oprav, jak je určeno v předchozím kroku.
Distribuujte opravy do účtu úložiště nástroje pro přenos souborů pro nasazení.
aktualizujte SQL k označení nových imagí jako "při přenosu" na každé cílové zařízení.
přidejte informace o sadě nasazení SQL společně s kontaktním e-mailem pro osobu, která nasazuje bitovou kopii.
Kanál úložiště manifestu pro manifest k zařízení
Tento kanál pošle novému manifestu nasazení do správné služby IoT Hub pro aktualizované zařízení. Toto je ručně aktivovaný kanál. Kanál:
Určuje, které image jsou pro nasazení potřeba.
dotazy SQL, abyste se ujistili, že požadované image jsou už na cílových zařízeních.
- Pokud nejsou, kanál se tady ukončí se stavem "neúspěch".
Vloží nový manifest nasazení do správného centra IoT Hub.
Instance IoT Hub, kde je nabízeno nasazení, je proměnná prostředí konfigurovaná při vytvoření kanálu.
Řešení rychlého přenosu souborů
Tento zákazník už používá řešení rychlého přenosu souborů označované jako soubor. Catalyst, které preferují pokračování v používání. Toto řešení, označované také jako "nakonec konzistentní" Nástroj pro přenos souborů, poskytuje připojení mezi Azure a zařízeními IoT. Pojem nakonec konzistentní znamená, že může trvat týdny, než se přesunou z A na B, ale nakonec se dokončí bez ztráty informací o souboru. rozšíření pro příjem imagí použilo na straně Azure účet Azure Storage a na každé ze zařízení existující virtuální počítač pro přenos souborů (VM) daného zákazníka. Jakmile balíčky oprav dorazí do zařízení, přenesou je stávající procesy do virtuálního počítače se systémem Linux. Odtud se soubor přesune do virtuálního počítače se systémem Linux, na kterém běží IoT Hub.
Modul rekonstrukce image
Za použití přijatých oprav na zařízeních zodpovídá modul pro obnovu image IoT Edge. Funguje:
Probíhá příjem balíčku oprav do složky připojené ke kontejneru.
Rozzipovává obsah pro čtení konfiguračního souboru.
Nastahování základní image z místního registru kontejneru (pomocí hash)
Základní obrázek se uloží jako soubor. tar.
Aplikuje se oprava na základní image.
Načítají se nové soubory. tar obsahující novou image do Docker.
Vložení nové image do místního Container Registry. V konfiguračním souboru je uveden popisný název a značka.
Odesílá se IoT Hub zpráva o úspěchu.
Pokud proces kdykoli selže, zodpovídá za odeslání zprávy o selhání IoT Hub, aby bylo možné upozornit uživatele, který toto nasazení objednal. Funkce Azure Functions sleduje IoT Hub Stream zpracovává tyto image a v cloudu provede akci, jakmile budou připravené.
Místní registr kontejnerů
Každé zařízení hostuje svůj vlastní místní registr kontejnerů. V tomto řešení používalo rozšíření Open Source Registry distribuované nástrojem Docker. Tento proces běží na hostitelském virtuálním počítači, který se používá také jako stávající virtuální počítač pro přenos souborů.
Azure IoT Hub
IoT Hub používá několik dalších procesů nasazení. Centrum IoT přijímá stavové zprávy z modulů pro rekonstrukci imagí. také nastavuje manifesty nasazení pro různá různá zařízení a tyto manifesty se pak používají zbývající DevOps toku.
Azure Functions
Funkce Azure slouží k monitorování datového proudu zpráv přicházejících ze služby IoT Hub. Zodpovídá za to, že funguje na zprávách odesílaných moduly rekonstrukce imagí na každé zařízení.
V případě úspěšné zprávy:
funkce aktualizuje stav položky SQL pro obrázek v zařízení z "v přenosu" do "úspěšného".
Pokud se jedná o poslední obrázek, který se dostane do sady nasazení:
funkce upozorní uživatele (pomocí e-mailových oznámení nakonfigurovaných na SQL serveru) úspěšného nasazení.
Funkce také aktivuje kanál manifestu na zařízení, aby bylo možné začít používat nové image.
V případě zprávy o selhání:
položka SQL pro obrázek ve stavu zařízení je aktualizována z "při přenosu" na "neúspěšné".
uživateli se zobrazí oznámení (pomocí e-mailových oznámení nakonfigurovaných na SQL serveru) neúspěšného přenosu obrázku.
Databáze SQL
SQL databáze zodpovídá za sledování stavu toho, co se děje na cílových zařízeních a službách nasazení na základě Azure během a po procesech nasazení.
pro interakci s databází, kterou používá Azure Functions i Azure Pipelines, byl vytvořen privátní NuGet balíček.
Aktuálně uložená data jsou:
Na kterých obrázcích se nachází zařízení.
Které image jsou na cestě, na které se zařízení nachází.
Které image se nasazují, patří do sady, která si toto nasazení objednala.
Tato možnost se dá použít jako zdroj dat pro řídicí panel, který zobrazuje:
Stav nasazení.
Obrázky na daném zařízení.
Zařízení s obrázkem.
Úspěšná a neúspěšná přenos dat časové řady
Dotazy na nasazení založené na uživateli
Hlavním cílem během této zapojení zákazníka bylo zajistit, aby systém generoval data, která by byla v budoucnu potřeba. Řešení umožňuje budoucím řídicím panelům dotazovat se na IoT Hub a získat tak statistiku o spuštění IoT Edgech zařízení, která budou mít přehled o úspěchu kanálu manifestu na zařízení.
Souhrn implementace
Implementace tohoto řešení výrazně snížila šířku pásma využívanou aktualizacemi zařízení IoT. Rozpis rozdílů v efektivitě přenosu je uveden níže.
Další kroky
Další podrobnosti o procesech a technologiích, které slouží k vytvoření tohoto řešení, najdete v těchto tématech: