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

S’applique à : IoT Edge 1.1

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

• 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 d’appareil, 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 d’appareil, voir 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 (préversion) 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.

Utiliser Moby comme moteur de conteneur

Un moteur de conteneur fait partie des prérequis de tous les appareils IoT Edge. Seul le moteur Moby est pris en charge en 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, remplacera les paramètres et vous empêchera 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).

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. Ce sont des suffixes comme 1.1, ajoutés à la fin d’un référentiel de conteneur. Exemple : mcr.microsoft.com/azureiotedge-agent:1.1. 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îtra comme une nouvelle version et extraira 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.1 est mise à jour lorsqu’une nouvelle mise en production pointe vers la dernière version 1.1.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.1.0 ne change 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 très 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.1
   
   # Pull edgeHub image
   docker pull mcr.microsoft.com/azureiotedge-hub:1.1
   

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.1
   
   # Retag your edgeHub image
   docker tag <my-image-id> <registry-name/server>/azureiotedge-hub:1.1
   

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

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

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 l’article suivant :

• Configurer l’agent IoT Edge
• Agent Azure IoT Edge
• Hub Azure IoT Edge

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

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.

Par ailleurs, 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 :

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

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

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.

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.

Sous Windows, le démon IoT Edge utilise les diagnostics PowerShell. Interrogez les journaux d’activité du démon avec Get-IoTEdgeLog. Les modules IoT Edge utilisent par défaut le pilote JSON pour la journalisation.

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

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 :

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 par le référentiel, veuillez suivre Création d’un jeton d’étendue de 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.

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.