Préparer le déploiement en production d’une solution IoT Edge

Article
08/07/2024

S’applique à : IoT Edge 1.5 IoT Edge 1.4

Important

IoT Edge 1.5 LTS et IoT Edge 1.4 LTS sont des versions prises en charge. IoT Edge 1.4 LTS sera en fin de vie le 12 novembre 2024. Si vous utilisez une version antérieure, consultez l’article Mettre à jour IoT Edge.

Au moment de faire passer votre solution IoT Edge du développement à la production, vérifiez qu’elle est configurée de façon à offrir des performances continues.

Les informations indiquées dans cet article ne se valent pas toutes. Pour clarifier l’ordre de priorité, chaque section commence par une liste qui divise le travail en deux sections : Important, donc à effectuer avant de passer en production, ou Utile, c’est-à-dire bon à savoir.

Configuration de l’appareil

Il existe de nombreux types d’appareils IoT Edge : un Raspberry Pi, un portable, une machine virtuelle sur un serveur, etc. Vous pouvez avoir accès à l’appareil physiquement ou via une connexion virtuelle ; il peut aussi être isolé pendant de longues périodes. Dans les deux cas, l’objectif est de vérifier qu’il est configuré de façon à fonctionner de manière adéquate.

Important
- Installer les certificats de production
- Élaborer un plan de gestion des appareils
- Utiliser Moby comme moteur de conteneur. Si vous utilisez des snaps Ubuntu Core, le snap Docker est géré par Canonical et pris en charge pour les scénarios de production.
Utile
- Choisir un protocole en amont

Installer les certificats de production

Un certificat d’autorité de certification doit être installé sur chaque appareil IoT Edge en production. Ce certificat d’autorité de certification est ensuite déclaré au runtime IoT Edge dans le fichier config. Pour faciliter les scénarios de développement et de test, le runtime IoT Edge crée des certificats temporaires si aucun certificat n’est déclaré dans le fichier config. Toutefois, ces certificats temporaires expirent au bout de trois mois et ne sont pas sécurisés pour les scénarios de production. Dans les scénarios de production, vous devez fournir votre propre certificat d’autorité de certification Edge, soit issu d’une autorité de certification auto-signée, soit acheté auprès d’une autorité de certification commerciale.

Pour comprendre le rôle du certificat d’autorité de certification Edge, consultez Comment Azure IoT Edge utilise les certificats.

Pour savoir comment installer des certificats sur un appareil IoT Edge et y faire référence dans le fichier config, consultez Gérer un certificat sur un appareil IoT Edge.

Élaborer un plan de gestion des appareils

Avant de mettre un appareil en production, il faut savoir comment gérer les mises à jour à venir. Pour un appareil IoT Edge, il peut y avoir plusieurs composants à mettre à jour :

Le microprogramme de l’appareil
Bibliothèques du système d’exploitation
Moteur de conteneur, comme Moby
IoT Edge
Certificats d’autorité de certification

Device Update pour IoT Hub est un service qui vous permet de déployer des mises à jour OTA (over-the-air) pour vos appareils IoT Edge.

Les autres méthodes de mise à jour d’IoT Edge exigent un accès physique ou SSH à l’appareil IoT Edge. Pour plus d’informations, consultez Mettre à jour le runtime IoT Edge. Pour mettre à jour plusieurs appareils, envisagez d’ajouter les étapes de mise à jour à un script ou d’utiliser un outil d’automatisation comme Ansible.

Moteur de conteneur

Un moteur de conteneur fait partie des prérequis de tous les appareils IoT Edge. Le moteur Moby est pris en charge en production. Si vous utilisez des snaps Ubuntu Core, le snap Docker est géré par Canonical et pris en charge pour les scénarios de production. Les autres moteurs de conteneur, comme Docker, fonctionnent avec IoT Edge et sont utilisables à des fins de développement. Le moteur Moby peut être redistribué s’il est utilisé avec Azure IoT Edge ; par ailleurs, Microsoft en assure la maintenance.

Choisir un protocole en amont

Vous pouvez configurer le protocole (qui détermine le port utilisé) pour les communications en amont vers IoT Hub, tant pour l’agent IoT Edge que pour le hub IoT Edge. Le protocole par défaut, AMQP, est modifiable en fonction de la configuration réseau.

Les modules runtime ont tous les deux une variable d’environnement UpstreamProtocol, dont les valeurs valides sont les suivantes :

MQTT
AMQP
MQTTWS
AMQPWS

Configurez la variable UpstreamProtocol pour l’agent IoT Edge dans le fichier config sur l’appareil. Par exemple, si l’appareil IoT Edge se trouve derrière un serveur proxy qui bloque les ports AMQP, il peut se révéler nécessaire de configurer l’agent IoT Edge de façon à ce qu’il utilise AMQP sur WebSocket (AMQPWS) pour établir la connexion initiale à IoT Hub.

Une fois l’appareil IoT Edge connecté, poursuivez la configuration de la variable UpstreamProtocol pour les deux modules de runtime dans les déploiements à venir. Vous trouverez un exemple de ce processus dans Configurer un appareil IoT Edge pour communiquer via un serveur proxy.

Déploiement

Utile
- Rester cohérent avec le protocole en amont
- Configurer le stockage hôte pour les modules système
- Réduire l’espace mémoire utilisé par le hub IoT Edge
- Utiliser des images de module correctes dans les manifestes de déploiement
- Gardez à l’esprit les limites de taille du jumeau numérique lors de l’utilisation de modules personnalisés
- Configurer la façon dont les mises à jour des modules sont appliquées

Rester cohérent avec le protocole en amont

Si vous avez configuré l’agent IoT Edge sur votre appareil IoT Edge de façon à ce qu’il utilise un protocole autre que le protocole par défaut (AMQP), déclarez le même protocole dans tous les déploiements futurs. Par exemple, si votre appareil IoT Edge se trouve derrière un serveur proxy qui bloque les ports AMQP, vous avez probablement configuré l’appareil se sorte qu’il se connecte via AMQP sur WebSocket (AMQPWS). Lorsque vous déployez des modules sur l’appareil, configurez le même protocole AMQPWS pour l’agent IoT Edge et le hub IoT Edge. Sinon, le protocole par défaut AMQP remplace les paramètres et vous empêche de vous reconnecter.

Il suffit de configurer la variable d’environnement UpstreamProtocol pour les deux modules : l’agent IoT Edge et le hub IoT Edge. Tous les modules supplémentaires adoptent le protocole défini dans les modules de runtime.

Vous trouverez un exemple de ce processus dans Configurer un appareil IoT Edge pour communiquer via un serveur proxy.

Configurer le stockage hôte pour les modules système

Les modules de hub et d’agent IoT Edge utilisent le stockage local pour maintenir l’état et activer la messagerie entre les modules, les appareils et le cloud. Pour une fiabilité et des performances optimales, configurez les modules système pour qu’ils utilisent le stockage sur le système de fichiers hôte.

Pour plus d’informations, consultez Stockage hôte pour les modules système.

Réduire l’espace mémoire utilisé par le hub IoT Edge

Si vous déployez des appareils contraints avec une quantité de mémoire disponible limitée, vous pouvez configurer le hub IoT Edge de façon à ce qu’il s’exécute avec une capacité rationalisée et utilise moins d’espace disque. Ces configurations limitent les performances du hub IoT Edge. Trouvez l’équilibre adapté à votre solution.

Ne pas optimiser les performances sur les appareils contraints

Le hub IoT Edge, optimisé par défaut du point de vue des performances, tente d’allouer de grands blocs de mémoire. Cette configuration risque provoquer des problèmes de stabilité sur les petits appareils, comme le Raspberry Pi. Si vous déployez des appareils offrant des ressources limitées, vous pouvez si vous le souhaitez définir la variable d’environnement OptimizeForPerformance sur false sur le hub IoT Edge.

Lorsque la valeur d’OptimizeForPerformance est true, l’en-tête du protocole MQTT utilise PooledByteBufferAllocator, qui offre de meilleures performances, mais alloue plus de mémoire. L’allocateur ne fonctionne pas correctement sur des systèmes d’exploitation 32 bits ou sur des appareils ne disposant pas de suffisamment de mémoire. En outre, en cas d’optimisation des performances, RocksDB alloue plus de mémoire pour son rôle de fournisseur de stockage local.

Pour plus d’informations, consultez Problèmes de stabilité sur les appareils plus petits.

Désactiver les protocoles inutilisés

Il existe un autre moyen d’optimiser les performances du hub IoT Edge et de réduire son utilisation de la mémoire : désactiver les têtes de tous les protocoles non utilisés dans la solution.

Les têtes de protocole se configurent en définissant des variables d’environnement booléennes pour le module du hub IoT Edge dans les manifestes de déploiement. Voici les trois variables en question :

amqpSettings__enabled
mqttSettings__enabled
httpSettings__enabled

Ces variables comportent toutes les trois deux traits de soulignement. Elles peuvent être définies sur true ou false.

Réduire le temps de stockage des messages

Le module du hub IoT Edge stocke temporairement les messages si, pour une raison ou pour une autre, il n’est pas possible de les remettre à IoT Hub. Vous pouvez configurer la durée pendant laquelle le hub IoT Edge conserve les messages non remis avant qu’ils n’expirent. Si vous avez des problèmes de mémoire sur votre appareil, vous pouvez diminuer la valeur timeToLiveSecs dans le jumeau de module du hub IoT Edge.

La valeur par défaut du paramètre timeToLiveSecs est de 7 200 secondes, soit deux heures.

Utiliser des images de module correctes dans les manifestes de déploiement

Si une image de module vide ou incorrecte est utilisée, l’agent Edge tente de charger l’image, ce qui entraîne la génération d’un trafic supplémentaire. Ajoutez les images correctes au manifeste de déploiement pour éviter de générer un trafic inutile.

Ne pas utiliser les versions de débogage des images de module

Lors du passage de scénarios de test à des scénarios de production, pensez à supprimer les configurations de débogage des manifestes de déploiement. Vérifiez qu’aucune des images de modules des manifestes de déploiement ne comporte le suffixe .debug. Si vous avez ajouté des options de création pour exposer les ports dans les modules à des fins de débogage, supprimez-les également.

Gardez à l’esprit les limites de taille du jumeau numérique lors de l’utilisation de modules personnalisés

Le manifeste de déploiement qui contient des modules personnalisés fait partie du jumeau numérique EdgeAgent. Passez en revue la section sur la limitation de la taille du jumeau de module.

Si vous déployez un grand nombre de modules, vous risquez d’épuiser cette limite de taille de jumeau numérique. Prenons quelques mesures d’atténuation courantes pour cette limite matérielle :

Stockez n’importe quelle configuration dans le jumeau de module personnalisé, qui a sa propre limite.
Stockez une configuration qui pointe vers un emplacement qui n’est pas limité par un espace (autrement dit, dans un magasin d’objets blob).

Configurer la façon dont les mises à jour des modules sont appliquées

Lorsqu’un déploiement est mis à jour, l’agent Edge reçoit la nouvelle configuration en tant que mise à jour de jumeau. Si la nouvelle configuration a des images de module nouvelles ou mises à jour, par défaut, l’agent Edge traite de façon séquentielle chaque module :

L’image mise à jour est téléchargée
Le module en cours d’exécution est arrêté
Une nouvelle instance de module est démarrée
La mise à jour de module suivante est traitée

Dans certains cas, par exemple lorsqu’il existe des dépendances entre les modules, il peut être souhaitable de télécharger d’abord toutes les images de module mises à jour avant de redémarrer les modules en cours d’exécution. Ce comportement de mise à jour de module peut être configuré en définissant une variable d’environnement d’agent IoT Edge ModuleUpdateMode sur la valeur de chaîne WaitForAllPulls. Pour en savoir plus, voir Variables d’environnement IoT Edge.

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

Gestion de conteneur

Important
- Utiliser des balises pour gérer les versions
- Gérer les volumes
Utile
- Stocker les conteneurs Runtime dans votre registre privé
- Configurer le nettoyage de la mémoire d’image

Utiliser des balises pour gérer les versions

Une balise est un concept Docker servant à faire la distinction entre les versions des conteneurs Docker. Les balises sont des suffixes comme 1.5, ajoutées à la fin d’un référentiel de conteneur. Exemple : mcr.microsoft.com/azureiotedge-agent:1.5. Les balises étant mutables et modifiables pour pointer vers un autre conteneur à tout moment, il est essentiel que votre équipe se mette d’accord sur une convention à suivre pour mettre à jour vos images de module par la suite.

Les balises aident également à appliquer des mises à jour sur les appareils IoT Edge. Lorsque vous envoyez une version mise à jour d’un module à votre registre de conteneurs, incrémentez la balise. Ensuite, transmettez un nouveau déploiement sur vos appareils avec la balise incrémentée. Le moteur de conteneur la reconnaît comme une nouvelle version et extrait la dernière version du module sur l’appareil.

Étiquettes pour le runtime IoT Edge

Les images de l’agent IoT Edge et du hub IoT Edge sont marquées avec la version IoT Edge à laquelle elles sont associées. Il existe deux façons d’utiliser des étiquettes avec les images de runtime :

Étiquettes évolutives : utilisez uniquement les deux premières valeurs du numéro de version pour obtenir la dernière image qui correspond à ces chiffres. Par exemple, la version 1.5 est mise à jour lorsqu’une nouvelle mise en production pointe vers la dernière version 1.5.x. Si le runtime du conteneur sur votre appareil IoT Edge réextrait l’image, les modules de runtime sont mis à jour vers la dernière version. Les déploiements à partir du portail Azure adoptent par défaut des étiquettes évolutives. Cette approche est proposée à des fins de développement.
Étiquettes spécifiques : utilisez les trois valeurs du numéro de version pour définir explicitement la version de l’image. Par exemple, la version 1.5.0 ne changera pas après sa mise en production initiale. Vous pouvez déclarer un nouveau numéro de version dans le manifeste de déploiement quand vous êtes prêt à effectuer une mise à jour. Cette approche est proposée à des fins de production.

Gérer les volumes

IoT Edge ne supprime pas les volumes attachés à des conteneurs de module. Ce comportement est par conception, car il permet de conserver les données entre les instances de conteneur, comme par exemple dans les scénarios de mise à niveau. Toutefois, si ces volumes sont laissés inutilisés, cela peut entraîner un épuisement de l’espace disque et des erreurs système ultérieures. Si vous utilisez des volumes Docker dans votre scénario, nous vous encourageons à utiliser des outils Docker tels que docker volume prune et docker volume rm pour supprimer les volumes inutilisés, en particulier pour les scénarios de production.

Stocker les conteneurs Runtime dans votre registre privé

Vous savez comment stocker des images conteneur pour les modules de code personnalisés dans votre registre privé Azure, mais vous pouvez également l’utiliser pour stocker des images conteneur publiques comme les modules runtime edgeAgent et edgeHub. Cela peut être nécessaire si vous avez des restrictions de pare-feu strictes, car ces conteneurs de runtime sont stockés dans le registre de conteneurs Microsoft (MCR).

Les étapes suivantes montrent comment extraire une image Docker d’edgeAgent et d’edgeHub sur votre ordinateur local, comment la réétiqueter et l’envoyer à votre registre privé, puis comment mettre à jour votre fichier de configuration afin que vos appareils sachent qu’ils doivent extraire l’image de votre registre privé.

Extrayez l’image Docker edgeAgent du registre Microsoft. Mettez à jour le numéro de version si nécessaire.

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

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

Listez toutes vos images Docker, recherchez les images edgeAgent et edgeHub, puis copiez leur ID d’image.
```
docker images
```

Réétiquetez vos images edgeAgent et edgeHub. Remplacez les valeurs entre chevrons par les vôtres.

# 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

Envoyez vos images edgeAgent et edgeHub dans votre registre privé. Remplacez la valeur entre chevrons par la vôtre.

# 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

Mettez à jour les références d’image dans le fichier deployment.template.json pour les modules système edgeAgent et edgeHub en remplaçant mcr.microsoft.com par votre propre « registry-name/server » pour les deux modules.
Ouvrez un éditeur de texte sur votre appareil IoT Edge pour modifier le fichier de configuration afin qu’il ait connaissance de votre image de registre privé.
```
sudo nano /etc/aziot/config.toml
```
Dans l’éditeur de texte, changez vos valeurs d’image sous [agent.config]. Remplacez les valeurs entre chevrons par les vôtres.
```
[agent.config]
image = "<registry-name/server>/azureiotedge-agent:1.5"
```

Si votre registre privé nécessite une authentification, définissez les paramètres d’authentification dans [agent.config.auth].

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

Enregistrez vos changements et quittez l’éditeur de texte.
Appliquez le changement de configuration IoT Edge.
```
sudo iotedge config apply
```
Votre runtime IoT Edge redémarre.

Pour plus d’informations, consultez l’article suivant :

Configurer le nettoyage de la mémoire d’image

Le nettoyage de la mémoire d’image est une fonctionnalité d’IoT Edge v1.4 et versions ultérieures pour nettoyer automatiquement les images Docker qui ne sont plus utilisées par les modules IoT Edge. Il supprime uniquement les images Docker qui ont été extraites par le runtime IoT Edge dans le cadre d’un déploiement. La suppression des images Docker inutilisées permet de conserver de l’espace disque.

La fonctionnalité est implémentée dans le composant hôte d’IoT Edge, le service aziot-edged, et est activée par défaut. Le nettoyage est effectué tous les jours à minuit (heure locale de l’appareil) ; il supprime les images Docker inutilisées qui ont été utilisées pour la dernière fois il y a sept jours. Les paramètres permettant de contrôler le comportement de nettoyage sont définis dans config.toml, et sont expliqués plus loin dans cette section. Si les paramètres ne sont pas spécifiés dans le fichier de configuration, les valeurs par défaut sont appliquées.

Par exemple, voici la section de nettoyage de la mémoire d’image config.toml avec les valeurs par défaut :

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

Le tableau suivant décrit les paramètres de nettoyage de la mémoire d’image. Tous les paramètres sont facultatifs et peuvent être définis individuellement pour modifier les paramètres par défaut.

Paramètre	Description	Obligatoire	Valeur par défaut
`enabled`	Active le nettoyage de la mémoire d’image. Vous pouvez choisir de désactiver la fonctionnalité en définissant ce paramètre sur `false`.	Facultatif	true
`cleanup_recurrence`	Contrôle la fréquence de périodicité de la tâche de nettoyage. Doit être spécifié sous la forme d’un multiple de jours, et ne peut pas être inférieur à un jour. Par exemple : 1d, 2d, 6d, etc.	Facultatif	1d
`image_age_cleanup_threshold`	Définit le seuil d’âge minimal des images inutilisées avant d’envisager le nettoyage ; doit être spécifié en jours. Vous pouvez spécifier 0d pour nettoyer les images dès qu’elles sont supprimées du déploiement. Les images sont considérées comme inutilisées après leur suppression du déploiement.	Facultatif	7d
`cleanup_time`	Heure du jour, en heure locale de l’appareil, d’exécution de la tâche de nettoyage. Doit être au format HH:MM de 24 heures.	Facultatif	00:00

Mise en réseau

Utile
- Vérifier la configuration sortante/entrante
- Autoriser les connexions à partir d’appareils IoT Edge
- Configurer la communication via un proxy
- Définissez le serveur DNS dans les paramètres du moteur de conteneur

Vérifier la configuration sortante/entrante

Les canaux de communication entre Azure IoT Hub et IoT Edge sont toujours configurés pour être sortants. Dans la plupart des scénarios IoT Edge, seules trois connexions sont nécessaires. Une connexion doit être établie entre le moteur de conteneur et le ou les registres de conteneurs qui contiennent les images de module. Le runtime IoT Edge doit être connecté à IoT Hub pour récupérer des informations de configuration des appareils et envoyer des messages et des données de télémétrie. Enfin, si vous utilisez l’approvisionnement automatique, IoT Edge doit se connecter au service d’approvisionnement d’appareil (Service IoT Hub Device Provisioning). Pour plus d’informations, voir Règles de configuration du pare-feu et des ports.

Autoriser les connexions à partir d’appareils IoT Edge

Si votre configuration réseau exige d’autoriser explicitement les connexions effectuées à partir d’appareils IoT Edge, passez en revue la liste suivante de composants IoT Edge :

L’agent IoT Edge ouvre une connexion AMQP/MQTT persistante à IoT Hub, éventuellement sur WebSockets.
Le hub IoT Edge ouvre une seule connexion AMQP persistante ou plusieurs connexions MQTT à IoT Hub, éventuellement sur WebSockets.
Le service IoT Edge effectue des appels HTTPS intermittents au service IoT Hub.

Dans les trois cas, le nom de domaine complet (FQDN) correspond au modèle \*.azure-devices.net.

Registres de conteneurs

Le Moteur de conteneur effectue des appels aux registres de conteneurs via HTTPS. Pour récupérer les images de conteneur du runtime IoT Edge, le nom de domaine complet est mcr.microsoft.com. Le moteur de conteneur se connecte aux autres registres configurés dans le déploiement.

Cette liste de vérification est un point de départ pour les règles de pare-feu :

FQDN (`*` = caractère générique)	Ports TCP sortants	Utilisation
`mcr.microsoft.com`	443	Registre de conteneurs Microsoft
`*.data.mcr.microsoft.com`	443	Point de terminaison de données fournissant la distribution de contenu
`*.cdn.azcr.io`	443	Déployer des modules de la Place de marché sur des appareils
`global.azure-devices-provisioning.net`	443	Accès au service de provisionnement des appareils (facultatif)
`*.azurecr.io`	443	Registres de conteneurs personnels et tiers
`*.blob.core.windows.net`	443	Télécharger les deltas d’image Azure Container Registry à partir du stockage Blob
`*.azure-devices.net`	5671, 8883, 443¹	Accès IoT Hub
`*.docker.io`	443	Accès Docker Hub (facultatif)

¹ Ouvrez le port 8883 pour MQTT sécurisé ou le port 5671 pour AMQP sécurisé. Si vous pouvez uniquement établir des connexions via le port 443, l’un ou l’autre de ces protocoles peut être exécuté via un tunnel WebSocket.

Étant donné que l’adresse IP d’un hub IoT peut être modifiée sans préavis, utilisez toujours le nom de domaine complet pour configurer la liste des autorisations. Pour en savoir plus, consultez Comprendre l’adresse IP de votre hub IoT.

Certaines de ces règles de pare-feu sont héritées d’Azure Container Registry. Pour plus d’informations, consultez Configurer des règles pour accéder à un registre de conteneurs Azure derrière un pare-feu.

Vous pouvez activer les points de terminaison de données dédiés dans votre registre de conteneurs Azure pour éviter l’établissement d’une liste d’autorisation du nom de domaine complet *.blob.core.windows.net. Pour plus d’informations, consultez Activer les points de terminaison de données dédiés.

Remarque

Pour fournir un nom de domaine complet (FQDN) cohérent entre les points de terminaison REST et de données, à partir du 15 juin 2020, le point de terminaison de données Registre de conteneurs Microsoft passe de *.cdn.mscr.io à *.data.mcr.microsoft.com.
Pour plus d’informations, consultez Configuration des règles de pare-feu de client du Registre de conteneurs Microsoft.

Si vous ne souhaitez pas configurer votre pare-feu pour autoriser l’accès aux registres de conteneurs publics, vous pouvez stocker les images dans votre registre de conteneurs privé, comme décrit dans Stocker les conteneurs Runtime dans votre registre privé.

Service d’identité Azure IoT

Le service d’identité IoT fournit des services d’approvisionnement et de chiffrement pour les appareils Azure IoT. Le service d’identité vérifie si la version installée est la dernière version. La vérification utilise les noms de domaine complets suivants pour vérifier la version.

FQDN	Ports TCP sortants	Utilisation
`aka.ms`	443	URL de redirection qui fournit la redirection vers le fichier de version
`raw.githubusercontent.com`	443	Fichier de version du service d’identité hébergé dans GitHub

Configurer la communication via un proxy

Si vos appareils sont destinés à être déployés sur un réseau qui utilise un serveur proxy, ils doivent être en mesure de communiquer via le proxy pour accéder à IoT Hub et aux registres de conteneurs. Pour plus d’informations, voir Configurer un appareil IoT Edge de façon à ce qu’il communique via un serveur proxy.

Définissez le serveur DNS dans les paramètres du moteur de conteneur

Spécifiez le serveur DNS de votre environnement dans les paramètres du moteur de conteneur. Le paramètre du serveur DNS s’applique à tous les modules de conteneur démarrés par le moteur.

Dans le répertoire /etc/docker sur votre appareil, modifiez le fichier daemon.json. Créez le fichier s’il n’existe pas.
Ajoutez la clé dns et définissez l’adresse du serveur DNS sur un service DNS accessible publiquement. Si votre périphérique ne peut pas accéder à un serveur DNS public, utilisez une adresse de serveur DNS accessible dans votre réseau. Par exemple :
```
{
    "dns": ["1.1.1.1"]
}
```

Gestion des solutions

Utile
- Configurer les journaux d’activité et les diagnostics
- Configurer le pilote de journalisation par défaut
- Prendre en compte les tests et les pipelines CI/CD

Configurer les journaux d’activité et les diagnostics

Sous Linux, le démon IoT Edge utilise des journaux comme pilote de journalisation par défaut. Vous pouvez vous servir de l’outil en ligne de commande journalctl pour interroger les journaux d’activité du démon.

Depuis la version 1.2, IoT Edge s’appuie sur plusieurs démons. Si les journaux de chaque démon peuvent être interrogés individuellement avec journalctl, les commandes iotedge system offrent un moyen pratique d’interroger les journaux combinés.

Commande iotedge consolidée :
```
sudo iotedge system logs
```

Commande journalctl équivalente :

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

Lorsque vous testez un déploiement IoT Edge, vous pouvez généralement accéder à vos appareils pour récupérer les journaux d’activité et résoudre les problèmes. Dans un scénario de déploiement, vous n’avez pas forcément cette option. Réfléchissez à la façon dont vous allez collecter des informations sur vos appareils en production. Il est possible d’utiliser un module de journalisation, par exemple, logspout-loganalytics, qui recueille des informations auprès des autres modules et les envoie vers le cloud. Vous pouvez également concevoir votre propre module de journalisation.

Configurer le pilote de journalisation par défaut

Par défaut, le moteur de conteneur Moby ne définit pas de limites de taille pour le journal de conteneur. Au fil du temps, cela peut amener l’appareil à se remplir de journaux et à manquer d’espace disque. Configurez votre moteur de conteneur pour utiliser le pilote de journalisation local comme mécanisme de journalisation. Le pilote de journalisation Local offre une limite de taille de journal par défaut, effectue une rotation des journaux par défaut et utilise un format de fichier plus efficace qui permet d’éviter l’épuisement de l’espace disque. Vous pouvez aussi choisir d’utiliser différents pilotes de journalisation et de définir des limites de taille différentes en fonction de vos besoins.

Option : Configurer le pilote de journalisation par défaut pour tous les modules de conteneur

Vous pouvez configurer votre moteur de conteneur pour utiliser un pilote de journalisation spécifique en définissant la valeur de log driver sur le nom du pilote de journal dans le fichier daemon.json. L’exemple suivant définit le pilote de journalisation par défaut sur le pilote de journal local (recommandé).

{
    "log-driver": "local"
}

Vous pouvez également configurer vos clés log-opts pour utiliser les valeurs appropriées dans le fichier daemon.json. L’exemple suivant définit le pilote de journal sur local et définit les options max-size et max-file.

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

Ajoutez ces informations dans un fichier nommé daemon.json et placez-le à l’emplacement suivant :

/etc/docker/

Vous devez redémarrer le moteur de conteneur pour que les modifications entrent en vigueur.

Option : Ajuster les paramètres de journal pour chaque module de conteneur

Vous pouvez le faire dans createOptions au sein de chaque module. Par exemple :

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

Options supplémentaires sur les systèmes Linux

Configurez le moteur de conteneur pour envoyer des journaux au journal systemd en définissant journald comme pilote de journalisation par défaut.
Supprimez régulièrement les anciens journaux d’activité de votre appareil en installant un outil logrotate. Utilisez la spécification de fichier suivante :
```
/var/lib/docker/containers/*/*-json.log{
     copytruncate
     daily
     rotate7
     delaycompress
     compress
     notifempty
     missingok
}
```

Prendre en compte les tests et les pipelines CI/CD

Pour maximiser l’efficacité du scénario de déploiement IoT Edge, intégrez votre déploiement de production dans vos pipelines de tests et CI/CD. Azure IoT Edge prend en charge plusieurs plateformes CI/CD, notamment Azure DevOps. Pour plus d’informations, voir Intégration continue et déploiement continu sur Azure IoT Edge.

Considérations de sécurité

Important
- Gérer l’accès au registre de conteneurs
- Limiter l’accès du conteneur aux ressources hôtes

Gérer l’accès au registre de conteneurs

Avant de déployer des modules sur des appareils IoT Edge en production, veillez à contrôler l’accès à votre registre de conteneurs pour éviter que des intrus ne puissent accéder à vos images conteneur ou les modifier. Utilisez un registre de conteneurs privé pour gérer les images conteneur.

Dans les tutoriels et autres documents, nous prescrivons d’utiliser les mêmes informations d’identification de registre de conteneur sur l’appareil IoT Edge que sur l’ordinateur de développement. Ces instructions, qui ne sont destinées qu’à aider à configurer plus facilement les environnements de test et de développement, ne doivent pas être suivies dans un scénario de production.

Pour un accès plus sécurisé à votre Registre, vous avez le choix entre plusieurs options d’authentification. Une authentification populaire et recommandée consiste à utiliser un principal de service Active Directory adapté aux applications ou aux services pour extraire des images de conteneur de manière automatisée ou sans assistance (headless/sans périphérique de contrôle), comme le font les appareils IoT Edge. Une autre option consiste à utiliser des jetons délimités par le référentiel, qui vous permettent de créer des identités longues ou courtes qui existent uniquement dans l’instance Azure Container Registry dans laquelle elles ont été créées et d’étendre l’accès au niveau du référentiel.

Pour créer un principal de service, exécutez les deux scripts comme décrit dans Créer un principal de service. Ces scripts effectuent les tâches suivantes :

Le premier script crée le principal du service. Il génère l’ID du principal de service et le mot de passe du principal de service. Conservez ces valeurs en lieu sûr dans vos dossiers.
Le deuxième script crée des attributions de rôles à accorder au principal de service, qui peuvent être exécutées ultérieurement si nécessaire. Nous vous recommandons d’appliquer le rôle d’utilisateur acrPull pour le paramètre role. Pour obtenir la liste des rôles, consultez Autorisations et rôles Azure Container Registry.

Pour vous authentifier à l’aide d’un principal de service, fournissez l’ID et le mot de passe du principal de service que vous avez obtenus grâce au premier script. Spécifiez ces informations d’identification dans le manifeste de déploiement.

Pour le nom d’utilisateur ou l’ID client, spécifiez l’ID du principal de service.
Pour le mot de passe ou la clé secrète client, spécifiez le mot de passe du principal de service.

Pour créer des jetons délimités au référentiel, suivez Créer un jeton délimité au référentiel.

Pour vous authentifier à l’aide de jetons d’étendue de référentiel, indiquez le nom et le mot de passe du jeton que vous avez obtenus après avoir créé votre jeton d’étendue de référentiel. Spécifiez ces informations d’identification dans le manifeste de déploiement.

Pour le nom d’utilisateur, spécifiez le nom d’utilisateur du jeton.
Pour le mot de passe, spécifiez l’un des mots de passe du jeton.

Remarque

Après avoir implémenté une authentification de sécurité renforcée, désactivez le paramètre Utilisateur administrateur afin que l’accès par défaut avec le nom d’utilisateur/le mot de passe ne soit plus possible. Dans le Registre de conteneurs du portail Azure, dans le menu du volet gauche sous Paramètres, sélectionnez Clés d’accès.

Limiter l’accès du conteneur aux ressources hôtes

Pour équilibrer les ressources hôtes partagées entre les modules, nous vous recommandons de limiter la consommation des ressources par module. Ces limites garantissent qu’un module ne peut pas consommer trop de mémoire ou d’utilisation du processeur et empêchent d’autres processus de s’exécuter sur l’appareil. La plateforme IoT Edge ne limite pas les ressources pour les modules par défaut, car la connaissance de la quantité de ressources qu’un module donné doit exécuter de façon optimale nécessite un test.

Docker fournit des contraintes que vous pouvez utiliser pour limiter les ressources telles que la mémoire et l’utilisation de l’UC. Pour plus d’informations, consultez Options d’exécution avec la mémoire, processeurs et GPU.

Ces contraintes peuvent être appliquées à des modules individuels à l’aide des options de création des manifestes de déploiement. Pour en savoir plus, consultez Guide pratique pour configurer les options de création de conteneur pour les modules IoT Edge.

Étapes suivantes

En savoir plus sur le déploiement automatique IoT Edge.
Découvrez comment IoT Edge prend en charge l’intégration continue et le déploiement continu.

Partage via

Préparer le déploiement en production d’une solution IoT Edge

Configuration de l’appareil

Installer les certificats de production

Élaborer un plan de gestion des appareils

Moteur de conteneur

Choisir un protocole en amont

Déploiement

Rester cohérent avec le protocole en amont

Configurer le stockage hôte pour les modules système

Réduire l’espace mémoire utilisé par le hub IoT Edge

Ne pas optimiser les performances sur les appareils contraints

Désactiver les protocoles inutilisés

Réduire le temps de stockage des messages

Utiliser des images de module correctes dans les manifestes de déploiement

Ne pas utiliser les versions de débogage des images de module

Gardez à l’esprit les limites de taille du jumeau numérique lors de l’utilisation de modules personnalisés

Configurer la façon dont les mises à jour des modules sont appliquées

Gestion de conteneur

Utiliser des balises pour gérer les versions

Étiquettes pour le runtime IoT Edge

Gérer les volumes

Stocker les conteneurs Runtime dans votre registre privé

Configurer le nettoyage de la mémoire d’image

Mise en réseau

Vérifier la configuration sortante/entrante

Autoriser les connexions à partir d’appareils IoT Edge

Registres de conteneurs

Service d’identité Azure IoT

Configurer la communication via un proxy

Définissez le serveur DNS dans les paramètres du moteur de conteneur

Gestion des solutions

Configurer les journaux d’activité et les diagnostics

Configurer le pilote de journalisation par défaut

Option : Configurer le pilote de journalisation par défaut pour tous les modules de conteneur

Option : Ajuster les paramètres de journal pour chaque module de conteneur

Options supplémentaires sur les systèmes Linux

Prendre en compte les tests et les pipelines CI/CD

Considérations de sécurité

Gérer l’accès au registre de conteneurs

Limiter l’accès du conteneur aux ressources hôtes

Étapes suivantes

Commentaires

Ressources supplémentaires