Partager via

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

S’applique à :IoT Edge 1.5 coche IoT Edge 1.5

Important

IoT Edge 1.5 LTS est la version prise en charge. IoT Edge 1.4 LTS est en fin de vie depuis le 12 novembre 2024. Si vous utilisez une version antérieure, consultez l’article Mettre à jour IoT Edge.

Lorsque vous êtes prêt à prendre votre solution IoT Edge du développement en production, assurez-vous qu’elle est configurée pour des performances continues.

Toutes les informations contenues dans cet article ne sont pas tout aussi importantes. Pour vous aider à hiérarchiser, chaque section commence par des listes qui divisent le travail en deux groupes : important à terminer avant d’aller en production ou utile à connaître.

Device configuration

Les appareils IoT Edge peuvent être n’importe quoi d’un Raspberry Pi à un ordinateur portable ou d’une machine virtuelle s’exécutant sur un serveur. Vous pouvez accéder à l’appareil physiquement ou via une connexion virtuelle, ou il peut être isolé pendant des périodes prolongées. Dans les deux cas, assurez-vous qu’il est configuré pour fonctionner correctement.

  • 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 maintenu par Canonical et pris en charge pour les scénarios de production.

  • Helpful

    • 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 de configuration. Pour le développement et le test, le runtime IoT Edge crée des certificats temporaires si aucun certificat n’est déclaré dans le fichier de configuration. Toutefois, ces certificats temporaires expirent après trois mois et ne sont pas sécurisés pour les scénarios de production. Pour les scénarios de production, fournissez votre propre certificat d’autorité de certification Edge, qu’il s’agisse d’une autorité de certification auto-signée ou 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 plus d’informations sur l’installation de certificats sur un appareil IoT Edge et leur référencement à partir du fichier de configuration, consultez Gérer le certificat sur un appareil IoT Edge.

Élaborer un plan de gestion des appareils

Avant de mettre un appareil en production, réfléchissez à la façon dont vous allez gérer les futures mises à jour. Pour un appareil IoT Edge, la liste des composants à mettre à jour peut inclure :

  • Device firmware
  • Bibliothèques du système d’exploitation
  • Moteur de conteneur, comme Moby
  • IoT Edge
  • CA certificates

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.

D’autres façons de mettre à jour IoT Edge nécessitent 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.

Container engine

Un moteur de conteneur est requis pour n’importe quel appareil IoT Edge. Le moteur Moby est pris en charge en production. Si vous utilisez des snaps Ubuntu Core, le snap Docker est maintenu par Canonical et pris en charge pour les scénarios de production. D’autres moteurs de conteneur, comme Docker, fonctionnent avec IoT Edge et il est possible d’utiliser ces moteurs pour le 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 est AMQP, mais vous souhaiterez peut-être le modifier en fonction de la configuration de votre 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 votre appareil IoT Edge se trouve derrière un serveur proxy qui bloque les ports AMQP, vous devrez peut-être configurer l’agent IoT Edge pour utiliser AMQP sur WebSocket (AMQPWS) pour établir la connexion initiale à IoT Hub.

Une fois que votre appareil IoT Edge se connecte, continuez à configurer la variable UpstreamProtocol pour les deux modules d’exécution dans les déploiements futurs. Par exemple, consultez Configurer un appareil IoT Edge pour communiquer via un serveur proxy.

Deployment

  • Helpful
    • 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 :

  1. L’image mise à jour est téléchargée
  2. Le module en cours d’exécution est arrêté
  3. Une nouvelle instance de module est démarrée
  4. 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"
                        }
                    ...

Container management

  • Important
    • Utiliser des balises pour gérer les versions
    • Manage volumes
  • Helpful
    • 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.

Manage 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é.

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

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

    docker images

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

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

  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.

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

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

  8. 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>"

  9. Enregistrez vos changements et quittez l’éditeur de texte.

  10. Appliquez le changement de configuration IoT Edge.

    sudo iotedge config apply

    Votre runtime IoT Edge redémarre.

Pour plus d'informations, consultez les pages suivantes :

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.

Parameter Description Required Default value
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. Optional 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.		 Optional 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.		 Optional 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. Si l’appareil n’est pas en ligne, la tâche de nettoyage ne sera pas exécutée. La tâche sera exécutée à la prochaine heure de nettoyage prévue si l’appareil est en ligne à ce moment-là. Optional 00:00

Networking

  • Helpful
    • Vérifier la configuration sortante/entrante
    • Autoriser les connexions à partir d’appareils IoT Edge
    • Configurer la communication via un proxy
    • Définir le serveur DNS dans les paramètres du moteur du 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.

Container registries

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 Usage
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, 4431 Accès IoT Hub
*.docker.io 443 Accès Docker Hub (facultatif)

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

Note

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 Usage
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éfinir le serveur DNS dans les paramètres du moteur du 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.

  1. Dans le répertoire /etc/docker sur votre appareil, modifiez le fichier daemon.json. Créez le fichier s’il n’existe pas.

  2. Ajoutez la clé dns et définissez l’adresse du serveur DNS sur un service DNS accessible publiquement. Si votre appareil edge ne peut pas accéder à un serveur DNS public, utilisez une adresse de serveur DNS accessible dans votre réseau. For example:

    {
    "dns": ["1.1.1.1"]
}

Solution management

  • Helpful
    • 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. Utilisez l’outil journalctl en ligne de commande pour interroger les journaux du démon.

Depuis la version 1.2, IoT Edge s’appuie sur plusieurs démons. Bien que vous puissiez interroger les journaux de chaque démon individuellement avec journalctl, utilisez les commandes iotedge system pour 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 accédez généralement à 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 peut-être pas cette option. Réfléchissez à la façon dont vous collecterez des informations sur vos appareils en production. L’une des options consiste à utiliser un module de journalisation qui collecte des informations à partir d’autres modules et l’envoie au cloud. Par exemple, utilisez logspout-loganalytics ou concevez le vôtre.

Configurer le pilote de journalisation par défaut

Par défaut, le moteur de conteneur Moby ne définit pas de limites de taille de journal de conteneur. Au fil du temps, cela peut entraîner le remplissage de l’appareil par les journaux d’activité et un espace disque insuffisant. Configurer votre moteur de conteneur pour utiliser le pilote de journalisation local comme mécanisme de journalisation. Le local pilote de journalisation offre une limite de taille de journal par défaut, effectue la rotation des journaux par défaut et utilise un format de fichier plus efficace, ce qui permet d’éviter l’épuisement de l’espace disque. Vous pouvez également utiliser différents pilotes de journalisation et définir diverses limites de taille en fonction de vos besoins.

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

Définissez votre moteur de conteneur pour utiliser un pilote de journalisation spécifique en assignant au log driver 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 ou ajoutez ces informations à un fichier nommé daemon.json et placez-le à l’emplacement suivant :

  • /etc/docker/

Redémarrez le moteur de conteneur pour appliquer les changements.

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

Définissez ces options dans les createOptions de chaque module. For example:

"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 systemdjournal en définissant journald en tant que 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 le déploiement IoT Edge le plus efficace, intégrez votre déploiement de production dans vos pipelines de test 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.

Security considerations

  • 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 de production, veillez à contrôler l’accès à votre registre de conteneurs afin que les externes ne puissent pas accéder ou modifier vos images conteneur. Utilisez un registre de conteneurs privé pour gérer les images conteneur.

Dans les didacticiels et d’autres documents, nous vous informons d’utiliser les mêmes informations d’identification de registre de conteneurs sur votre appareil IoT Edge que sur votre ordinateur de développement. Ces instructions vous aident à configurer des environnements de test et de développement plus facilement et ne sont pas destinés à une utilisation en production.

Pour un accès plus sécurisé à votre registre, choisissez parmi plusieurs options d’authentification. L'utilisation d'un principal de service Active Directory est une méthode populaire et recommandée pour les applications ou les services afin de télécharger automatiquement et sans intervention humaine des images conteneur, comme c'est le cas pour les appareils IoT Edge. Vous pouvez également utiliser des jetons délimités par un référentiel, ce qui vous permet de créer des identités longues ou de courte durée qui existent uniquement dans Azure Container Registry où vous les créez et vous étendez l’accès au niveau du référentiel.

Pour créer un principal de service, exécutez les deux scripts décrits dans la création d’un principal de service. Ces scripts effectuent les opérations suivantes :

  • Le premier script crée le principal du service. Il affiche 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ôle à octroyer au principal de service. Exécutez-la par la suite si nécessaire. Utilisez le rôle d’utilisateur acrPull pour le role paramètre. 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 de principal de service et les informations d’identification de mot de passe du premier script 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élimités par le référentiel, fournissez le nom du jeton et les informations d’identification de mot de passe que vous obtenez après avoir créé votre jeton délimité par le référentiel 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.

Note

Après avoir implémenté une authentification de sécurité améliorée, désactivez le paramètre utilisateur Administrateur afin que l’accès par défaut au nom d’utilisateur et au mot de passe ne soit pas disponible. Vous trouverez le paramètre de votre registre de conteneurs dans le portail Azure, 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, définissez des limites sur l’utilisation des ressources pour chaque module. Ces limites permettent de s’assurer qu’un module ne peut pas utiliser trop de mémoire ou d’UC et empêcher les autres processus de s’exécuter sur l’appareil. Par défaut, la plateforme IoT Edge ne limite pas les ressources pour les modules, car vous devez tester la quantité de ressources dont un module a besoin pour s’exécuter correctement.

Docker vous permet de limiter les ressources telles que la mémoire et l’utilisation du processeur. Pour plus d’informations, consultez Options d’exécution avec la mémoire, processeurs et GPU.

Vous pouvez appliquer ces contraintes à des modules individuels à l’aide des options de création dans les 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.

Next steps

  • Last updated on