Preparare la distribuzione della soluzione IoT Edge alla produzione

Si applica IoT Edge 1.1

Importante

IoT Edge 1.1 data di fine del supporto è stata il 13 dicembre 2022. Controlla il ciclo di vita dei prodotti Microsoft per ottenere informazioni sul modo in cui viene supportato questo prodotto, servizio, tecnologia o API. Per altre informazioni sull'aggiornamento alla versione più recente di IoT Edge, 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 del 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. Tale certificato della CA viene quindi dichiarato al runtime IoT Edge nel file di configurazione. Per gli scenari di sviluppo e test, il runtime di IoT Edge crea certificati temporanei se nel file di configurazione non vengono dichiarati certificati. 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.

Nota

Attualmente, una limitazione nel libiothsm impedisce l'uso di certificati che scadono il 1° gennaio 2038.

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 di CA

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

Metodi alternativi per l'aggiornamento 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 di IoT Edge
  • Usare le immagini del modulo corrette nei manifesti di distribuzione
  • Tenere presente i limiti delle 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 vincolate, è possibile impostare la variabile di ambiente OptimizeForPerformance su false nell'hub IoT Edge.

Quando OptimizeForPerformance è impostato su true, l'intestazione 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 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 teste di protocollo per tutti i protocolli che non si usano nella soluzione.

Le teste del protocollo vengono configurate 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 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 delle 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. Prendere in considerazione alcune mitigazioni comuni per questo limite rigido:

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

Gestione di 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 in sequenza : usare 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 per finalità di sviluppo.

• Tag specifici : usare 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 per finalità di produzione.

Gestire i volumi

IoT Edge non rimuove i volumi collegati ai contenitori di moduli. Questo comportamento è previsto, in quanto consente di rendere persistenti i dati tra istanze del contenitore, ad esempio scenari di aggiornamento. Tuttavia, se questi volumi vengono lasciati inutilizzati, può causare l'esaurimento dello spazio su disco e gli errori di sistema successivi. 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 rigide perché questi contenitori di runtime vengono archiviati nel Registro Contenitori Di Microsoft.

La procedura seguente illustra come eseguire il pull di un'immagine Docker di edgeAgent e edgeHub nel computer locale, effettuare nuovamente 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.1
   
   # Pull edgeHub image
   docker pull mcr.microsoft.com/azureiotedge-hub:1.1
   

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 propri.

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

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.1
   
   # Push your edgeHub image to your private registry
   docker push <registry-name/server>/azureiotedge-hub:1.1
   

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 propri.

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

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 IoT Edge.

    sudo iotedge config apply
    

    Il runtime IoT Edge viene riavviato.

Per altre informazioni, vedere:

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

Rete

• Utile
  • Verificare la configurazione in uscita e in entrata
  • Consentire le connessioni da dispositivi IoT Edge
  • Configurare la comunicazione tramite un proxy

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:

• IoT Edge agente apre una connessione AMQP/MQTT persistente a hub IoT, possibilmente tramite WebSocket.
• IoT Edge hub apre una singola connessione AMQP persistente o più connessioni MQTT a hub IoT, possibilmente tramite WebSocket.
• IoT Edge servizio 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.

Inoltre, il motore contenitore effettua chiamate ai registri contenitori tramite HTTPS. Per recuperare le immagini del contenitore di runtime 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 il recapito del contenuto
*.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'archiviazione BLOB
*.azure-devices.net	5671, 8883, 4431	Accesso hub IoT
*.docker.io	443	Docker Hub accesso (facoltativo)

¹ Aprire la porta 8883 per proteggere MQTT o porta 5671 per AMQP sicura. 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 Azure Container dietro un firewall.

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

Nota

Per fornire un nome di dominio completo coerente tra gli endpoint REST e dati, a partire dal 15 giugno 2020 l'endpoint dei dati del Registro contenitori Microsoft cambierà da *.cdn.mscr.io a *.data.mcr.microsoft.com
Per altre informazioni, vedere Configurazione delle regole del firewall client del Registro Contenitori Microsoft

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

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.

Gestione della soluzione

• 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.

In Windows, il daemon di IoT Edge usa la diagnostica di PowerShell. Usare Get-IoTEdgeLog per eseguire query dei log da daemon. I moduli IoT Edge usano il driver JSON per la registrazione, ovvero l'impostazione predefinita.

. {Invoke-WebRequest -useb aka.ms/iotedge-win} | Invoke-Expression; Get-IoTEdgeLog

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 contenitore Moby non imposta i limiti delle dimensioni del log dei contenitori. Nel 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 proprie esigenze.

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

È possibile configurare il motore del contenitore per usare un driver di registrazione specifico impostando il valore di log driver sul nome del driver di log nell'oggetto daemon.json. Nell'esempio seguente viene impostato il driver di registrazione predefinito sul local driver di log (consigliato).

{
    "log-driver": "local"
}

È anche possibile configurare le log-opts chiavi per usare i valori appropriati nel daemon.json file. L'esempio seguente imposta il driver di log su local e imposta 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:

Piattaforma	Posizione
Linux	/etc/docker/
Windows	C:\ProgramData\iotedge-moby\config\

Il motore del contenitore deve essere riavviato per rendere effettive le modifiche.

Opzione: Modificare 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 al systemdjournal impostando journald come driver di registrazione predefinito.

• Rimuovere periodicamente i vecchi log 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 relative alla sicurezza

• Importante
  • Gestire l'accesso nel registro contenitori
  • Limitare l'accesso ai contenitori 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 le opzioni di autenticazione. Un'autenticazione popolare e consigliata consiste nell'usare un'entità servizio Active Directory adatta per le applicazioni o i servizi per eseguire il pull delle immagini del contenitore in modo automatizzato o altrimenti automatico (headless), come IoT Edge dispositivi. Un'altra opzione consiste nell'usare i token con ambito repository, che consentono di creare identità lunghe o brevi che esistono solo nei Registro Azure Container creati e l'accesso all'ambito al livello di 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 dell'entità servizio e la password dell'entità servizio. Archiviare questi valori in modo sicuro nei record.

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

Per eseguire l'autenticazione usando un'entità servizio, specificare l'ID dell'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 dell'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 i 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 al nome utente/password non sia più disponibile. Nel registro contenitori nel portale di Azure, dal menu del riquadro sinistro in Impostazioni selezionare Chiavi di accesso.

Limitare l'accesso ai contenitori 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 troppo memoria o utilizzo della 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 un determinato modulo richiede il test ottimale.

Docker fornisce alcuni vincoli che è possibile usare per limitare le risorse come 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 di IoT Edge.

Passaggi successivi

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