Efektivní nasazení image Dockeru pro připojení s nízkou šířkou pásma

Tento článek popisuje řešení pro nasazení kontejnerizovaných hraničních modulů IoT (Internet-of-things) mezi přerušovanými nebo málo šířkou pásma připojení k internetu.

Zpracování edge je klíčovým vzorem internetu věcí (IoT), který zajišťuje připojení s nízkou latencí a šetří šířku pásma, například v mobilních scénářích. Systémy IoT obvykle zřizují hraniční zařízení nasazením imagí softwarového kontejneru. Přerušení nasazení kontejnerů přes přerušovaná připojení k internetu s nízkou šířkou pásma může způsobit selhání v mobilních scénářích. Scénáře IoT, které mají omezené, přerušované nebo nízké šířky pásma, vyžadují spolehlivé a odolné možnosti nasazení.

V tomto příkladu chtěla velká logistická společnost zlepšit sledování zásilek produktů po celém světě. Společnost dodává zboží s různými metodami pozemní, letecké a námořní dopravy do mnoha národních prostředí, včetně oblastí s přerušovaným připojením k internetu s nízkou šířkou pásma. V závislosti na typu zboží měly dodávky produktů různé systémy IoT pro pojištění, bezpečnost nebo sledování zařízení s různými možnostmi. Zařízení obsahovala GPS trackery, senzory teploty a nástroje pro zachytávání dat.

Společnost měla problémy s aktualizací zařízení v nedávno vyvinuté platformě Azure IoT Edge. Hlavní body bolesti byly:

• Vysoká spotřeba šířky pásma při nasazování aktualizovaného softwaru do zařízení.
• Žádné standardizované automatizované nasazení napříč zařízeními.
• Omezená flexibilita výběru technologií.

Vývojový tým vytvořil řešení, které řeší tyto problémy:

• Minimalizuje velikost nasazení do každého zařízení a snižuje šířku pásma.
• Implementuje standardizované nasazení kontejneru Dockeru z platformy IoT Edge do heterogenních vzdálených zařízení IoT.
• Umožňuje spolehlivé monitorování nasazení.
• Využívá různé služby Azure DevOps a cloudových služeb a využívá upřednostňované starší nástroje zákazníka.

Řešení výrazně zvyšuje spolehlivost a odolnost procesu zřizování zařízení v prostředích s omezeným připojením. Tento článek popisuje podrobnosti o řešení a proces vyhodnocení možností řešení.

Požadavky zákazníků

Zákazník měl následující požadavky:

• Řešení musí podporovat přerušované cloudové připojení s malou šířkou pásma.
• Nasazené aplikace musí dál běžet místně.
• Místní zaměstnanci potřebují používat funkce offline nebo bez zpoždění odezvy v cloudu.
• Při připojení musí řešení efektivně používat cloudové připojení.
• Řešení musí určovat prioritu odesílání dat podle konzistentně definovaných obchodních pravidel napříč produkty.

Byly zde také následující podrobné požadavky:

• Soubory obrázků se přenášejí přes malou šířku pásma a přerušované připojení satelitního připojení.
• Objem přenášených dat by se měl minimalizovat.
• Přenos souborů do zařízení používá preferovanou aplikaci třetí strany zákazníka.
• Úlohy zařízení používají image Dockeru v IoT Edge.
• Velikosti obrázků jsou v rozsahu od desítek MB do několika GB.
• Moduly IoT Edge jsou napsané v .NET Core 2.2.

Potenciální případy použití

Toto řešení je vhodné pro scénáře IoT, kdy softwarové kontejnery poskytují řešení přes malou šířku pásma přerušovaná připojení. Příkladem může být:

• Monitorování vzdálené ropy, plynu a těžby
• Aktualizace v automobilovém průmyslu nad vzduchem
• Bez zaručení silného připojení

Architektura

Ve scénářích s velkou šířkou pásma služba Azure IoT Edge načítá image přímo z internetového registru Dockeru, buď centra Dockeru, nebo privátního centra, jako je Azure Container Registry. Tato funkce je stejná jako spuštění docker pull <image_name> příkazu.

S potenciálně přerušovaným přístupem k síti, jako je například satelitní připojení k internetu, je metoda vyžádání dockeru nespolehlivý. Průběh není uložen v mezipaměti, pokud se připojení k internetu zahodí, když Docker načítá image. Když se připojení k internetu obnoví, musí Docker začít znovu načíst image od začátku.

Řešení používá alternativní mechanismus nasazení, binární opravy souborů imagí Dockeru, ke snížení šířky pásma a kompenzaci přerušovaného připojení.

Tok dat

1. Vývojáři pracují se zdrojovým kódem modulu Edge v úložišti zdrojového kódu.
2. Container Registry ukládá image Dockeru jednotlivých modulů.
3. Úložiště manifestu obsahuje manifesty nasazení pro všechny pracovní streamy.
4. Každý modul má kanál buildu Azure Pipelines, který k automatickému vytváření a registraci modulů používá obecné sestavení Dockeru.
5. Kanál image-zařízení nasadí image Dockeru do cílových zařízení, jak je definováno souborem manifestu.
6. Kanál manifestu zařízení odešle manifest nasazení do správné služby Azure IoT Hub pro zařízení, které se aktualizuje.
7. Řešení rychlého přenosu souborů třetí strany přenáší soubory z účtu služby Azure Storage do zařízení.
8. Modul IoT Edge pro obnovení image aplikuje přijaté opravy na zařízeních.
9. IoT Hub přijímá stavové zprávy z modulu Obnovení image a nastavuje manifest nasazení pro zařízení. Zbytek toku kanálu používá tento manifest nasazení.
10. Azure Functions monitoruje stream zpráv ioT Hubu, aktualizuje databázi SQL a upozorní uživatele na úspěch nebo selhání.
11. Azure SQL Database sleduje výskyty na cílových zařízeních a službách založených na Azure během a po nasazení.

Komponenty

• Azure IoT Edge spouští kontejnerizované úlohy na zařízeních, které poskytují připojení s nízkou latencí a šetří šířku pásma.
• Azure IoT Hub je spravovaná cloudová hostovaná služba, která funguje jako centrální centrum zpráv mezi aplikacemi IoT a zařízeními, která řídí.
• Azure Container Registry je cloudová služba privátního registru pro ukládání a správu privátních imagí kontejnerů Dockeru a souvisejících artefaktů.
• Azure Pipelines kombinuje kontinuální integraci (CI) a průběžné doručování (CD) a automaticky testuje a sestavuje kód a odesílá ho do libovolného cíle.
• Azure Functions je bezserverová výpočetní platforma, která umožňuje spouštění kódu aktivovaného událostí bez nutnosti zřizovat nebo spravovat infrastrukturu.
• Azure Storage poskytuje vysoce škálovatelné, zabezpečené, výkonné a nákladově efektivní úložiště pro všechny typy obchodních dat, objektů a souborů.
• Azure SQL Database je plně spravovaná multimodelová relační databázová služba vytvořená pro cloud.
• Docker je otevřená platforma pro vývoj, dopravu a spouštění kontejnerizovaných aplikací.

Alternativy

Vývojový tým vyhodnotil několik možností před rozhodnutím o úplném řešení rozdílového přenosu image Dockeru. Následující části popisují alternativy vyhodnocení a výsledky.

Tým pro každou možnost považoval následující kritéria hodnocení:

• Bez ohledu na to, jestli řešení splňovalo požadavky.
• Ať už je na zařízeních potřeba implementovat nízkou, střední nebo vysokou logiku.
• Ať už je potřeba implementovat v Azure nízkou, střední nebo vysokou logiku.
• Efektivita šířky pásma nebo poměr přenášených dat k celkové velikosti image pro přenos image kontejneru

Mezi scénáře efektivity šířky pásma patří:

• V zařízení neexistovaly žádné obrázky.
• Na zařízení existoval obrázek se stejnou základnou.
• Na zařízení existoval obrázek předchozí verze aplikace.
• Na zařízení existoval obrázek aplikace postavené na předchozí základní imagi.

Tým použil následující scénáře k vyhodnocení efektivity šířky pásma:

Možnost přenosu vrstev Dockeru

Image kontejneru Dockeru je připojení Systému souborů Jen pro čtení, přičemž další zapisovatelnou vrstvou pro změny provedené v době, kdy je kontejner spuštěný. Systémy souborů se nazývají vrstvy, což jsou v podstatě složky a soubory. Vrství zásobník pro vytvoření základu kořenového systému souborů kontejneru. Vzhledem k tomu, že vrstvy jsou jen pro čtení, můžou různé obrázky sdílet stejnou vrstvu, pokud mají společnou vrstvu.

Možnost přenosu vrstev Dockeru znovu použije vrstvy mezi imagemi a přenese do zařízení pouze nové vrstvy. Tato možnost by byla nejužitečnější pro image, které sdílejí stejnou základní vrstvu, obvykle operační systém nebo pro aktualizaci verzí existujících imagí.

Mezi nevýhody této metody patří:

• Orchestrátor musí udržovat informace o tom, které vrstvy existují na kterých zařízeních.
• Změny základní vrstvy způsobí, že se změní hodnoty hash všech následných vrstev.
• Porovnání vyžaduje konzistentní hodnoty hash vrstev.
• Při ukládání Dockeru a načítání Dockeru můžou existovat závislosti.

Úprava možnosti klienta Dockeru

Tato možnost se zaměřuje na úpravu nebo zabalení klienta Dockeru, aby po přerušení obnovil stahování vrstev. Ve výchozím nastavení stahování Dockeru obnoví stahování, pokud se připojení k internetu obnoví během přibližně 30 minut od přerušení. V opačném případě klient ukončí a ztratí veškerý průběh stahování.

Tato metoda je proveditelná, ale měla komplikace, mezi které patří:

• Aby se maximalizovala efektivita šířky pásma, musí být všechny image na zařízení zaregistrované u démona Dockeru, který načítá image.
• Opensourcový projekt Dockeru by musel být upraven tak, aby podporoval tuto funkci, což představuje riziko zamítnutí opensourcovými správci.
• Přenos dat přes protokol HTTP místo řešení rychlého přenosu souborů preferovaného zákazníkem by vyžadoval vývoj vlastní logiky opakování.
• Při změně základní image je nutné znovu převést všechny vrstvy.

Možnost Sestavit na hraničním zařízení

Tento přístup přesune prostředí sestavení image do zařízení. Do zařízení se odesílají následující data:

• Zdrojový kód pro vytvářenou aplikaci
• Kopie všech balíčků NuGet, na které kód závisí
• Základní image Dockeru pro prostředí sestavení .NET Core a modul runtime
• Metadata o koncovém obrázku

Agent sestavení na zařízení pak sestaví image a zaregistruje ji ve Správci Dockeru zařízení.

Toto řešení bylo odmítnuto, protože:

• Stále by bylo potřeba přesunout velké image Dockeru do zařízení. Image pro vytváření aplikací .NET jsou větší než samotné image aplikací.
• Tato metoda funguje jenom pro aplikace, ve kterých má tým zdrojový kód, takže nemůže používat obrázky třetích stran.
• Tato možnost vyžaduje balení balíčků NuGet a sledování jejich pohybu do zařízení.
• Pokud se nepodařilo sestavit image na zařízení, tým by musel vzdáleně ladit prostředí sestavení a vytvořenou image. Vzdálené ladění by vyžadovalo vysoké využití potenciálně omezeného připojení k internetu.

Možnost přenosu rozdílu úplného obrázku

Zvolený přístup považuje image Dockeru za jediný binární soubor. Příkaz Dockeru save exportuje image jako soubor .tar . Řešení exportuje existující a nové image Dockeru a vypočítá binární rozdíl, který při použití transformuje existující image na novou.

Řešení sleduje existující image Dockeru na zařízeních a sestavuje binární rozdílové opravy pro transformaci existujících imagí na nové image. Systém přenáší pouze rozdílové opravy v internetovém připojení s nízkou šířkou pásma. Toto řešení vyžadovalo pro sestavení binárních oprav určitou vlastní logiku, ale do zařízení odeslalo nejmenší množství dat.

Výsledky vyhodnocení

Následující tabulka ukazuje, jak se všechna výše uvedená řešení měří podle kritérií hodnocení.

Důležité informace

Tyto aspekty implementují pilíře architektury Azure Well-Architected Framework, která představuje sadu hlavních principů, které zlepšují kvalitu úloh. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Efektivita výkonu

Toto řešení výrazně snížilo šířku pásma spotřebované aktualizacemi zařízení IoT. Následující tabulky ukazují rozdělení rozdílů v efektivitě přenosu.

Rekonstrukční obraz jako zdroj:

Předchozí verze jako zdroj:

Provozní dokonalost

Následující části obsahují podrobný návod k řešení.

Úložiště zdrojového kódu

Vývojáři pracují se zdrojovým kódem modulu Edge v úložišti zdrojového kódu. Úložiště se skládá ze složek, které obsahují kód pro každý modul, a to následujícím způsobem:

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

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

Doporučený počet úložišť zdrojového kódu je:

• Jedno úložiště pro všechny moduly napříč všemi pracovními streamy.
• Jedno úložiště zdrojového kódu pro každý pracovnístream.

Instance služby Container Registry

Container Registry ukládá image Dockeru jednotlivých modulů. Pro Container Registry existují dvě možné konfigurace:

• Jedna instance služby Container Registry, která ukládá všechny image.
• Dvě instance služby Container Registry, jedna pro ukládání imagí pro vývoj, testování a ladění a druhá, která obsahuje pouze image označené jako připravené pro produkční prostředí.

Úložiště manifestu

Úložiště manifestu obsahuje manifesty nasazení pro všechny pracovní streamy. Šablony jsou ve složkách založených na jejich pracovním streamu. V tomto příkladu jsou dva pracovnístreamy sdílenou infrastrukturou a kontejnerizovanou aplikací.

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

Kanál buildu image Dockeru

Každý modul má kanál buildu Azure Pipelines. Kanál používá k vytvoření a registraci modulů obecný build Dockeru. Kanál zodpovídá za:

• Kontrola zabezpečení zdrojového kódu
• Kontrola zabezpečení základní image pro sestavení image Dockeru
• Spouštění testů jednotek pro modul
• Vytvoření zdroje do image Dockeru Značka obrázku BUILD_BUILDIDobsahuje značku , takže image může být vždy propojena zpět se zdrojovým kódem, který ho vytvořil.
• Nasdílením image do instance služby Container Registry
• Vytvoření rozdílového souboru
• Vytvoření souboru podpisu pro image a uložení souboru do účtu úložiště Azure

Všechny instance kanálu jsou založené na jedné definici kanálu YAML. Kanál může pracovat s moduly pomocí proměnných prostředí. Filtry aktivují jednotlivé kanály pouze v případech, kdy se změny potvrdí v určité složce. Tento filtr zabraňuje sestavování všech modulů při aktualizaci pouze jednoho modulu.

Kanál image-zařízení

Kanál image-zařízení nasadí image Dockeru do cílových zařízení, jak je definováno souborem manifestu. Ruční aktivace kanálu spustí nasazení.

Definice kanálu určuje spuštění těchto nasazení v kontejneru. Kanály podporují vstup proměnných pro image, na základě které se založí kontejnery. Jedna proměnná může řídit nasazení pro všechny kanály.

Obrázek obsahuje kód, který určuje, které opravy se mají sestavit, sestavte opravy a distribuuje je na straně Azure nástroje pro přenos souborů.

Nástroj pro distribuci obrázků potřebuje následující informace:

• Které image se mají nasadit, které poskytuje manifest v úložišti.
• Která zařízení se mají nasadit, která poskytuje uživatel, který kanál aktivuje.
• Které image už jsou na cílových zařízeních poskytované databází Azure SQL.

Výstupy kanálu jsou:

• Sady oprav odesílané na stranu Azure nástroje pro přenos souborů, které se mají distribuovat do zařízení.
• Položky databáze SQL, které označují, které obrázky začaly přenášet do každého zařízení.
• Položky databáze SQL pro nové sady nasazení Tyto položky zahrnují jméno a e-mailovou adresu uživatele, který nasazení objednal.

Tento kanál provede následující kroky:

1. Určuje potřebné image na základě manifestu nasazení.
2. Dotazuje SQL, aby viděl, které image už jsou na zařízeních. Pokud už jsou všechny image k dispozici, kanál se úspěšně ukončí.
3. Určuje, které sady oprav se mají vytvořit. Algoritmus určuje, který spouštěcí image generuje nejmenší sadu oprav.
   • Vstupy: Soubor .tar obsahující novou image pro nasazení a soubory podpisu existujících imagí na zařízeních.
   • Výstup: Pořadí existujících imagí k určení nejmenší opravy, která se má vytvořit.
4. Vytvoří potřebné sady oprav pro každé zařízení. Vytvoří podobné opravy jednou a zkopíruje je do všech zařízení, která je potřebují.
5. Distribuuje opravy do účtu úložiště nástroje pro přenos souborů pro nasazení.
6. Aktualizace SQL, aby nové image označí jako in transit všechna cílová zařízení.
7. Přidá informace sady nasazení do SQL se jménem a kontaktním e-mailem osoby, která image nasazuje.

Kanál manifestu do zařízení

Kanál manifestu zařízení odešle manifest nasazení do správného připojení ioT Hubu pro zařízení, které se aktualizuje. Uživatel aktivuje kanál ručně a určí proměnnou prostředí, na které má instance IoT Hub cílit.

Kanál:

• Určuje, které image nasazení potřebuje.
• Dotazuje SQL, aby se zajistilo, že jsou všechny potřebné image na cílových zařízeních. Pokud ne, kanál se ukončí se stavem failed .
• Odešle nový manifest nasazení do správného IoT Hubu.

Řešení rychlého přenosu souborů

Zákazník chtěl pokračovat v používání svého řešení rychlého přenosu souborů třetích stran, označovaného jako FileCatalyst, k poskytování připojení mezi Azure a zařízeními IoT. Toto řešení je nakonec konzistentní nástroj pro přenos souborů, což znamená, že přenos může trvat dlouhou dobu, ale nakonec se dokončí bez ztráty informací o souboru.

Řešení použilo účet Azure Storage na straně Azure připojení a existující virtuální počítač hostitele přenosu souborů zákazníka pro každé zařízení, které přijímá image. Sady oprav se přenesou na virtuální počítač s Linuxem, na kterém běží IoT Hub.

Modul Obnovení obrázku

Modul IoT Edge pro obnovení image aplikuje přijaté opravy na zařízeních. Každé zařízení hostuje vlastní místní registr kontejneru pomocí opensourcového registru Dockeru. Proces obnovení image běží na hostitelském virtuálním počítači, který je stejný jako virtuální počítač pro přenos souborů.

Modul:

1. Přijme sadu oprav ve složce připojené k kontejneru.
2. Rozbalí obsah opravy a přečte konfigurační soubor.
3. Načítá základní image z místního registru kontejneru hodnotou hash.
4. Uloží základní image jako soubor .tar .
5. Použije opravu na základní image.
6. Načte soubor .tar obsahující novou image do Dockeru.
7. Odešle novou image do místního registru kontejneru s konfiguračním souborem včetně popisného názvu a značky.
8. Odešle zprávu o úspěchu do ioT Hubu.

Pokud proces v libovolném okamžiku selže, modul odešle do Služby IoT Hub chybovou zprávu, takže uživatel, který nasazení aktivoval, může být upozorněn.

IoT Hub

Několik procesů nasazení používá IoT Hub. Kromě příjmu stavových zpráv z modulu Obnovení image nastaví IoT Hub manifest nasazení pro zařízení. Zbytek toku kanálu používá tento manifest.

Azure Functions

Azure Functions monitoruje stream zpráv přicházející ze služby IoT Hub a provádí akce v cloudu.

Zpráva o úspěchu:

• Funkce aktualizuje stav položky SQL pro image na zařízení z in transit do succeeded.
• Pokud je tato image poslední, která dorazí do sady nasazení:
  • Funkce upozorní uživatele na úspěch nasazení.
  • Funkce aktualizuje kanál manifest-zařízení tak, aby začal používat nové image.

Pro zprávu o selhání:

• Funkce aktualizuje stav položky SQL pro image na zařízení z in transit do failed.
• Funkce upozorní uživatele na selhání přenosu image.

SQL Database

Databáze SQL sleduje výskyty na cílových zařízeních a službách nasazení založených na Azure během a po nasazení. Azure Functions i Azure Pipelines používají privátní balíček NuGet vytvořený pro interakci s databází.

SQL Database ukládá následující data:

• Které obrázky jsou na každém zařízení.
• Které obrázky jsou na cestě ke každému zařízení.
• Které image, které se nasazují, patří do sady.
• Uživatel, který seřadil nasazení.

Cílem tohoto příkladu bylo zajistit, aby systém vygeneroval potřebná data pro budoucí řídicí panely dat. Dotazování služby IoT Hub může poskytnout následující data o kanálu manifest-to-device:

• Stav nasazení
• Obrázky na daném zařízení.
• Zařízení, která mají obrázek.
• Data časových řad při úspěšných a neúspěšných přenosech
• Dotazy nasazení na základě uživatele

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

• Kanio Dimitrov | Vedoucí hlavního softwarového inženýrství

Další kroky

• Nasazení prvního modulu IoT Edge na virtuální zařízení s Linuxem
• Vývoj modulů IoT Edge s linuxovými kontejnery

Související prostředky

• Referenční architektura Azure IoT
• Návrh kanálu CI/CD pomocí Azure DevOps
• Síťová připojení s nízkou latencí pro odvětví