Distribuzione efficiente delle immagini Docker per la connettività a larghezza di banda ridotta

Questo articolo descrive una soluzione per la distribuzione di moduli perimetrali IoT (Internet of Things) in contenitori tra connessioni Internet intermittenti o a larghezza di banda ridotta.

L'elaborazione perimetrale è un modello chiave di Internet delle cose (IoT) per fornire connettività a bassa latenza e conservare la larghezza di banda, ad esempio negli scenari per dispositivi mobili. I sistemi IoT in genere effettuano il provisioning dei dispositivi perimetrali distribuendo immagini del contenitore software. Le distribuzioni di contenitori interrotte su connessioni Internet intermittenti a bassa larghezza di banda possono causare errori negli scenari per dispositivi mobili. Gli scenari IoT con larghezza di banda limitata, intermittente o bassa richiedono funzionalità di distribuzione affidabili e resilienti.

In questo esempio, un'azienda di logistica di grandi dimensioni voleva migliorare la tracciabilità delle spedizioni di prodotti in tutto il mondo. L'azienda ha spedito merci con vari metodi di trasporto di terra, aria e mare a molte località, tra cui aree con connettività Internet intermittente e a larghezza di banda ridotta. A seconda del tipo di merci, le spedizioni di prodotti hanno installato diversi dispositivi di assicurazione, sicurezza o tracciamento IoT, con diverse funzionalità. I dispositivi includono tracker GPS, sensori di temperatura e strumenti di acquisizione dei dati.

L'azienda ha riscontrato problemi nell'aggiornamento dei dispositivi tramite la piattaforma Azure IoT Edge sviluppata di recente. I principali punti di dolore erano:

• Consumo elevato di larghezza di banda durante la distribuzione di software aggiornato nei dispositivi.
• Nessuna distribuzione automatizzata standardizzata tra dispositivi.
• Flessibilità limitata della selezione della tecnologia.

Per risolvere questi problemi, il team di sviluppo ha creato una soluzione che:

• Riduce al minimo le dimensioni della distribuzione in ogni dispositivo, riducendo la larghezza di banda.
• Implementa una distribuzione standardizzata di contenitori Docker dalla piattaforma IoT Edge a dispositivi IoT remoti eterogenei.
• Abilita il monitoraggio affidabile della distribuzione.
• Sfrutta i vari servizi cloud e Azure DevOps e usa gli strumenti legacy preferiti del cliente.

La soluzione aumenta notevolmente l'affidabilità e la resilienza del processo di provisioning dei dispositivi in ambienti con connettività limitata. Questo articolo descrive i dettagli della soluzione e il processo di valutazione delle opzioni della soluzione.

Requisiti dei clienti

Il cliente ha i requisiti seguenti:

• La soluzione deve supportare la connettività cloud intermittente a larghezza di banda ridotta.
• Le applicazioni distribuite devono continuare a essere eseguite in locale.
• Il personale locale deve usare la funzionalità offline o senza un ritardo di round trip nel cloud.
• Quando si è connessi, la soluzione deve usare la connessione cloud in modo efficiente.
• La soluzione deve classificare in ordine di priorità l'invio di dati in base alle regole business definite in modo coerente tra i prodotti.

Sono stati inoltre soddisfatti i requisiti dettagliati seguenti:

• I file di immagine vengono trasferiti attraverso una connessione satellite a bassa larghezza di banda e connettività intermittente.
• La quantità di dati trasferiti deve essere ridotta al minimo.
• Il trasferimento di file ai dispositivi usa l'applicazione di terze parti preferita del cliente.
• I carichi di lavoro dei dispositivi usano immagini Docker in IoT Edge.
• Le dimensioni delle immagini vanno da decine di MB a diversi GB.
• I moduli IoT Edge sono scritti in .NET Core 2.2.

Potenziali casi d'uso

Questa soluzione è adatta agli scenari IoT in cui i contenitori software offrono soluzioni su larghezza di banda ridotta, connessioni intermittenti. Alcuni esempi:

• Monitoraggio remoto di petrolio, gas e estrazione mineraria
• Aggiornamenti per il settore automobilistico in modalità wireless
• Ovunque non sia garantita una connessione forte

Architettura

Negli scenari a larghezza di banda elevata, Azure IoT Edge esegue il pull delle immagini direttamente da un registro Docker accessibile da Internet, un hub Docker o un hub privato come Registro Azure Container. Questa funzionalità equivale all'esecuzione del docker pull <image_name> comando .

Con accesso di rete potenzialmente intermittente, ad esempio una connessione Internet satellite, il metodo pull Docker non è affidabile. Lo stato di avanzamento non viene memorizzato nella cache se la connessione Internet si interrompe mentre Docker esegue il pull dell'immagine. Quando la connessione Internet riprende, Docker deve iniziare a eseguire di nuovo il pull dell'immagine dall'inizio.

La soluzione usa un meccanismo di distribuzione alternativo, l'applicazione di patch binarie dei file di immagine Docker, per ridurre la larghezza di banda e compensare la connettività intermittente.

Flusso di dati

1. Gli sviluppatori interagiscono con il codice sorgente del modulo Edge in un repository di codice sorgente.
2. Registro Container archivia le immagini Docker di ogni modulo.
3. Il repository di manifesti contiene i manifesti di distribuzione per tutte le sequenze di lavoro.
4. Ogni modulo ha una pipeline di compilazione di Azure Pipelines che usa una compilazione Docker generica per creare e registrare automaticamente i moduli.
5. La pipeline da immagine a dispositivo distribuisce le immagini Docker nei dispositivi di destinazione, come definito dal file manifesto.
6. La pipeline da manifesto a dispositivo esegue il push del manifesto della distribuzione nel hub IoT di Azure appropriato per il dispositivo da aggiornare.
7. Una soluzione di trasferimento rapido di file di terze parti trasferisce i file da un account Archiviazione di Azure al dispositivo.
8. Il modulo Image Reconstruction IoT Edge applica le patch ricevute nei dispositivi.
9. hub IoT riceve i messaggi di stato dal modulo Ricostruzione immagini e imposta il manifesto della distribuzione per il dispositivo. Il resto del flusso della pipeline usa questo manifesto della distribuzione.
10. Funzioni di Azure monitora il flusso di messaggi hub IoT, aggiorna il database SQL e notifica all'utente di esito positivo o negativo.
11. database SQL di Azure tiene traccia delle occorrenze nei dispositivi di destinazione e nei servizi basati su Azure, durante e dopo la distribuzione.

Componenti

• Azure IoT Edge esegue carichi di lavoro in contenitori nei dispositivi, offrendo connettività a bassa latenza e larghezza di banda.
• hub IoT di Azure è un servizio gestito ospitato nel cloud che funge da hub messaggi centrale tra le applicazioni IoT e i dispositivi che controllano.
• Registro Azure Container è un servizio del Registro di sistema privato basato sul cloud per archiviare e gestire immagini di contenitori Docker private e artefatti correlati.
• Azure Pipelines combina l'integrazione continua (CI) e il recapito continuo (CD) per testare e compilare automaticamente il codice e spedirlo a qualsiasi destinazione.
• Funzioni di Azure è una piattaforma di calcolo serverless che consente l'esecuzione di codice attivato da eventi senza dover effettuare il provisioning o gestire l'infrastruttura.
• Archiviazione di Azure offre un'archiviazione altamente scalabile, sicura, efficiente e conveniente per tutti i tipi di dati, oggetti e file aziendali.
• database SQL di Azure è un servizio di database relazionale completamente gestito e multimodello creato per il cloud.
• Docker è una piattaforma aperta per lo sviluppo, la spedizione e l'esecuzione di applicazioni in contenitori.

Alternative

Il team di sviluppo ha valutato diverse opzioni prima di decidere la soluzione completa di trasferimento differenziale delle immagini Docker. Le sezioni seguenti descrivono le alternative di valutazione e i risultati.

Il team ha considerato i criteri di valutazione seguenti per ogni opzione:

• Indica se la soluzione soddisfa o meno i requisiti.
• Che sia necessario implementare una quantità di logica bassa, media o elevata nei dispositivi.
• Che sia necessario implementare una quantità di logica bassa, media o elevata in Azure.
• Efficienza della larghezza di banda o rapporto tra i dati trasferiti e le dimensioni totali di un'immagine per il trasferimento di un'immagine del contenitore.

L'efficienza della larghezza di banda include scenari in cui:

• Nessuna immagine esistente nel dispositivo.
• Nel dispositivo è presente un'immagine con la stessa base.
• Immagine di una versione precedente dell'applicazione presente nel dispositivo.
• Nel dispositivo esiste un'immagine per l'applicazione basata su un'immagine di base precedente.

Il team ha usato gli scenari seguenti per valutare l'efficienza della larghezza di banda:

Opzione Trasferisci livelli Docker

Un'immagine del contenitore Docker è un montaggio UnionFS di differenze di file system di sola lettura, con un altro livello scrivibile per le modifiche apportate durante l'esecuzione del contenitore. I file system sono denominati livelli, che sono fondamentalmente cartelle e file. Stack di livelli per formare la base del file system radice del contenitore. Poiché i livelli sono di sola lettura, varie immagini possono condividere lo stesso livello se hanno il livello in comune.

L'opzione Trasferisci livelli Docker riutilizza i livelli tra le immagini e trasferisce solo nuovi livelli al dispositivo. Questa opzione sarebbe più utile per le immagini che condividono lo stesso livello di base, in genere il sistema operativo o per l'aggiornamento delle versioni delle immagini esistenti.

Gli svantaggi di questo metodo includono:

• L'agente di orchestrazione deve mantenere informazioni su quali livelli esistono nei dispositivi.
• Le modifiche apportate al livello di base implicano la modifica degli hash di tutti i livelli successivi.
• Il confronto richiede hash di livello coerenti.
• Potrebbero esserci dipendenze dal salvataggio docker e dal caricamento di Docker.

Modificare l'opzione del client Docker

Questa opzione è incentrata sulla modifica o il wrapping del client Docker in modo da riprendere il download del livello dopo un'interruzione. Per impostazione predefinita, un pull Docker riprende un download se la connessione Internet viene ripristinata entro circa 30 minuti dall'interruzione. In caso contrario, il client viene chiuso e perde tutto lo stato di avanzamento del download.

Questo metodo è fattibile, ma ha avuto complicazioni, tra cui:

• Tutte le immagini nel dispositivo devono essere registrate con il daemon Docker che esegue il pull delle immagini per ottimizzare l'efficienza della larghezza di banda.
• Il progetto Docker open source deve essere modificato per supportare questa funzionalità, presentando un rischio di rifiuto da parte dei gestori open source.
• Il trasferimento dei dati tramite HTTP anziché la soluzione di trasferimento rapido dei file preferito del cliente richiederebbe lo sviluppo di logica di ripetizione dei tentativi personalizzata.
• Tutti i livelli devono essere ritrasmessi quando viene modificata un'immagine di base.

Opzione Build on edge device (Compilazione nel dispositivo perimetrale)

Questo approccio sposta l'ambiente di compilazione delle immagini nei dispositivi. I dati seguenti vengono inviati al dispositivo:

• Codice sorgente per l'applicazione da compilare
• Una copia di tutti i pacchetti NuGet da cui dipende il codice
• Immagini di base Docker per l'ambiente di compilazione e il runtime di .NET Core
• Metadati sull'immagine finale

Un agente di compilazione nel dispositivo compila quindi l'immagine e la registra con Il dispositivo Docker Manager.

Questa soluzione è stata rifiutata per i motivi seguenti:

• Sarebbe comunque necessario spostare immagini Docker di grandi dimensioni nei dispositivi. Le immagini per la compilazione di applicazioni .NET sono più grandi delle immagini dell'app stesse.
• Questo metodo funziona solo per le applicazioni in cui il team ha il codice sorgente, quindi non può usare immagini di terze parti.
• L'opzione richiede la creazione di pacchetti NuGet e il rilevamento dello spostamento nei dispositivi.
• Se non è stato possibile compilare un'immagine nel dispositivo, il team dovrà eseguire il debug remoto dell'ambiente di compilazione e dell'immagine creata. Il debug remoto richiederebbe un utilizzo elevato della connessione Internet potenzialmente limitata.

Opzione di trasferimento differenziale immagine completa

L'approccio scelto considera un'immagine Docker come un singolo file binario. Il comando Docker save esporta l'immagine come file .tar . La soluzione esporta le immagini Docker esistenti e nuove e calcola il delta binario che, quando applicato, trasforma l'immagine esistente in quella nuova.

La soluzione tiene traccia delle immagini Docker esistenti nei dispositivi e compila patch differenziali binarie per trasformare le immagini esistenti nelle nuove immagini. Il sistema trasferisce solo le patch differenziali attraverso la connessione Internet a larghezza di banda ridotta. Questa soluzione richiedeva una logica personalizzata per compilare le patch binarie, ma inviava la quantità minima di dati ai dispositivi.

Valutazione dei risultati

Nella tabella seguente viene illustrato il modo in cui ognuna delle soluzioni precedenti è misurata in base ai criteri di valutazione.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, un set di principi guida che migliorano la qualità del carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Efficienza prestazionale

Questa soluzione riduce notevolmente la larghezza di banda usata dagli aggiornamenti ai dispositivi IoT. Le tabelle seguenti mostrano una suddivisione delle differenze nell'efficienza del trasferimento.

Image Reconstructor come origine:

Versione precedente come origine:

Eccellenza operativa

Le sezioni seguenti forniscono una procedura dettagliata della soluzione.

Repository del codice sorgente

Gli sviluppatori interagiscono con il codice sorgente del modulo Edge in un repository di codice sorgente. Il repository è costituito da cartelle che contengono il codice per ogni modulo, come indicato di seguito:

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

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

Il numero consigliato di repository di codice sorgente è:

• Un repository per tutti i moduli in tutti i flussi di lavoro.
• Un repository del codice sorgente per ogni sequenza di lavoro.

Istanze di Registro Container

Registro Container archivia le immagini Docker di ogni modulo. Esistono due possibili configurazioni per Registro Container:

• Una singola istanza del Registro Container che archivia tutte le immagini.
• Due istanze del Registro Container, una per archiviare le immagini di sviluppo, test e debug e un'altra che contiene solo immagini contrassegnate come pronte per la produzione.

Repository di manifesti

Il repository di manifesti contiene i manifesti di distribuzione per tutte le sequenze di lavoro. I modelli si trovano in cartelle basate sul flusso di lavoro. In questo esempio i due flussi di lavoro sono un'infrastruttura condivisa e l'applicazione in contenitori.

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

Pipeline di compilazione di immagini Docker

Ogni modulo ha una pipeline di compilazione di Azure Pipelines. La pipeline usa una compilazione Docker generica per creare e registrare moduli. La pipeline è responsabile di:

• Analisi di sicurezza del codice sorgente.
• Analisi di sicurezza dell'immagine di base per la compilazione dell'immagine Docker.
• Esecuzione degli unit test per il modulo.
• Compilazione del codice sorgente in un'immagine Docker. Il tag immagine contiene , BUILD_BUILDIDin modo che l'immagine possa essere sempre collegata al codice sorgente che lo ha reso.
• Push dell'immagine in un'istanza del Registro Container.
• Creazione del file differenziale.
• Creazione di un file di firma per l'immagine e salvataggio del file in un account di archiviazione di Azure.

Tutte le istanze della pipeline si basano su una singola definizione di pipeline YAML. La pipeline può agire sui moduli usando le variabili di ambiente. I filtri attivano ogni pipeline solo quando viene eseguito il commit delle modifiche in una determinata cartella. Questo filtro evita la compilazione di tutti i moduli quando viene aggiornato un solo modulo.

Pipeline da immagine a dispositivo

La pipeline da immagine a dispositivo distribuisce le immagini Docker nei dispositivi di destinazione, come definito da un file manifesto. L'attivazione manuale della pipeline avvia la distribuzione.

La definizione della pipeline specifica l'esecuzione di queste distribuzioni in un contenitore. Le pipeline supportano l'input della variabile per le immagini su cui basare i contenitori. Una singola variabile può controllare le distribuzioni per tutte le pipeline.

L'immagine contiene il codice che determina le patch da compilare, compila le patch e le distribuisce sul lato Azure dello strumento di trasferimento file.

Lo strumento di distribuzione delle immagini necessita delle informazioni seguenti:

• Quali immagini distribuire, fornite dal manifesto nel repository.
• In quali dispositivi eseguire la distribuzione, forniti dall'utente che attiva la pipeline.
• Quali immagini sono già presenti nei dispositivi di destinazione, forniti da un database SQL di Azure.

Gli output della pipeline sono:

• Bundle di patch inviati al lato Azure dello strumento di trasferimento file, da distribuire ai dispositivi.
• Voci del database SQL che contrassegnano le immagini che hanno avviato il trasferimento a ogni dispositivo.
• Voci di database SQL per i nuovi set di distribuzione. Queste voci includono il nome e l'indirizzo di posta elettronica dell'utente che ha ordinato la distribuzione.

Questa pipeline esegue i passaggi seguenti:

1. Determina le immagini necessarie, in base al manifesto della distribuzione.
2. Esegue query su SQL per vedere quali immagini sono già presenti nei dispositivi. Se tutte le immagini sono già presenti, la pipeline termina correttamente.
3. Determina quali bundle di patch creare. L'algoritmo determina l'immagine iniziale che genera il bundle di patch più piccolo.
   • Input: un file .tar contenente la nuova immagine da distribuire e i file di firma per le immagini esistenti nei dispositivi.
   • Output: classificazione delle immagini esistenti per determinare la patch più piccola da creare.
4. Crea i bundle di patch necessari per ogni dispositivo. Crea patch simili una sola volta e le copia in tutti i dispositivi che ne hanno bisogno.
5. Distribuisce le patch all'account di archiviazione dello strumento di trasferimento file per la distribuzione.
6. Aggiorna SQL per contrassegnare le nuove immagini in in transit ognuno dei dispositivi di destinazione.
7. Aggiunge le informazioni del set di distribuzione a SQL, con il nome e il messaggio di posta elettronica di contatto per la persona che distribuisce l'immagine.

Pipeline da manifesto a dispositivo

La pipeline da manifesto a dispositivo esegue il push del manifesto della distribuzione nella connessione hub IoT appropriata per il dispositivo da aggiornare. Un utente attiva manualmente la pipeline e specifica una variabile di ambiente per l'istanza di hub IoT di destinazione.

La pipeline:

• Determina le immagini necessarie per la distribuzione.
• Esegue query su SQL per assicurarsi che le immagini necessarie siano tutte presenti nei dispositivi di destinazione. In caso contrario, la pipeline termina con uno failed stato .
• Esegue il push del nuovo manifesto della distribuzione nel hub IoT appropriato.

Soluzione di trasferimento rapido dei file

Il cliente voleva continuare a usare la soluzione di trasferimento rapido dei file di terze parti, denominata FileCatalyst, per fornire la connessione tra Azure e i propri dispositivi IoT. Questa soluzione è uno strumento di trasferimento file coerente alla fine, il che significa che un trasferimento può richiedere molto tempo, ma alla fine verrà completato senza perdere alcuna informazione sul file.

La soluzione ha usato un account Archiviazione di Azure sul lato Azure della connessione e la macchina virtuale host di trasferimento file esistente del cliente per ogni dispositivo che riceve immagini. I bundle di patch vengono trasferiti in una macchina virtuale Linux che esegue hub IoT.

Modulo Ricostruzione immagini

Il modulo Image Reconstruction IoT Edge applica le patch ricevute nei dispositivi. Ogni dispositivo ospita il proprio registro contenitori locale usando il registro open source Docker. Il processo di ricostruzione dell'immagine viene eseguito nella macchina virtuale host, che corrisponde alla macchina virtuale di trasferimento file.

Il modulo:

1. Riceve il bundle di patch in una cartella montata nel contenitore.
2. Decomprime il contenuto della patch per leggere il file di configurazione.
3. Esegue il pull dell'immagine di base dal registro contenitori locale tramite hash.
4. Salva l'immagine di base come file .tar .
5. Applica la patch all'immagine di base.
6. Carica il file .tar contenente la nuova immagine in Docker.
7. Esegue il push della nuova immagine nel registro contenitori locale, con un file di configurazione che include un nome descrittivo e un tag.
8. Invia un messaggio di operazione riuscita a hub IoT.

Se il processo ha esito negativo in qualsiasi momento, il modulo invia un messaggio di errore a hub IoT, in modo che l'utente che ha attivato la distribuzione possa ricevere una notifica.

Hub IoT

Diversi processi di distribuzione usano hub IoT. Oltre a ricevere messaggi di stato dal modulo Ricostruzione immagini, hub IoT imposta il manifesto della distribuzione per il dispositivo. Il resto del flusso della pipeline usa questo manifesto.

Funzioni di Azure

Funzioni di Azure monitora il flusso di messaggi proveniente da hub IoT e agisce nel cloud.

Per un messaggio di operazione riuscita:

• La funzione aggiorna lo stato della voce SQL per l'immagine nel dispositivo da in transit a succeeded.
• Se questa immagine è l'ultima per arrivare in un set di distribuzione:
  • La funzione invia una notifica all'utente dell'esito positivo della distribuzione.
  • La funzione aggiorna la pipeline da manifesto a dispositivo per iniziare a usare le nuove immagini.

Per un messaggio di errore:

• La funzione aggiorna lo stato della voce SQL per l'immagine nel dispositivo da in transit a failed.
• La funzione notifica all'utente dell'errore di trasferimento dell'immagine.

Database SQL

Un database SQL tiene traccia delle occorrenze nei dispositivi di destinazione e nei servizi di distribuzione basati su Azure durante e dopo la distribuzione. Funzioni di Azure e Azure Pipelines usano entrambi un pacchetto NuGet privato creato per interagire con il database.

database SQL archivia i dati seguenti:

• Quali immagini si trovano in ogni dispositivo.
• Quali immagini sono in viaggio per ogni dispositivo.
• Le immagini distribuite appartengono a un set.
• Utente che ha ordinato le distribuzioni.

L'obiettivo di questo esempio era assicurarsi che il sistema abbia generato i dati necessari per i dashboard dei dati futuri. L'esecuzione di query hub IoT può fornire i dati seguenti sulla pipeline da manifesto a dispositivo:

• Stato di una distribuzione.
• Immagini in un determinato dispositivo.
• Dispositivi per cui esiste un'immagine.
• Dati della serie temporale relativi a trasferimenti riusciti e non riusciti.
• Query delle distribuzioni in base all'utente.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Kanio Dimitrov | Principal Software Engineering Lead

Passaggi successivi

• Distribuire il primo modulo IoT Edge in un dispositivo Linux virtuale
• Sviluppare moduli IoT Edge con contenitori Linux

Risorse correlate

• Architettura di riferimento di Azure IoT
• Progettare una pipeline CI/CD con Azure DevOps
• Connessioni di rete a bassa latenza per l'industria