Effektiv Docker-avbildningsdistribution för anslutning med låg bandbredd

I den här artikeln beskrivs en lösning för att distribuera IoT-gränsmoduler (i containrar) över tillfälliga eller bandbreddssnåla Internetanslutningar.

Edge-bearbetning är ett viktigt IoT-mönster (Internet-of-things) för att tillhandahålla anslutningar med låg latens och spara bandbredd, till exempel i mobila scenarier. IoT-system etablerar vanligtvis gränsenheter genom att distribuera programcontaineravbildningar. Avbrutna containerdistributioner via tillfälliga internetanslutningar med låg bandbredd kan orsaka fel i mobila scenarier. IoT-scenarier som har begränsad, tillfällig eller låg bandbredd behöver tillförlitliga och motståndskraftiga distributionsfunktioner.

I det här exemplet ville ett stort logistikföretag förbättra sin globala produktleveransspårning. Företaget levererade varor med olika mark-, luft- och sjötransportmetoder till många platser, inklusive områden med tillfälliga internetanslutningar med låg bandbredd. Beroende på typen av varor hade produktsändningar olika IoT-försäkringar, säkerhets- eller spårningsenheter installerade på dem, med olika funktioner. Enheterna inkluderade GPS-spårare, temperatursensorer och datainsamlingsverktyg.

Företaget hade problem med att uppdatera enheter via sin nyligen utvecklade Azure IoT Edge-plattform. De viktigaste smärtpunkterna var:

• Hög bandbreddsförbrukning vid distribution av uppdaterad programvara till enheter.
• Ingen standardiserad automatiserad distribution mellan enheter.
• Begränsad flexibilitet vid val av teknik.

För att lösa dessa problem skapade utvecklingsteamet en lösning som:

• Minimerar storleken på distributionen till varje enhet, vilket minskar bandbredden.
• Implementerar en standardiserad Docker-containerdistribution från IoT Edge-plattformen till heterogena fjärr-IoT-enheter.
• Möjliggör tillförlitlig distributionsövervakning.
• Utnyttjar olika Azure DevOps- och molntjänster och använder kundens föredragna äldre verktyg.

Lösningen har avsevärt ökat tillförlitligheten och återhämtningsprocessen för enhetsetablering i miljöer med begränsad anslutning. I den här artikeln beskrivs lösningsinformationen och utvärderingsprocessen för lösningsalternativ.

Kundkrav

Kunden hade följande krav:

• Lösningen måste ha stöd för tillfälliga molnanslutningar med låg bandbredd.
• Distribuerade program måste fortsätta att köras lokalt.
• Lokal personal måste använda funktioner offline eller utan fördröjning av molnresor.
• När den är ansluten måste lösningen använda molnanslutningen effektivt.
• Lösningen måste prioritera att skicka data enligt konsekvent definierade affärsregler mellan produkter.

Det fanns också följande detaljerade krav:

• Bildfiler överförs via en satellitanslutning med låg bandbredd och tillfälliga anslutningar.
• Mängden data som överförs bör minimeras.
• Överföring av filer till enheter använder kundens föredragna program från tredje part.
• Enhetsarbetsbelastningar använder Docker-avbildningar i IoT Edge.
• Bildstorlekarna varierar från tiotals MB till flera GB.
• IoT Edge-moduler skrivs i .NET Core 2.2.

Potentiella användningsfall

Den här lösningen är lämplig för IoT-scenarier där programvarucontainrar levererar lösningar över låg bandbredd, tillfälliga anslutningar. Exempel:

• Fjärrövervakning av olja, gas och gruvdrift
• Trådlösa fordonsuppdateringar
• Någonstans där en stark anslutning inte garanteras

Arkitektur

I scenarier med hög bandbredd hämtar Azure IoT Edge avbildningar direkt från ett Internettillgängligt Docker-register, antingen en Docker-hubb eller en privat hubb som Azure Container Registry. Den här funktionen är densamma som när docker pull <image_name> kommandot körs.

Med potentiellt tillfällig nätverksåtkomst, till exempel en satellitanslutning till Internet, är Docker-pull-metoden otillförlitlig. Förloppet cachelagras inte om Internetanslutningen bryts medan Docker hämtar avbildningen. När Internetanslutningen återupptas måste Docker börja hämta avbildningen igen från början.

Lösningen använder en alternativ distributionsmekanism, binär korrigering av Docker-avbildningsfiler, för att minska bandbredden och kompensera för tillfälliga anslutningar.

Dataflöde

1. Utvecklare interagerar med edge-modulens källkod på en källkodslagringsplats.
2. Container Registry lagrar varje moduls Docker-avbildningar.
3. Manifestlagringsplatsen innehåller distributionsmanifesten för alla arbetsströmmar.
4. Varje modul har en Azure Pipelines-byggpipeline som använder en allmän Docker-version för att skapa och registrera moduler automatiskt.
5. Pipelinen image-to-device distribuerar Docker-avbildningarna till de målenheter som definieras av manifestfilen.
6. Pipelinen manifest-till-enhet skickar distributionsmanifestet till rätt Azure IoT Hub för den enhet som uppdateras.
7. En snabb filöverföringslösning från tredje part överför filerna från ett Azure Storage-konto till enheten.
8. IoT Edge-modulen Bildrekonstruktion tillämpar de mottagna korrigeringarna på enheterna.
9. IoT Hub tar emot statusmeddelanden från modulen Bildrekonstruktion och anger distributionsmanifestet för enheten. Resten av pipelineflödet använder det här distributionsmanifestet.
10. Azure Functions övervakar IoT Hub-meddelandeströmmen, uppdaterar SQL-databasen och meddelar användaren om framgång eller fel.
11. Azure SQL Database spårar förekomster på målenheterna och de Azure-baserade tjänsterna under och efter distributionen.

Komponenter

• Azure IoT Edge kör containerbaserade arbetsbelastningar på enheter, vilket ger anslutning med låg svarstid och sparar bandbredd.
• Azure IoT Hub är en hanterad molnbaserad tjänst som fungerar som en central meddelandehubb mellan IoT-program och de enheter som de styr.
• Azure Container Registry är en molnbaserad privat registertjänst som lagrar och hanterar privata Docker-containeravbildningar och relaterade artefakter.
• Azure Pipelines kombinerar kontinuerlig integrering (CI) och kontinuerlig leverans (CD) för att automatiskt testa och skapa kod och skicka den till alla mål.
• Azure Functions är en serverlös beräkningsplattform som möjliggör körning av händelseutlöst kod utan att behöva etablera eller hantera infrastruktur.
• Azure Storage tillhandahåller mycket skalbar, säker, högpresterande och kostnadseffektiv lagring för alla typer av affärsdata, objekt och filer.
• Azure SQL Database är en fullständigt hanterad relationsdatabastjänst med flera modeller som skapats för molnet.
• Docker är en öppen plattform för utveckling, leverans och körning av containerbaserade program.

Alternativ

Utvecklingsteamet utvärderade flera alternativ innan de bestämde sig för den fullständiga Docker-avbildningslösningen för deltaöverföring. I följande avsnitt beskrivs utvärderingsalternativ och resultat.

Teamet övervägde följande utvärderingskriterier för varje alternativ:

• Om lösningen uppfyllde kraven eller inte.
• Om en låg, medelhög eller hög mängd logik behövde implementeras på enheterna.
• Om en låg, medelhög eller hög mängd logik behövde implementeras i Azure.
• Bandbreddseffektivitet, eller förhållandet mellan överförda data och den totala storleken på en bild, för överföring av en containeravbildning.

Bandbreddseffektivitet inkluderade scenarier där:

• Det fanns inga bilder på enheten.
• Det fanns en avbildning med samma bas på enheten.
• Det fanns en bild av en tidigare programversion på enheten.
• En avbildning för programmet som bygger på en tidigare basavbildning fanns på enheten.

Teamet använde följande scenarier för att utvärdera bandbreddseffektiviteten:

Alternativet Överför Docker-lager

En Docker-containeravbildning är en UnionFS-montering av skrivskyddade filsystemskillnader, med ett annat skrivbart lager för ändringar som görs medan containern körs. Filsystemen kallas lager, som i princip är mappar och filer. Lagerstaplar som utgör basen för containerns rotfilsystem. Eftersom lagren är skrivskyddade kan olika bilder dela samma lager om de har lagret gemensamt.

Alternativet Överför Docker-lager återanvänder lagren mellan bilder och överför endast nya lager till enheten. Det här alternativet är mest användbart för bilder som delar samma basskikt, vanligtvis operativsystemet, eller för att uppdatera versioner av befintliga avbildningar.

Nackdelar med den här metoden är:

• Orkestratorn måste ha information om vilka lager som finns på vilka enheter.
• Ändringar i basskiktet gör att alla efterföljande lagers hashar ändras.
• Jämförelse kräver konsekventa lagershashvärden.
• Det kan finnas beroenden vid Docker-sparande och Docker-inläsning.

Ändra Docker-klientalternativet

Det här alternativet fokuserar på att ändra eller omsluta Docker-klienten så att lagerhämtningen återupptas efter ett avbrott. Som standard återupptar en Docker-hämtning en nedladdning om Internetanslutningen återställs inom cirka 30 minuter efter avbrottet. Annars avslutar klienten och förlorar alla nedladdningsstatusar.

Denna metod är livskraftig, men hade komplikationer, inklusive:

• Alla avbildningar på enheten måste registreras med Docker-daemonen som hämtar bilderna för att maximera bandbreddseffektiviteten.
• Docker-projektet med öppen källkod måste ändras för att stödja den här funktionen, vilket innebär en risk för avvisande av underhållare med öppen källkod.
• Överföring av data via HTTP i stället för kundens favoritlösning för snabb filöverföring skulle kräva utveckling av anpassad logik för återförsök.
• Alla lager måste överföras igen när en basavbildning ändras.

Alternativet Skapa på gränsenhet

Den här metoden flyttar avbildningsmiljön till enheterna. Följande data skickas till enheten:

• Källkoden för programmet som skapas
• En kopia av alla NuGet-paket som koden är beroende av
• Docker-basavbildningarna för .NET Core-byggmiljön och körningen
• Metadata om slutbilden

En byggagent på enheten skapar sedan avbildningen och registrerar den med dockerhanteraren för enheten.

Den här lösningen avvisades eftersom:

• Det skulle fortfarande behövas ett sätt att flytta stora Docker-avbildningar till enheterna. Avbildningar för att skapa .NET-program är större än själva appbilderna.
• Den här metoden fungerar bara för program där teamet har källkoden, så den kan inte använda avbildningar från tredje part.
• Alternativet kräver paketering av NuGet-paket och spårning av deras förflyttning till enheterna.
• Om en avbildning inte kunde byggas på enheten skulle teamet behöva fjärrfelsöka byggmiljön och den skapade avbildningen. Fjärrfelsökning skulle kräva hög användning av den potentiellt begränsade Internetanslutningen.

Alternativet Fullständig överföring av bilddelta

Den valda metoden behandlar en Docker-avbildning som en enda binär fil. Docker-kommandot exporterar save avbildningen som en .tar fil. Lösningen exporterar befintliga och nya Docker-avbildningar och beräknar det binära delta som när det används omvandlar den befintliga avbildningen till den nya.

Lösningen spårar befintliga Docker-avbildningar på enheterna och skapar binära deltakorrigeringar för att omvandla befintliga avbildningar till de nya avbildningarna. Systemet överför endast deltakorrigeringarna över internetanslutningen med låg bandbredd. Den här lösningen krävde viss anpassad logik för att skapa binära korrigeringar, men den skickade minst mängd data till enheter.

Utvärderingsresultat

Följande tabell visar hur var och en av ovanstående lösningar mättes mot utvärderingskriterierna.

Att tänka på

Dessa överväganden implementerar grundpelare i Azure Well-Architected Framework, en uppsättning vägledande grundsatser som förbättrar arbetsbelastningskvaliteten. Mer information finns i Microsoft Azure Well-Architected Framework.

Prestandaeffektivitet

Den här lösningen minskade avsevärt den bandbredd som förbrukades av uppdateringar av IoT-enheter. Följande tabeller visar en uppdelning av skillnaderna i överföringseffektivitet.

Image Reconstructor som källa:

Tidigare version som källa:

Driftsäkerhet

Följande avsnitt innehåller en detaljerad genomgång av lösningen.

Källkodslagringsplats

Utvecklare interagerar med edge-modulens källkod på en källkodslagringsplats. Lagringsplatsen består av mappar som innehåller koden för varje modul enligt följande:

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

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

Det rekommenderade antalet lagringsplatser för källkod är:

• En lagringsplats för alla moduler i alla arbetsströmmar.
• En källkodslagringsplats för varje arbetsström.

Container Registry-instanser

Container Registry lagrar varje moduls Docker-avbildningar. Det finns två möjliga konfigurationer för Container Registry:

• En enda Container Registry-instans som lagrar alla avbildningar.
• Två Container Registry-instanser, en för att lagra avbildningar för utveckling, testning och felsökning och en annan som endast innehåller avbildningar som markerats som produktionsklara.

Manifestlagringsplats

Manifestlagringsplatsen innehåller distributionsmanifesten för alla arbetsströmmar. Mallarna finns i mappar baserat på deras arbetsström. I det här exemplet är de två arbetsströmmarna delad infrastruktur och det containerbaserade programmet.

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

Docker-avbildningsgenereringspipeline

Varje modul har en Azure Pipelines-byggpipeline. Pipelinen använder en allmän Docker-version för att skapa och registrera moduler. Pipelinen ansvarar för:

• Säkerhetsgenomsökning av källkoden.
• Säkerhetsgenomsökning av basavbildningen för att skapa Docker-avbildningen.
• Köra enhetstester för modulen.
• Skapa källan till en Docker-avbildning. Avbildningstaggen BUILD_BUILDIDinnehåller , så att avbildningen alltid kan länkas tillbaka till källkoden som skapade den.
• Push-överför avbildningen till en Container Registry-instans.
• Skapa deltafilen.
• Skapa en signaturfil för avbildningen och spara filen på ett Azure-lagringskonto.

Alla pipelineinstanser baseras på en enda YAML-pipelinedefinition. Pipelinen kan fungera på modulerna med hjälp av miljövariabler. Filter utlöser endast varje pipeline när ändringar checkas in i en viss mapp. Det här filtret undviker att skapa alla moduler när endast en modul uppdateras.

Pipeline för avbildning till enhet

Pipelinen image-to-device distribuerar Docker-avbildningarna till de målenheter som definieras av en manifestfil. Distributionen startas manuellt när pipelinen utlöses.

Pipelinedefinitionen anger hur du kör dessa distributioner i en container. Pipelines stöder variabelindata för avbildningarna som ska bascontainrar på. En enskild variabel kan styra distributioner för alla pipelines.

Avbildningen innehåller koden som avgör vilka korrigeringar som ska skapas, skapar korrigeringarna och distribuerar dem till Azure-sidan av filöverföringsverktyget.

Avbildningsdistributionsverktyget behöver följande information:

• Vilka avbildningar som ska distribueras, som tillhandahålls av manifestet på lagringsplatsen.
• Vilka enheter som ska distribueras till, tillhandahålls av den användare som utlöser pipelinen.
• Vilka avbildningar som redan finns på målenheterna, som tillhandahålls av en Azure SQL-databas.

Pipelineutdata är:

• Korrigeringspaket som skickas till Azure-sidan av filöverföringsverktyget, som ska distribueras till enheterna.
• SQL-databasposter som markerar vilka bilder som har börjat överföras till varje enhet.
• SQL-databasposter för de nya distributionsuppsättningarna. Dessa poster inkluderar namnet och e-postadressen för den användare som beställde distributionen.

Den här pipelinen utför följande steg:

1. Avgör vilka avbildningar som behövs baserat på distributionsmanifestet.
2. Frågar SQL för att se vilka bilder som redan finns på enheterna. Om alla avbildningar redan finns avslutas pipelinen.
3. Avgör vilka korrigeringspaket som ska skapas. Algoritmen avgör vilken startbild som genererar det minsta korrigeringspaketet.
   • Indata: En .tar fil som innehåller den nya avbildningen som ska distribueras och signaturfiler för befintliga avbildningar på enheterna.
   • Utdata: En rangordning av befintliga bilder för att fastställa den minsta korrigering som ska skapas.
4. Skapar de korrigeringspaket som behövs för varje enhet. Skapar liknande korrigeringar en gång och kopierar dem till alla enheter som behöver dem.
5. Distribuerar korrigeringarna till filöverföringsverktygets lagringskonto för distribution.
6. Uppdaterar SQL för att markera de nya avbildningarna som in transit för var och en av målenheterna.
7. Lägger till information om distributionsuppsättningen i SQL, med namn och kontakt-e-post för den person som distribuerar avbildningen.

Manifest-till-enhet-pipeline

Pipelinen manifest-till-enhet skickar distributionsmanifestet till rätt IoT Hub-anslutning för enheten som uppdateras. En användare utlöser pipelinen manuellt och anger en miljövariabel för IoT Hub-instansen till målet.

Pipelinen:

• Avgör vilka avbildningar distributionen behöver.
• Frågar SQL för att se till att alla nödvändiga avbildningar finns på målenheterna. Annars avslutas pipelinen med status failed .
• Push-överför det nya distributionsmanifestet till rätt IoT Hub.

Snabb filöverföringslösning

Kunden ville fortsätta att använda sin snabbfilöverföringslösning från tredje part, kallad FileCatalyst, för att tillhandahålla anslutningen mellan Azure och deras IoT-enheter. Den här lösningen är ett så småningom konsekvent filöverföringsverktyg, vilket innebär att en överföring kan ta lång tid, men kommer så småningom att slutföras utan att någon filinformation förloras.

Lösningen använde ett Azure Storage-konto på Azure-sidan av anslutningen och kundens befintliga virtuella filöverföringsvärddator för varje enhet som tar emot avbildningar. Korrigeringen paket överför till en virtuell Linux-dator som kör IoT Hub.

Bildrekonstruktionsmodul

IoT Edge-modulen Bildrekonstruktion tillämpar de mottagna korrigeringarna på enheterna. Varje enhet är värd för sitt eget lokala containerregister med hjälp av Docker-registret med öppen källkod. Avbildningsrekonstruktionsprocessen körs på den virtuella värddatorn, vilket är samma som den virtuella filöverföringsdatorn.

Modulen:

1. Tar emot korrigeringspaketet i en mapp som är monterad på containern.
2. Packa upp korrigeringsinnehållet för att läsa konfigurationsfilen.
3. Hämtar basavbildningen från det lokala containerregistret med hash.
4. Sparar basavbildningen som en .tar fil.
5. Tillämpar korrigeringen på basavbildningen.
6. Läser in .tar-filen som innehåller den nya avbildningen till Docker.
7. Skickar den nya avbildningen till det lokala containerregistret med en konfigurationsfil med ett eget namn och en tagg.
8. Skickar ett meddelande till IoT Hub.

Om processen misslyckas vid något tillfälle skickar modulen ett felmeddelande till IoT Hub, så att användaren som utlöste distributionen kan meddelas.

IoT Hub

Flera av distributionsprocesserna använder IoT Hub. Förutom att ta emot statusmeddelanden från modulen Bildrekonstruktion anger IoT Hub distributionsmanifestet för enheten. Resten av pipelineflödet använder det här manifestet.

Azure Functions

Azure Functions övervakar meddelandeströmmen som kommer från IoT Hub och vidtar åtgärder i molnet.

För ett lyckat meddelande:

• Funktionen uppdaterar statusen för SQL-posten för avbildningen på enheten från in transit till succeeded.
• Om den här avbildningen är den sista som tas emot i en distributionsuppsättning:
  • Funktionen meddelar användaren om att distributionen lyckades.
  • Funktionen uppdaterar pipelinen manifest-till-enhet för att börja använda de nya avbildningarna.

För ett felmeddelande:

• Funktionen uppdaterar statusen för SQL-posten för avbildningen på enheten från in transit till failed.
• Funktionen meddelar användaren om avbildningsöverföringsfelet.

SQL Database

En SQL-databas spårar förekomster på målenheterna och de Azure-baserade distributionstjänsterna under och efter distributionen. Både Azure Functions och Azure Pipelines använder ett privat NuGet-paket som skapats för att interagera med databasen.

SQL Database lagrar följande data:

• Vilka bilder som finns på varje enhet.
• Vilka bilder som är på väg till varje enhet.
• Vilka avbildningar som distribueras tillhör en uppsättning.
• Användaren som beställde distributionerna.

Målet med det här exemplet var att se till att systemet genererade nödvändiga data för framtida datainstrumentpaneler. Att köra frågor mot IoT Hub kan ge följande data om pipelinen manifest-till-enhet:

• Tillståndet för en distribution.
• Bilderna på en viss enhet.
• De enheter som har en bild.
• Tidsseriedata om lyckade och misslyckade överföringar.
• Frågor om distributioner baserat på användare.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

• Kanio Dimitrov | Huvudansvarig programvaruutvecklingsledare

Nästa steg

• Distribuera din första IoT Edge-modul till en virtuell Linux-enhet
• Utveckla IoT Edge-moduler med Linux-containrar

Relaterade resurser

• Azure IoT-referensarkitektur
• Utforma en CI/CD-pipeline med Hjälp av Azure DevOps
• Nätverksanslutningar med låg fördröjning för industrin