Preparare la distribuzione della soluzione IoT Edge alla produzione

Si applica a: IoT Edge 1.5 IoT Edge 1.4

Una volta pronti a portare la soluzione IoT Edge dallo sviluppo alla produzione, assicurarsi che sia configurata per prestazioni costanti.

Le informazioni fornite in questo articolo non sono tutte uguali. Per assicurarsi di definire le priorità, ogni sezione inizia con elenchi che dividono il lavoro in due sezioni: importante da completare prima di passare all'ambiente di produzione, o utile da sapere.

Configurazione dispositivo

I dispositivi IoT Edge possono essere qualsiasi cosa, da un dispositivo Raspberry Pi a un computer portatile, a una macchina virtuale in esecuzione in un server. È possibile accedere al dispositivo fisicamente o tramite una connessione virtuale, oppure può essere isolato per lunghi periodi di tempo. In entrambi i casi, è bene assicurarsi che sia configurato per funzionare in modo appropriato.

• Importante

  • Installare i certificati di produzione
  • Disporre di un piano di gestione dei dispositivi
  • Usare Moby come motore del contenitore. Se si usano pacchetti snap di Ubuntu Core, lo snap di Docker è gestito da Canonical ed è supportato per gli scenari di produzione.

• Utile

  • Scegliere il protocollo di upstream

Installare i certificati di produzione

Ogni dispositivo IoT Edge nell'ambiente di produzione richiede un certificato di autorità di certificazione (CA) del dispositivo installato. Tale certificato della CA viene quindi dichiarato per il runtime IoT Edge nel file di configurazione. Per scenari di sviluppo e test, il runtime IoT Edge consente di creare certificati temporanei se non sono presenti certificati dichiarati nel file di configurazione. Tuttavia, questi certificati temporanei scadono dopo tre mesi e non sono sicuri per gli scenari di produzione. Per gli scenari di produzione, è necessario fornire il proprio certificato della CA di Edge, da un'autorità di certificazione autofirmata o acquistato da un'autorità di certificazione commerciale.

Per comprendere il ruolo del certificato della CA di Edge, vedere Come Azure IoT Edge usa i certificati.

Per altre informazioni su come installare i certificati su un dispositivo IoT Edge e farvi riferimento dal file di configurazione, vedere Gestire un certificato su un dispositivo IoT Edge.

Disporre di un piano di gestione dei dispositivi

Prima di rendere disponibili tutti i dispositivi nell'ambiente di produzione è necessario sapere come si intende gestire gli aggiornamenti futuri. Per un dispositivo IoT Edge, l'elenco dei componenti da aggiornare può includere:

• Il firmware del dispositivo
• Le librerie del sistema operativo
• Motore del contenitore, ad esempio Moby
• IoT Edge
• Certificati CA

Aggiornamento dispositivi per hub IoT è un servizio che consente di distribuire aggiornamenti over-the-air (OTA) ai dispositivi IoT Edge.

I metodi alternativi per aggiornare IoT Edge richiedono l'accesso SSH o fisico al dispositivo IoT Edge. Per altre informazioni, vedere Aggiornare il runtime IoT Edge. Per aggiornare molti dispositivi, è consigliabile aggiungere i passaggi per l'aggiornamento a uno script o usare uno strumento di automazione come Ansible.

Motore del contenitore

Disporre di un motore del contenitore è un prerequisito per qualsiasi dispositivo IoT Edge. Il motore moby è supportato nell'ambiente di produzione. Se si usano pacchetti snap di Ubuntu Core, lo snap di Docker è gestito da Canonical ed è supportato per gli scenari di produzione. Gli altri motori del contenitore, come Docker, funzionano con IoT Edge ed è comunque possibile usare questi motori per lo sviluppo. Il motore moby può essere ridistribuito quando usato con Azure IoT Edge e Microsoft fornisce assistenza per questo motore.

Scegliere il protocollo di upstream

È possibile configurare il protocollo (che determina la porta usata) per le comunicazioni upstream all'hub IoT per l'agente IoT Edge e l'hub di IoT Edge. Il protocollo predefinito è AMQP, ma è possibile modificarlo a seconda della configurazione di rete.

I due moduli runtime hanno una variabile di ambiente UpstreamProtocol. I valori validi per la variabile sono:

• MQTT
• AMQP
• MQTTWS
• AMQPWS

Configurare la variabile UpstreamProtocol per l'agente IoT Edge nel file di configurazione nel dispositivo stesso. Ad esempio, se il dispositivo IoT Edge si trova dietro un server proxy che blocca le porte AMQP, potrebbe essere necessario configurare l'agente di IoT Edge per usare AMQP su WebSocket (AMQPWS) per stabilire la connessione iniziale all'hub IoT.

Una volta che il dispositivo IoT Edge si connette, assicurarsi di continuare a configurare la variabile UpstreamProtocol per entrambi i moduli runtime nelle distribuzioni future. È possibile trovare un esempio di questo processo in Configurare un dispositivo IoT Edge per comunicare tramite un server proxy.

Distribuzione

• Utile
  • Essere coerenti con il protocollo upstream
  • Configurare l'archiviazione host per i moduli di sistema
  • Ridurre lo spazio di memoria usato dall'hub di IoT Edge
  • Usare le immagini del modulo corrette nei manifesti di distribuzione
  • Tenere presente i limiti relativi alle dimensioni dei dispositivi gemelli quando si usano moduli personalizzati
  • Configurare la modalità di applicazione degli aggiornamenti ai moduli

Essere coerenti con il protocollo upstream

Se l'agente di IoT Edge nel dispositivo IoT Edge è stato configurato per usare un protocollo diverso rispetto al valore AMQP predefinito, è necessario dichiarare lo stesso protocollo in tutte le distribuzioni future. Ad esempio, se il dispositivo IoT Edge si trova dietro un server proxy che blocca le porte AMQP,è probabile che il dispositivo sia stato configurato per connettersi tramite AMQP su WebSocket (AMQPWS). Quando si distribuiscono i moduli nel dispositivo, configurare lo stesso protocollo APQPWS per l'agente IoT Edge e l'hub di IoT Edge, altrimenti il valore predefinito AMQP sovrascriverà le impostazioni e impedirà di connettersi nuovamente.

È necessario configurare solo la variabile di ambiente UpstreamProtocol per i moduli dell'agente di IoT Edge e dell'hub di IoT Edge. Tutti i moduli aggiuntivi adottano qualsiasi protocollo impostato nei moduli del runtime.

È possibile trovare un esempio di questo processo in Configurare un dispositivo IoT Edge per comunicare tramite un server proxy.

Configurare l'archiviazione host per i moduli di sistema

I moduli dell'hub e dell'agente di IoT Edge usano l'archiviazione locale per mantenere lo stato e abilitare la messaggistica tra moduli, dispositivi e cloud. Per migliorare l'affidabilità e le prestazioni, configurare i moduli di sistema per usare l'archiviazione nel file system host.

Per altre informazioni, vedere Archiviazione host per i moduli di sistema.

Ridurre lo spazio di memoria usato dall'hub di Iot Edge

Se si distribuiscono dispositivi vincolati con memoria limitata, è possibile configurare l'hub di IoT Edge in modo che venga eseguito in una capacità più semplificata e che usi meno spazio su disco. Tuttavia, queste configurazioni limitano le prestazioni dell'hub di IoT Edge, quindi occorre trovare il giusto equilibrio adatto per la soluzione specifica.

Non ottimizzare le prestazioni su dispositivi vincolati

L'hub di IoT Edge è ottimizzato in termini di prestazioni per impostazione predefinita, perciò tenta di allocare blocchi di memoria di grandi dimensioni. Questa configurazione può causare problemi di stabilità in dispositivi più piccoli come Raspberry Pi. Se si distribuiscono dispositivi con risorse limitate, è consigliabile impostare la variabile di ambiente OptimizeForPerformance su false nell'hub di IoT Edge.

Quando OptimizeForPerformance è impostato su true, l'intestazione del protocollo MQTT usa PooledByteBufferAllocator, che offre prestazioni migliori ma alloca più memoria. L'allocatore non funziona bene nei sistemi operativi a 32 bit o nei dispositivi con memoria insufficiente. Inoltre, quando ottimizzato per le prestazioni, RocksDb alloca più memoria per il suo ruolo come provider di archiviazione locale.

Per altre informazioni, vedere Problemi di stabilità nei dispositivi di dimensioni inferiori.

Disabilitare i protocolli non usati

Un altro modo per ottimizzare le prestazioni dell'hub di IoT Edge e ridurre l'utilizzo della memoria consiste nel disattivare gli head di protocollo per tutti i protocolli in cui non si usa la soluzione.

Gli head di protocollo vengono configurati impostando le variabili di ambiente booleane per il modulo dell'hub di IoT Edge nei manifesti di distribuzione. Le tre variabili sono:

• amqpSettings__enabled
• mqttSettings__enabled
• httpSettings__enabled

Tutte le tre variabili hanno due caratteri di sottolineatura e possono essere impostate su true o false.

Ridurre il tempo di archiviazione per i messaggi

Il modulo hub di IoT Edge memorizza temporaneamente i messaggi che per qualsiasi motivo non possono essere consegnati all'hub IoT. È possibile configurare il tempo di permanenza dell'hub di IoT Edge sui messaggi non consegnati prima di lasciarli scadere. In caso di problemi di memoria sul dispositivo, è possibile abbassare il valore timeToLiveSecs nel modulo gemello dell'hub di IoT Edge.

Il valore predefinito del parametro timeToLiveSecs è 7200 secondi, che equivale a due ore.

Usare le immagini del modulo corrette nei manifesti di distribuzione

Se viene usata un'immagine di modulo vuota o errata, l'agente Edge ritenta il caricamento dell'immagine, causando la generazione di traffico aggiuntivo. Aggiungere le immagini corrette al manifesto della distribuzione per evitare di generare traffico non necessario.

Non usare le versioni di debug delle immagini del modulo

Quando si passa da scenari di test a scenari di produzione, ricordarsi di rimuovere le configurazioni di debug dai manifesti di distribuzione. Verificare che nessuna delle immagini dei moduli nei manifesti della distribuzione abbia il suffisso .debug. Se sono state aggiunte opzioni di creazione per esporre le porte nei moduli per il debug, rimuovere anche queste opzioni di creazione.

Tenere presente i limiti relativi alle dimensioni dei dispositivi gemelli quando si usano moduli personalizzati

Il manifesto della distribuzione che contiene moduli personalizzati fa parte del gemello EdgeAgent. Esaminare la limitazione delle dimensioni del modulo gemello.

Se si distribuisce un numero elevato di moduli, è possibile esaurire questo limite di dimensioni dei dispositivi gemelli. Considerare alcune mitigazioni comuni per questo limite rigido:

• Archiviare qualsiasi configurazione nel modulo gemello personalizzato, che ha un limite specifico.
• Archiviare alcune configurazioni che puntano a una posizione non limitata a spazi, ovvero a un archivio BLOB.

Configurare la modalità di applicazione degli aggiornamenti ai moduli

Quando una distribuzione viene aggiornata, Edge Agent riceve la nuova configurazione come aggiornamento del gemello. Se la nuova configurazione include immagini di modulo nuove o aggiornate, per impostazione predefinita Edge Agent elabora in sequenza ogni modulo:

1. L'immagine aggiornata viene scaricata
2. Il modulo in esecuzione viene arrestato
3. Viene avviata una nuova istanza del modulo
4. L'aggiornamento del modulo successivo viene elaborato

In alcuni casi, ad esempio quando esistono dipendenze tra i moduli, potrebbe essere preferibile scaricare prima di tutto le immagini del modulo aggiornate prima di riavviare i moduli in esecuzione. Questo comportamento di aggiornamento del modulo può essere configurato impostando una variabile di ambiente dell'agente IoT Edge ModuleUpdateMode sul valore stringa WaitForAllPulls. Per altre informazioni, vedere Variabili di ambiente di IoT Edge.

"modulesContent": {
    "$edgeAgent": {
        "properties.desired": {
            ...
            "systemModules": {
                "edgeAgent": {
                    "env": {
                        "ModuleUpdateMode": {
                            "value": "WaitForAllPulls"
                        }
                    ...

Gestione contenitori

• Importante
  • Usare tag per gestire le versioni
  • Gestire i volumi
• Utile
  • Archiviare i contenitori di runtime nel registro privato
  • Configurare la GC delle immagini

Usare tag per gestire le versioni

Un tag è un concetto di docker che è possibile usare per distinguere tra le versioni dei contenitori docker. I tag sono suffissi come 1.5 che vanno alla fine di un repository del contenitore. Ad esempio, mcr.microsoft.com/azureiotedge-agent:1.5. I tag sono modificabili e possono essere modificati in modo da puntare a un altro contenitore in qualsiasi momento, in modo che il team debba concordare una convenzione da seguire quando si aggiornano le immagini del modulo.

I tag consentono inoltre di applicare gli aggiornamenti sui dispositivi IoT Edge. Quando si esegue il push di una versione aggiornata di un modulo nel registro contenitori, incrementare il tag. Eseguire quindi il push di una nuova distribuzione per i dispositivi con il tag incrementato. Il motore contenitore riconosce il tag incrementato come una nuova versione ed esegue il pull della versione più recente del modulo nel dispositivo.

Tag per il runtime IoT Edge

Le immagini dell'agente IoT Edge e dell'hub di IoT Edge vengono contrassegnate con la versione di IoT Edge a cui sono associate. Esistono due diversi modi per usare i tag con le immagini di runtime:

• Tag di versioni. Vengono usati solo i primi due valori del numero di versione per ottenere l'immagine più recente corrispondente a tali cifre. Ad esempio, il tag 1.5 viene aggiornato ogni volta che è disponibile una nuova versione in modo da puntare alla versione 1.5.x più recente. Se il runtime del contenitore nel dispositivo IoT Edge esegue nuovamente il pull dell'immagine, i moduli del runtime vengono aggiornati alla versione più recente. Nelle distribuzioni dal portale di Azure vengono usati i tag di versioni per impostazione predefinita. Questo approccio è consigliato per finalità di sviluppo.

• Tag specifici. Vengono usati tutti e tre i valori del numero di versione per impostare in modo esplicito la versione dell'immagine. Ad esempio, il tag 1.5.0 non verrà modificato dopo il rilascio iniziale. Quando si è pronti per l'aggiornamento, è possibile dichiarare un nuovo numero di versione nel manifesto della distribuzione. Questo approccio è consigliato per finalità di produzione.

Gestire i volumi

IoT Edge non rimuove i volumi collegati ai contenitori del modulo. Questo comportamento è previsto da progettazione, perché consente di rendere persistenti i dati tra istanze del contenitore, ad esempio gli scenari di aggiornamento. Tuttavia, se questi volumi vengono lasciati inutilizzati, ciò può causare l'esaurimento dello spazio su disco e conseguenti errori di sistema. Se si usano volumi Docker nello scenario, è consigliabile usare gli strumenti Docker, come docker volume prune e docker volume rm per rimuovere i volumi inutilizzati, in particolare per gli scenari di produzione.

Archiviare i contenitori di runtime nel registro privato

Si è appreso come archiviare le immagini del contenitore per i moduli di codice personalizzati nel registro di Azure privato, ma è anche possibile usarlo per archiviare immagini di contenitori pubbliche, ad esempio moduli di runtime edgeAgent e edgeHub. Questa operazione può essere necessaria se sono presenti restrizioni del firewall rigorose perché questi contenitori di runtime vengono archiviati nel Registro Container Microsoft (MCR).

I passaggi seguenti illustrano come eseguire il pull di un'immagine Docker di edgeAgent e edgeHub nel computer locale, eseguirne il retagging, eseguirne il push nel registro privato, quindi aggiornare il file di configurazione in modo che i dispositivi sappiano eseguire il pull dell'immagine dal registro privato.

1. Eseguire il pull dell'immagine Docker edgeAgent dal Registro di sistema Microsoft. Aggiornare il numero di versione, se necessario.

   # Pull edgeAgent image
   docker pull mcr.microsoft.com/azureiotedge-agent:1.5
   
   # Pull edgeHub image
   docker pull mcr.microsoft.com/azureiotedge-hub:1.5
   

2. Elencare tutte le immagini Docker, trovare le immagini edgeAgent e edgeHub, quindi copiare gli ID immagine.

   docker images
   

3. Eseguire il retagging delle immagini edgeAgent e edgeHub. Sostituire i valori tra parentesi con i propri valori.

   # Retag your edgeAgent image
   docker tag <my-image-id> <registry-name/server>/azureiotedge-agent:1.5
   
   # Retag your edgeHub image
   docker tag <my-image-id> <registry-name/server>/azureiotedge-hub:1.5
   

4. Eseguire il push delle immagini edgeAgent e edgeHub nel registro privato. Sostituire il valore tra parentesi con il proprio valore.

   # Push your edgeAgent image to your private registry
   docker push <registry-name/server>/azureiotedge-agent:1.5
   
   # Push your edgeHub image to your private registry
   docker push <registry-name/server>/azureiotedge-hub:1.5
   

5. Aggiornare i riferimenti alle immagini nel file deployment.template.json per i moduli di sistema edgeAgent e edgeHub, sostituendo mcr.microsoft.com con il proprio valore "registry-name/server" per entrambi i moduli.

6. Aprire un editor di testo nel dispositivo IoT Edge per modificare il file di configurazione in modo da conoscere l'immagine del Registro di sistema privato.

   sudo nano /etc/aziot/config.toml
   

7. Nell'editor di testo modificare i valori dell'immagine in [agent.config]. Sostituire i valori tra parentesi con i propri valori.

   [agent.config]
   image = "<registry-name/server>/azureiotedge-agent:1.5"
   

8. Se il registro privato richiede l'autenticazione, impostare i parametri di autenticazione in [agent.config.auth].

   [agent.config.auth]
   serveraddress = "<login-server>" # Almost always equivalent to <registry-name/server>
   username = "<username>"
   password = "<password>"
   

9. Salvare le modifiche e chiudere l'editor di testo.

10. Applicare le modifiche alla configurazione di IoT Edge.

    sudo iotedge config apply
    

    Il runtime IoT Edge si riavvia.

Per altre informazioni, vedi:

• Configurare l'agente IoT Edge
• Agente di Azure IoT Edge
• Hub di Azure IoT Edge

Configurare la GC delle immagini

GC delle immagini è una funzionalità di IoT Edge v1.4 e versioni successive per pulire automaticamente le immagini Docker non più usate dai moduli IoT Edge. Elimina solo le immagini Docker estratte dal runtime di IoT Edge come parte di una distribuzione. L'eliminazione di immagini Docker inutilizzate consente di risparmiare spazio su disco.

La funzionalità viene implementata nel componente host di IoT Edge, nel servizio aziot-edged e abilitata per impostazione predefinita. La pulizia viene eseguita ogni giorno a mezzanotte (ora locale del dispositivo) e rimuove le immagini Docker inutilizzate usate sette giorni fa. I parametri per controllare il comportamento di pulizia vengono impostati in config.toml e illustrati più avanti in questa sezione. Se i parametri non vengono specificati nel file di configurazione, vengono applicati i valori predefiniti.

Ad esempio, di seguito è riportata la sezione config.toml GC delle immagini usando i valori predefiniti:

[image_garbage_collection]
enabled = true
cleanup_recurrence = "1d"
image_age_cleanup_threshold = "7d" 
cleanup_time = "00:00"

Nella tabella seguente vengono descritti i parametri di GC delle immagini. Tutti i parametri sono facoltativi e possono essere impostati singolarmente per modificare le impostazioni predefinite.

Parametro	Descrizione	Richiesto	Default value
enabled	Configura la GC delle immagini. È possibile scegliere di disabilitare la funzionalità modificando questa impostazione in false.	Facoltativo	true
cleanup_recurrence	Controlla la frequenza di ricorrenza dell'attività di pulizia. Deve essere specificata come più giorni e non può essere minore di un giorno. Ad esempio: 1d, 2d, 6d e così via.	Facoltativo	1 g
image_age_cleanup_threshold	Definisce la soglia di validità minima delle immagini inutilizzate prima di prendere in considerazione la pulizia e deve essere specificata in giorni. È possibile specificare come 0d per pulire le immagini non appena vengono rimosse dalla distribuzione. Le immagini vengono considerate inutilizzate dopo essere state rimosse dalla distribuzione.	Facoltativo	7 g
cleanup_time	Ora del giorno, nell'ora locale del dispositivo, quando viene eseguita l'attività di pulizia. Deve essere in formato HH:MM di 24 ore.	Facoltativo	00:00

Rete

• Utile
  • Verificare la configurazione in uscita e in entrata
  • Consentire le connessioni da dispositivi IoT Edge
  • Configurare la comunicazione tramite un proxy
  • Impostare il server DNS nelle impostazioni del motore del contenitore

Verificare la configurazione in uscita e in entrata

I canali di comunicazione tra Azure IoT Edge e hub IoT di Azure sono sempre configurati per essere in uscita. Per la maggior parte degli scenari di IoT Edge, sono necessarie solo tre connessioni. Il motore del contenitore deve connettersi con il registro contenitori (o i registri) che contiene le immagini del modulo. Il runtime IoT Edge deve connettersi all'hub IoT per recuperare le informazioni di configurazione del dispositivo e per inviare i messaggi e i dati di telemetria. E se si usa il provisioning automatico, IoT Edge deve connettersi al servizio di provisioning di dispositivi. Per altre informazioni, vedere Regole di configurazione del firewall e delle porte.

Consentire le connessioni da dispositivi IoT Edge

Se la configurazione di rete richiede di consentire in modo esplicito le connessioni effettuate dai dispositivi IoT Edge, esaminare il seguente elenco di componenti IoT Edge:

• Agente IoT Edge apre una connessione MQTT/AMQP permanente all'hub IoT, possibilmente tramite WebSockets.
• Hub di IoT Edge apre una singola connessione AMQP permanente o più connessioni MQTT all'hub IoT, probabilmente tramite WebSockets.
• Il servizio IoT Edge effettua chiamate HTTPS intermittenti all'hub IoT.

In tutti e tre i casi, il nome di dominio completo (FQDN) corrisponde al criterio \*.azure-devices.net.

Registri contenitori

Il motore del contenitore effettua chiamate ai registri contenitori tramite HTTPS. Per recuperare le immagini del contenitore del runtime IoT Edge, il nome FQDN è mcr.microsoft.com. Il motore del contenitore si connette ad altri registri in base alla configurazione della distribuzione.

Questo elenco di controllo è un punto di partenza per le regole del firewall:

FQDN (* = carattere jolly)	Porte TCP in uscita	Utilizzo
mcr.microsoft.com	443	Registro Container Microsoft
*.data.mcr.microsoft.com	443	Endpoint dati che fornisce la distribuzione di contenuti
*.cdn.azcr.io	443	Distribuire moduli dal Marketplace ai dispositivi
global.azure-devices-provisioning.net	443	Accesso al servizio di provisioning di dispositivi (facoltativo)
*.azurecr.io	443	Registri contenitori personali e di terze parti
*.blob.core.windows.net	443	Scaricare i delta delle immagini di Registro Azure Container dall'archiviazione BLOB
*.azure-devices.net	5671, 8883, 4431	Accesso hub IoT
*.docker.io	443	Accesso a Docker Hub (facoltativo)

¹Aprire la porta 8883 per un MQTT sicuro o la porta 5671 per un AMQP sicuro. Se è possibile effettuare connessioni solo tramite la porta 443, è possibile eseguire uno di questi protocolli tramite un tunnel WebSocket.

Poiché l'indirizzo IP di un hub IoT può cambiare senza preavviso, usare sempre il nome di dominio completo per aggiungere la configurazione all'elenco elementi consentiti. Per altre informazioni, vedere Informazioni sull'indirizzo IP dell'hub IoT.

Alcune di queste regole del firewall vengono ereditate da Registro Azure Container. Per altre informazioni, vedere Configurare le regole per accedere a un registro contenitori di Azure dietro un firewall.

È possibile abilitare gli endpoint dati dedicati nel Registro Azure Container per evitare l'aggiunta di caratteri jolly all'elenco di elementi consentiti dell'FQDN *.blob.core.windows.net. Per altre informazioni, vedere Abilitare endpoint dati dedicati.

Se non si vuole configurare il firewall per consentire l'accesso ai registri contenitori pubblici, è possibile archiviare le immagini nel registro contenitori privato, come descritto in Archiviare i contenitori di runtime nel registro privato.

Servizio di gestione delle identità di Azure IoT

Il servizio di gestione delle identità IoT fornisce servizi di provisioning e crittografia per i dispositivi Azure IoT. Il servizio di gestione delle identità controlla se la versione installata è la versione più recente. Il controllo usa i nomi di dominio completi seguenti per verificare la versione.

FQDN	Porte TCP in uscita	Utilizzo
aka.ms	443	URL di reindirizzamento a microsito che fornisce il reindirizzamento al file di versione
raw.githubusercontent.com	443	File della versione del servizio di gestione delle identità ospitato in GitHub

Configurare la comunicazione tramite un proxy

Se i dispositivi vengono distribuiti su una rete che utilizza un server proxy, devono essere in grado di comunicare attraverso il proxy per raggiungere l'hub IoT e i registri contenitori. Per altre informazioni, vedere Configurare un dispositivo IoT Edge per comunicare tramite un server proxy.

Impostare il server DNS nelle impostazioni del motore del contenitore

Specificare il server DNS per l'ambiente nelle impostazioni del motore di contenitori. L'impostazione del server DNS si applica a tutti i moduli contenitore avviati dal motore.

1. Nella directory /etc/docker sul dispositivo, modificare il file daemon.json. Se il file non esiste, crearlo.

2. Aggiungere la chiave dns e impostare l'indirizzo del server DNS su un servizio DNS accessibile pubblicamente. Se il dispositivo perimetrale non riesce ad accedere a un server DNS pubblico, usare un indirizzo del server DNS accessibile nella rete. Ad esempio:

   {
       "dns": ["1.1.1.1"]
   }
   

Gestione soluzioni

• Utile
  • Impostare i log e la diagnostica
  • Configurare il driver di registrazione predefinito
  • Prendere in considerazione i test e le pipeline CI/CD

Impostare i log e la diagnostica

In Linux, il daemon di IoT Edge usa journal come driver di registrazione predefinito. È possibile usare lo strumento della riga di comando journalctl per eseguire una query dei log daemon.

A partire dalla versione 1.2, IoT Edge si basa su più daemon. Anche se i log di ogni daemon possono essere sottoposti a query singolarmente con journalctl, i comandi iotedge system offrono un modo pratico per eseguire query sui log combinati.

• Comando iotedge consolidato:

  sudo iotedge system logs
  

• Comandojournalctl equivalente:

  journalctl -u aziot-edge -u aziot-identityd -u aziot-keyd -u aziot-certd -u aziot-tpmd
  

Quando si esegue il test di una distribuzione di IoT Edge, è generalmente possibile accedere ai dispositivi per recuperare i log e risolvere i problemi. In uno scenario di distribuzione, quell'opzione potrebbe non essere disponibile. Considerare in che modo raccogliere informazioni sui dispositivi in produzione. Una possibilità consiste nell'usare un modulo di registrazione che raccoglie le informazioni da altri moduli e le invia al cloud. Un esempio di un modulo di registrazione logspout-loganalytics, oppure è possibile progettare il proprio.

Configurare il driver di registrazione predefinito

Per impostazione predefinita, il motore del contenitore Moby non imposta limiti di dimensioni per i log dei contenitori. Nel corso del tempo questo può causare il riempimento del dispositivo con i log e l'esaurimento dello spazio su disco. Configurare il motore del contenitore per usare il local driver di registrazione locale come meccanismo di registrazione. Il driver di registrazione Local offre un limite di dimensioni del log predefinito, esegue la rotazione dei log per impostazione predefinita e usa un formato di file più efficiente, che consente di evitare l'esaurimento dello spazio su disco. È anche possibile scegliere di usare driver di registrazione diversi e impostare limiti di dimensioni diversi in base alle esigenze.

Opzione: Configurare il driver di registrazione predefinito per tutti i moduli contenitore

È possibile configurare il motore del contenitore per l'uso di un driver di registrazione specifico impostando il valore di log driver sul nome del driver di log nel daemon.json. Nell'esempio seguente il driver di registrazione predefinito viene impostato sul driver di log local (scelta consigliata).

{
    "log-driver": "local"
}

È anche possibile configurare le chiavi di log-opts in modo da usare i valori appropriati nel file daemon.json. Nell'esempio seguente, il driver di log viene impostato su local e vengono impostate le opzioni di max-size e max-file.

{
    "log-driver": "local",
    "log-opts": {
        "max-size": "10m",
        "max-file": "3"
    }
}

Aggiungere (o accodare) queste informazioni a un file denominato daemon.json e inserirle nel percorso seguente:

• /etc/docker/

Il motore di contenitore deve essere riavviato per applicare le modifiche.

Opzione: Regolare le impostazioni del log per ogni modulo contenitore

È possibile farlo in createOptions di ogni modulo. Ad esempio:

"createOptions": {
    "HostConfig": {
        "LogConfig": {
            "Type": "local",
            "Config": {
                "max-size": "10m",
                "max-file": "3"
            }
        }
    }
}

Opzioni aggiuntive nei sistemi Linux

• Configurare il motore del contenitore per inviare i log a systemd journal impostando journald come driver di registrazione predefinito.

• Rimuovere periodicamente i log precedenti dal dispositivo tramite l'installazione di uno strumento logrotate. Usare la specifica del file seguente:

  /var/lib/docker/containers/*/*-json.log{
       copytruncate
       daily
       rotate7
       delaycompress
       compress
       notifempty
       missingok
  }
  

Prendere in considerazione i test e le pipeline CI/CD

Per uno scenario di distribuzione di IoT Edge più efficiente, provare a integrare la distribuzione di produzione nel test e nelle pipeline CI/CD. Azure IoT Edge supporta più piattaforme di integrazione CI/CD, tra cui Azure DevOps. Per altre informazioni, vedere Integrazione e distribuzione continue in Azure IoT Edge.

Considerazioni relative alla sicurezza

• Importante
  • Gestire l'accesso nel registro contenitori
  • Limitare l'accesso del contenitore alle risorse host.

Gestire l'accesso nel registro contenitori

Prima di distribuire moduli nei dispositivi IoT Edge di produzione, assicurarsi di controllare l'accesso al registro contenitori in modo che gli utenti esterni non possano accedere o apportare modifiche alle immagini del contenitore. Usare un registro contenitori privato per gestire le immagini del contenitore.

Nelle esercitazioni e in altri documenti, viene indicato di usare nel dispositivo IoT Edge le stesse credenziali del registro contenitori usate nel computer di sviluppo. Queste istruzioni sono destinate solamente a facilitare la configurazione degli ambienti di test e di sviluppo e non devono essere seguite in uno scenario di produzione.

Per un accesso più protetto al Registro di sistema, è possibile scegliere opzioni di autenticazione. Un'autenticazione comune e consigliata consiste nell'usare un'entità servizio Active Directory particolarmente adatta alle applicazioni o ai servizi per eseguire il pull delle immagini del contenitore in modo automatico o senza intervento dell'utente (headless), come fanno i dispositivi IoT Edge. Un'altra opzione consiste nell'usare i token con ambito repository, che consentono di creare identità di breve o lunga durata esistenti solo nel Registro Azure Container in cui sono state create e di definire l'ambito dell'accesso al livello del repository.

Per creare un'entità servizio, eseguire i due script come descritto in Creare un'entità servizio. Gli script eseguono le task seguenti:

• Il primo script crea l'entità servizio. Restituisce l'ID entità servizio e la password. Archiviare questi valori in modo sicuro nei record.

• Il secondo script crea assegnazioni di ruolo da concedere all'entità servizio, un'operazione che può essere eseguita successivamente, se necessario. È consigliabile applicare il ruolo utente acrPull per il parametro role. Per un elenco dei ruoli, vedere Ruoli e autorizzazioni di Registro Azure Container.

Per eseguire l'autenticazione usando un'entità servizio, specificare l'ID entità servizio e la password ottenuti dal primo script. Specificare queste credenziali nel manifesto della distribuzione.

• Per il nome utente o l'ID client, specificare l'ID entità servizio.

• Per la password o il segreto client, specificare la password dell'entità servizio.

Per creare token con ambito repository, seguire le istruzioni in Creare un token con ambito repository.

Per eseguire l'autenticazione usando token con ambito repository, specificare il nome del token e la password ottenuti dopo aver creato il token con ambito repository. Specificare queste credenziali nel manifesto della distribuzione.

• Per il nome utente, specificare il nome utente del token.

• Per la password, specificare una delle password del token.

Limitare l'accesso del contenitore alle risorse host.

Per bilanciare le risorse host condivise tra moduli, è consigliabile inserire limiti al consumo di risorse per ogni modulo. Questi limiti garantiscono che un modulo non possa usare troppa memoria o CPU e impedire l'esecuzione di altri processi nel dispositivo. La piattaforma IoT Edge non limita le risorse per i moduli per impostazione predefinita, poiché la quantità di risorse necessarie per eseguire in modo ottimale un determinato modulo va determinata.

Docker fornisce alcuni vincoli che è possibile usare per limitare le risorse, ad esempio l'utilizzo della memoria e della CPU. Per altre informazioni, vedere Opzioni di runtime con memoria, CPU e GPU.

Questi vincoli possono essere applicati ai singoli moduli usando le opzioni di creazione nei manifesti della distribuzione. Per altre informazioni, vedere Come configurare opzioni di creazione di contenitori per moduli IoT Edge.

Passaggi successivi

• Altre informazioni sulla distribuzione automatica di IoT Edge.
• Vedere come IoT Edge supporta l'integrazione e la distribuzione continue.