Preparare la distribuzione della soluzione IoT Edge alla produzione

Si applica a: IoT Edge 1.4

Importante

IoT Edge 1.4 è la versione supportata. Se si usa una versione precedente, vedere Aggiornare IoT Edge.

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

• 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. Il certificato della CA viene quindi dichiarato al runtime di IoT Edge nel file di configurazione. Per gli scenari di sviluppo e test, il runtime di IoT Edge crea certificati temporanei se non vengono dichiarati certificati 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 del dispositivo, da un'autorità di certificazione autofirmato o acquistato da un'autorità di certificazione commerciale.

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

Per altre informazioni su come installare i certificati in un dispositivo IoT Edge e farvi riferimento dal file di configurazione, vedere Gestire il certificato in 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 dei dispositivi per hub IoT è un servizio che consente di distribuire gli aggiornamenti over-the-air per i dispositivi IoT Edge.

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

Usare Moby come motore del contenitore

Disporre di un motore del contenitore è un prerequisito per qualsiasi dispositivo IoT Edge. Solo il motore moby è supportato nell'ambiente 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 la comunicazione upstream con hub IoT sia per l'agente IoT Edge che per l'hub 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 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 di IoT Edge e l'hub di IoT Edge. In caso contrario, 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 IoT Edge è ottimizzato per le prestazioni per impostazione predefinita, quindi 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, è possibile impostare la variabile di ambiente OptimizeForPerformance su false nell'hub IoT Edge.

Quando OptimizeForPerformance è impostato su true, l'head del protocollo MQTT usa PooledByteBufferAllocator, con 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 più piccoli.

Disabilitare i protocolli non usati

Un altro modo per ottimizzare le prestazioni dell'hub IoT Edge e ridurre l'utilizzo della memoria consiste nel disattivare i test di protocollo per tutti i protocolli che non si usano nella soluzione.

I teste del protocollo vengono configurati impostando variabili di ambiente booleane per il modulo hub IoT Edge nei manifesti della 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 IoT Edge archivia temporaneamente i messaggi se non possono essere recapitati a hub IoT per qualsiasi motivo. È possibile configurare per quanto tempo l'hub IoT Edge mantiene i messaggi non recapitati prima di lasciarli scadere. In caso di problemi di memoria nel dispositivo, è possibile ridurre il valore timeToLiveSecs nel modulo gemello dell'hub 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 del modulo 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 ModuleUpdateMode di ambiente dell'agente IoT Edge sul valore WaitForAllPullsstringa . Per altre informazioni, vedere Variabili di ambiente 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 l'operazione di Garbage Collection 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.1 che vanno alla fine di un repository di contenitori. Ad esempio, mcr.microsoft.com/azureiotedge-agent:1.1. 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 riconoscerà il tag incrementato come una nuova versione ed eseguirà 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.1 viene aggiornato ogni volta che è disponibile una nuova versione in modo da puntare alla versione 1.1.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 a scopo 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.1.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 a scopo 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 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 sa 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 i moduli di runtime edgeAgent e edgeHub . Questa operazione può essere necessaria se sono presenti restrizioni del firewall molto restrittive perché questi contenitori di runtime vengono archiviati nel Registro Contenitori Microsoft (MCR).

I passaggi seguenti illustrano come eseguire il pull di un'immagine Docker di edgeAgent e edgeHub nel computer locale, eseguirne il retaging, 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.4
   
   # Pull edgeHub image
   docker pull mcr.microsoft.com/azureiotedge-hub:1.4
   

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

   docker images
   

3. Modificare il tag delle immagini edgeAgent e edgeHub . Sostituire i valori tra parentesi quadre con i valori personalizzati.

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

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

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

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 "nome-registro/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 quadre con i valori personalizzati.

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

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 uscire dall'editor di testo.

10. Applicare la modifica della configurazione di IoT Edge.

    sudo iotedge config apply
    

    Il runtime di IoT Edge viene riavviato.

Per altre informazioni, vedi:

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

Configurare l'operazione di Garbage Collection delle immagini

Image Garbage Collection è 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, il aziot-edged servizio e abilitato 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 config.toml sezione Image Garbage Collection 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 Garbage Collection delle immagini. Tutti i parametri sono facoltativi e possono essere impostati singolarmente per modificare le impostazioni predefinite.

Parametro	Descrizione	Richiesto	Valore predefinito
enabled	Abilita l'operazione di Garbage Collection dell'immagine. È possibile scegliere di disabilitare la funzionalità modificando questa impostazione su false.	Facoltativo	true
cleanup_recurrence	Controlla la frequenza di ricorrenza dell'attività di pulizia. Deve essere specificato 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 che sono 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 di contenitori

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. Se si usa il provisioning automatico, IoT Edge deve connettersi al servizio Device Provisioning. 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 a hub IoT.

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

Registri contenitori

Il motore contenitore effettua chiamate ai registri contenitori tramite HTTPS. Per recuperare le immagini del contenitore di runtime di IoT Edge, il nome di dominio completo è 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 Device Provisioning (facoltativo)
*.azurecr.io	443	Registri contenitori personali e di terze parti
*.blob.core.windows.net	443	Scaricare Registro Azure Container delta dell'immagine dall'archivio BLOB
*.azure-devices.net	5671, 8883, 4431	Accesso hub IoT
*.docker.io	443	Accesso all'hub Docker (facoltativo)

¹Aprire la porta 8883 per la porta MQTT sicura o la porta 5671 per 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 consentire la configurazione dell'elenco. Per altre informazioni, vedere Informazioni sull'indirizzo IP del 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'elenco di caratteri jolly dell'FQDN *.blob.core.windows.net . Per altre informazioni, vedere Abilitare endpoint dati dedicati.

Nota

Per fornire un FQDN coerente tra gli endpoint REST e i dati, a partire dal 15 giugno 2020 l'endpoint dati del Registro Azure Container passerà da *.cdn.mscr.io a *.data.mcr.microsoft.com
Per altre informazioni, vedere Configurazione delle regole del firewall del client del Registro Azure Container

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 identity 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 vanità 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 di contenitori

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 del /etc/docker dispositivo modificare il daemon.json file. Creare il file se non esiste.

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 iotedge system comandi offrono un modo pratico per eseguire query sui log combinati.

• Comando consolidato iotedge :

  sudo iotedge system logs
  

• Comando equivalente journalctl :

  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 come meccanismo di registrazione. Local il driver di registrazione 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 in daemon.json. Nell'esempio seguente il driver di registrazione predefinito viene impostato sul driver di local log (scelta consigliata).

{
    "log-driver": "local"
}

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

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

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

• /etc/docker/

Per rendere effettive le modifiche, è necessario riavviare il motore del contenitore.

Opzione: Modificare le impostazioni del log per ogni modulo contenitore

A tale scopo, è possibile usare 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 al systemdjournal impostando journald come driver di registrazione predefinito.

• Rimuovere periodicamente i log precedenti dal dispositivo installando 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 sulla sicurezza

• Importante
  • Gestire l'accesso nel registro contenitori
  • Limitare l'accesso al 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 tra le 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 automatico (headless), come fanno i dispositivi IoT Edge. Un'altra opzione consiste nell'usare i token con ambito repository, che consentono di creare identità long o short-live esistenti solo nei Registro Azure Container creati in e di definire l'ambito di accesso al livello del repository.

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

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

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

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 la procedura per 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.

Nota

Dopo aver implementato un'autenticazione di sicurezza avanzata, disabilitare l'impostazione utente Amministrazione in modo che l'accesso predefinito a nome utente/password non sia più disponibile. Nel registro contenitori nel portale di Azure selezionare Chiavi di accesso dal menu del riquadro a sinistra in Impostazioni.

Limitare l'accesso al 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 le opzioni di creazione di contenitori per i moduli IoT Edge.

Passaggi successivi

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