Partager via


Comprendre les déploiements automatiques d'IoT Edge pour des appareils uniques ou à grande échelle

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

Important

IoT Edge 1.5 LTS est la version prise en charge. IoT Edge 1,4 LTS a atteint la fin de vie le 12 novembre 2024. Si vous utilisez une version antérieure, consultez Update IoT Edge.

Les déploiements automatiques et le déploiement en couches vous aident à gérer et configurer des modules sur un grand nombre d’appareils IoT Edge.

Azure IoT Edge fournit deux façons de configurer les modules à exécuter sur des appareils IoT Edge. La première consiste à déployer les modules sur la base de chaque appareil. Vous créez un manifeste de déploiement, puis vous l’appliquez à un appareil donné par nom. La seconde méthode consiste à déployer automatiquement les modules sur tous les appareils inscrits répondant à un ensemble de conditions définies. Vous créez un manifeste de déploiement, puis définissez les appareils auxquels il s’applique en fonction des indicateurs dans le jumeau d'appareil.

Vous ne pouvez pas combiner les déploiements automatiques et par appareil. Une fois que vous commencez à cibler des appareils IoT Edge avec des déploiements automatiques (avec ou sans déploiements en couches), les déploiements par appareil ne sont plus pris en charge.

Cet article se concentre sur la configuration et la surveillance des flottes d’appareils, appelées collectivement IoT Edge déploiements automatiques.

Les étapes de déploiement de base sont les suivantes :

  1. Un opérateur définit un manifeste de déploiement décrivant un ensemble de modules, ainsi que les appareils cibles.
  2. Par conséquent, le service IoT Hub communique avec tous les appareils ciblés pour les configurer avec les modules déclarés.
  3. Le service IoT Hub récupère l’état des appareils IoT Edge et les met à la disposition de l’opérateur. Par exemple, un opérateur voit quand un appareil Edge n’est pas correctement configuré ou si un module échoue en cours de runtime.
  4. À tout moment, quand les appareils IoT Edge nouvellement ciblés sont en ligne et se connectent avec IoT Hub, ils sont configurés pour le déploiement.

Cet article décrit chaque composant impliqué dans la configuration et la surveillance d’un déploiement. Pour obtenir une procédure pas à pas de création et de mise à jour d’un déploiement, consultez Deploy IoT Edge modules à grande échelle à l’aide du portail Azure.

Déploiement

Un déploiement automatique IoT Edge assigne des images de module IoT Edge à exécuter en tant qu’instances sur un ensemble ciblé d’appareils IoT Edge. Le déploiement automatisé configure un manifeste de déploiement IoT Edge pour inclure une liste de modules avec les paramètres d’initialisation correspondants. Un déploiement peut être affecté à un appareil unique (basé sur l’ID de l’appareil) ou à un groupe d’appareils (basé sur des balises). Une fois qu’un appareil IoT Edge reçoit un manifeste de déploiement, il télécharge et installe les images conteneur à partir des référentiels de conteneurs respectifs et les configure en conséquence. Une fois qu’un déploiement est créé, un opérateur peut surveiller l’état de déploiement pour voir si les appareils ciblés sont configurés correctement.

Seuls les appareils IoT Edge peuvent être configurés avec un déploiement. L’appareil destiné à recevoir le déploiement doit satisfaire aux prérequis suivants :

  • Le système d’exploitation de base
  • Un système de gestion de conteneur, comme Moby ou Docker
  • Approvisionnement du runtime IoT Edge

Manifeste de déploiement

Un manifeste de déploiement est un document JSON qui décrit les modules à configurer sur les appareils IoT Edge ciblés. Il contient les métadonnées de configuration de tous les modules, y compris les modules système requis (en particulier l’agent IoT Edge et le hub IoT Edge).

Les métadonnées de configuration pour chaque module incluent :

  • Version
  • Type
  • État (par exemple, En cours d’exécution ou arrêté)
  • Stratégie de redémarrage
  • Registre d’images et de conteneurs
  • Itinéraires pour les données en entrée et en sortie

Si l’image du module est stockée dans un registre de conteneurs privé, l’agent IoT Edge contient les informations d’identification du Registre.

Condition cible

La condition d’appareil cible est évaluée en permanence sur toute la durée de vie du déploiement. Les nouveaux appareils qui répondent aux exigences sont inclus. Tous les appareils existants qui n’y satisfont plus sont supprimés. Le déploiement est réactivé si le service détecte une modification de la condition cible.

Par exemple, vous disposez d’un déploiement avec une condition cible tags.environment = 'prod'. Lorsque vous lancez le déploiement, il y a 10 appareils de production. Les modules sont correctement installés sur ces 10 appareils. L’état de l’agent IoT Edge affiche 10 appareils totaux, 10 réponses réussies, 0 réponses d’échec et 0 réponses en attente. Maintenant, vous ajoutez cinq autres appareils avec tags.environment = 'prod'. Le service détecte la modification et l’état de l’agent IoT Edge affiche désormais 15 appareils, 10 réponses réussies, 0 réponses d’échec et 5 réponses en attente pendant son déploiement sur les cinq nouveaux appareils.

Si un déploiement n’a aucune condition cible, il n’est appliqué à aucun appareil.

Utilisez une condition booléenne sur des balises de jumeaux d’appareils, propriétés signalées de jumeaux d'appareils ou deviceId pour sélectionner les appareils cibles. Si vous souhaitez utiliser une condition avec des balises, vous devez ajouter une section "tags":{} dans le jumeau d’appareil au même niveau que les propriétés. Pour plus d’informations sur les balises dans les jumeaux d’appareil, voir Comprendre et utiliser les jumeaux d’appareil dans IoT Hub. Pour plus d’informations sur les opérations de requête, consultez les opérateurs de langage de requête du IoT Hub et la fonction IS_DEFINED.

Exemples de conditions cibles :

  • deviceId =’linuxprod1’
  • tags.environment =’prod’
  • tags.environment = ’prod’ AND tags.location = ’westus’
  • tags.environment = ’prod’ OR tags.location = ’westus’
  • tags.operator = 'John' ET tags.environment = 'prod' ET NON deviceId = 'linuxprod1'
  • properties.reported.devicemodel = '4000x'
  • IS_DEFINED(tags.remote)
  • NOT IS_DEFINED(tags.location.building)
  • tags.environment != null
  • [aucun]

Prenez en compte les contraintes suivantes lorsque vous créez une condition cible :

  • Dans le jumeau d’appareil, vous pouvez uniquement créer une condition cible en utilisant les balises, les propriétés signalées ou l'identifiant de périphérique.
  • Les guillemets doubles ne sont autorisés nulle part dans la condition cible. Utilisez des guillemets simples.
  • Les guillemets simples représentent les valeurs de la condition cible. Par conséquent, vous devez échapper le guillemet simple avec un autre guillemet simple s’il fait partie du nom de l’appareil. Par exemple, pour cibler un appareil appelé operator'sDevice, écrire deviceId='operator''sDevice'.
  • Les chiffres, les lettres et les caractères suivants sont autorisés dans les valeurs de condition cible : "()<>@,;:\\"/?={} \t\n\r.
  • Les caractères suivants ne sont pas autorisés dans les clés de condition cible :/;.

Priorité

Une priorité définit si un déploiement doit être appliqué à un appareil ciblé par rapport à d’autres déploiements. Une priorité de déploiement est un entier positif dans la plage de 0 à 2 147 483 647. Les nombres supérieurs désignent une priorité plus élevée. Si plusieurs déploiements ciblent un appareil IoT Edge, le déploiement avec la priorité la plus élevée s’applique. Les déploiements avec une priorité inférieure ne sont pas appliqués, ni fusionnés. Si un périphérique est ciblé par au moins deux déploiements de priorité égale, c’est le déploiement créé le plus récemment (déterminé par l’horodatage de création) qui s’applique.

Étiquettes

Les étiquettes sont des paires clé-valeur de type chaîne que vous pouvez utiliser pour filtrer et grouper les déploiements. Un déploiement peut avoir plusieurs étiquettes. Les étiquettes sont facultatives et n'affectent pas la configuration des appareils IoT Edge.

Métriques

Par défaut, tous les déploiements rapportent quatre métriques :

  • Targeted affiche les appareils IoT Edge qui correspondent à la condition de ciblage du déploiement.
  • Applied montre les appareils IoT Edge ciblés qui ne sont pas ciblés par un autre déploiement de priorité supérieure.
  • Reporting Success affiche les appareils IoT Edge qui signalent leurs modules comme étant déployés avec succès.
  • Reporting Failure affiche les appareils IoT Edge qui signalent un ou plusieurs modules comme étant déployés sans succès. Pour examiner l’erreur plus en détail, connectez-vous à distance à ces appareils et consultez les fichiers journaux.

En outre, vous pouvez définir vos propres mesures personnalisées pour faciliter la surveillance et la gestion du déploiement.

Les métriques fournissent des décomptes récapitulatives des différents états que les appareils peuvent renvoyer suite à l’application d’une configuration de déploiement. Les métriques peuvent interroger les propriétés signalées du jumeau de module edgeHub, comme lastDesiredStatus ou lastConnectTime.

Par exemple :

SELECT deviceId FROM devices
  WHERE properties.reported.lastDesiredStatus.code = 200

L'ajout de vos propres métriques est facultatif et n'affecte pas la configuration réelle des appareils IoT Edge.

Déploiement en couches

Les déploiements en couches sont des déploiements automatiques qui peuvent être combinés afin de réduire le nombre de déploiements uniques à créer. Les déploiements en couches s'avèrent utiles dans les scénarios où les mêmes modules sont réutilisés selon différentes combinaisons dans de nombreux déploiements automatiques.

Les déploiements en couches possèdent les mêmes composants de base que n’importe quel déploiement automatique. Ils ciblent les appareils en fonction des balises présentes dans les jumeaux d’appareil et fournissent les mêmes fonctionnalités en termes d’étiquettes, de métriques et de rapports d’état. Les déploiements en couches ont également des priorités attribuées. Au lieu d’utiliser la priorité pour déterminer le déploiement appliqué à un appareil, la priorité détermine le classement de plusieurs déploiements sur un appareil. Par exemple, si deux déploiements en couches ont un module ou un itinéraire portant le même nom, le déploiement en couches avec la priorité supérieure est appliqué alors que la priorité inférieure est remplacée.

Les modules d’exécution du système, appelés edgeAgent et edgeHub, ne sont pas configurés dans le cadre d’un déploiement en couches. Tout appareil IoT Edge ciblé par un déploiement par couches nécessite d’abord un déploiement automatique standard. Ce déploiement automatique fait office de base sur laquelle ajouter les déploiements en couches.

Un appareil IoT Edge peut appliquer un seul et un seul déploiement automatique standard, mais il peut appliquer plusieurs déploiements automatiques en couches. Les déploiements en couches ciblant un appareil doivent avoir une priorité plus élevée que le déploiement automatique pour cet appareil.

Prenons pour exemple une entreprise gérant des bâtiments. L’entreprise a développé des modules IoT Edge pour collecter des données à partir de caméras de sécurité, de capteurs de mouvement et d’ascenseurs. Cela étant, tous ses bâtiments ne peuvent pas utiliser les trois modules. Avec les déploiements automatiques standard, l’entreprise doit créer des déploiements individuels pour toutes les combinaisons de modules dont ses bâtiments ont besoin.

Capture d’écran montrant que les déploiements automatiques standard doivent prendre en charge chaque combinaison de modules.

Toutefois, lorsque la société bascule vers des déploiements automatiques en couches, elle peut créer les mêmes combinaisons de modules pour ses bâtiments, tout en réduisant les déploiements à gérer. Chaque module possède son propre déploiement en couches, et les balises des appareils identifient les modules ajoutés à chaque bâtiment.

Capture d’écran montrant comment les déploiements automatiques en couches simplifient les scénarios où les mêmes modules sont combinés de différentes façons.

Configuration de jumeau de module

Lorsque vous travaillez avec des déploiements en couches, vous pouvez, intentionnellement ou autrement, avoir deux déploiements avec le même module ciblant un appareil. Dans ces cas, vous pouvez décider si le déploiement doté d’une priorité plus élevée doit remplacer le jumeau de module ou s’y ajouter. Par exemple, vous pouvez avoir un déploiement qui applique le même module à 100 appareils différents. Toutefois, 10 de ces appareils se trouvent dans des installations sécurisées et ont besoin d’une configuration supplémentaire pour communiquer via des serveurs proxy. Vous pouvez utiliser un déploiement en couches pour ajouter des propriétés de jumeau de module permettant à ces dix appareils de communiquer en toute sécurité, sans remplacer les informations de jumeau de module existantes du déploiement de base.

Vous pouvez ajouter les propriétés de jumeau de module souhaitées dans le manifeste de déploiement. Dans un déploiement standard, vous devez ajouter des propriétés dans la section properties.desired du module jumeau. Dans un déploiement en couches, vous pouvez déclarer un nouveau sous-ensemble de propriétés souhaitées.

Par exemple, dans un déploiement standard, vous pouvez ajouter le module de capteur de température simulé avec les propriétés souhaitées suivantes pour lui indiquer d’envoyer les données à intervalles de 5 secondes :

"SimulatedTemperatureSensor": {
  "properties.desired": {
    "SendData": true,
    "SendInterval": 5
  }
}

Dans un déploiement en couches qui cible certains ou tous ces mêmes appareils, vous pouvez ajouter une propriété qui indique au capteur simulé d’envoyer 1 000 messages, puis d’arrêter. Vous ne souhaitez pas remplacer les propriétés existantes. Vous créez donc une section dans les propriétés souhaitées appelées layeredProperties, qui contient la nouvelle propriété :

"SimulatedTemperatureSensor": {
  "properties.desired.layeredProperties": {
    "StopAfterCount": 1000
  }
}

Un appareil sur lequel les deux déploiements sont appliqués reflète les propriétés suivantes dans le jumeau de module pour le capteur de température simulé :

"properties": {
  "desired": {
    "SendData": true,
    "SendInterval": 5,
    "layeredProperties": {
      "StopAfterCount": 1000
    }
  }
}

Si vous définissez le properties.desired champ du jumeau de module dans un déploiement en couches, properties.desired remplace les propriétés souhaitées pour ce module dans les déploiements de priorité inférieure.

Déploiement progressif

Un déploiement par phases est un processus global dans lequel un opérateur déploie des modifications sur un ensemble élargi d’appareils IoT Edge. L’objectif est d’apporter des modifications progressivement afin de réduire le risque d’effectuer des changements cassants à grande échelle. Les déploiements automatiques permettent de gérer les déploiements par phases sur une flotte d’appareils IoT Edge.

Un déploiement progressif est exécuté dans les phases et étapes suivantes :

  1. Établissez un environnement de tests d’appareils IoT Edge en les approvisionnant et en paramétrant une balise de jumeau d’appareil comme tag.environment='test'. L’environnement de test doit mettre en miroir l’environnement de production que le déploiement cible finalement.
  2. Créez un déploiement comprenant les modules et les configurations souhaités. La condition de ciblage doit viser l’environnement de test de l’appareil IoT Edge.
  3. Validez la nouvelle configuration du module dans l’environnement de test.
  4. Mettez à jour le déploiement pour inclure un sous-ensemble d’appareils de production IoT Edge en ajoutant une nouvelle balise à la condition de ciblage. En outre, vérifiez que la priorité pour le déploiement est supérieure aux autres déploiements actuellement ciblés sur ces appareils.
  5. Vérifiez que le déploiement a réussi sur les appareils IoT Edge ciblés en affichant l’état du déploiement.
  6. Mettez à jour le déploiement afin de cibler tous les appareils de production IoT Edge restants.

Retour arrière

Les déploiements peuvent être restaurés en cas d'erreurs ou de problèmes de configuration. Étant donné qu’un déploiement définit la configuration absolue du module pour un appareil IoT Edge, un déploiement supplémentaire doit également être ciblé sur le même appareil à une priorité inférieure, même si l’objectif est de supprimer tous les modules.

La suppression d’un déploiement ne supprime pas les modules des appareils ciblés. Un autre déploiement doit définir une nouvelle configuration pour les appareils, même s’il s’agit d’un déploiement vide.

Toutefois, la suppression d’un déploiement peut supprimer des modules de l’appareil ciblé s’il s’agissait d’un déploiement en couches. Un déploiement en couches met à jour le déploiement sous-jacent, en ajoutant potentiellement des modules. La suppression d’un déploiement en couches supprime sa mise à jour du déploiement sous-jacent, ce qui peut entraîner potentiellement la suppression de modules.

Par exemple, un appareil a un déploiement de base A et des déploiements en couches O et M qui lui sont appliqués (afin que les déploiements A, O et M soient déployés sur l’appareil). Si le déploiement en couches M est ensuite supprimé, A et O sont appliqués à l’appareil et les modules propres au déploiement M sont supprimés.

Effectuez des retours en arrière dans l’ordre suivant :

  1. Confirmez qu’un deuxième déploiement cible également le même ensemble d’appareils. Si l’objectif du retrait est de supprimer tous les modules, le deuxième déploiement ne devrait inclure aucun module.
  2. Modifiez ou supprimez l’expression de la condition cible du déploiement que vous souhaitez annuler de façon à ce que les appareils ne répondent plus à la condition de ciblage.
  3. Vérifiez que la restauration a réussi en consultant l’état du déploiement.
    • Le déploiement restauré ne doit plus afficher d’état pour les appareils qui ont été restaurés.
    • Le deuxième déploiement doit désormais inclure l’état de déploiement pour les appareils qui ont été restaurés.

Étapes suivantes