Azure IoT et EflowVm : désynchronisation des Auto-Update
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(48, 54%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDG%3C/text%3E%3C/svg%3E)
Deni Gahlinger
25
Points de réputation
Bonjour,
Je souhaite comprendre quel est le flux standard pour activer les mises à jour automatiques sur un Edge Device qui tourne sur une EflowVm.
Pour des raisons de sécurités, nous souhaitons activer les mises à jour automatique sur le Windows (hôte de l'EflowVm). (L'edge device est provisionné avec DPS).
Il y a donc :
- La version de l'EflowVm
- La version des modules qui tournent sur l'Device
- La configuration de la version des modules qui est paramétrée depuis le cloud (Azure).
La version de l'Eflow dépend de l'installation, alors que la version des modules dépend de la configuration qui est sur la resource IotHub sur Azure (donc côté Cloud).
Voici un exemple de ce qu'il se passe lorsque l'EflowVm est mis à jour à par l'auto-update :
| EflowVm | $edgeHub / $edgeAgent version (Device) | $edgeHub / $edgeAgent config (Azure) | Description |
|---|---|---|---|
| 1.4 | 1.4 | 1.4 | L'EflowVm est en version 1.4, les modules essentiels sont configurés sur Azure en version 1.4 également ($edgeAgent, $edgeHub). respectivement mcr.microsoft.com/azureiotedge-agent:1.4 et mcr.microsoft.com/azureiotedge-hub:1.4 |
| 1.5 | 1.4 | 1.4 | Une mise à jour automatique s'exécute côté device : L'EflowVm passe donc en 1.5. |
| 1.5 | 1.4 | 1.4 | A ce stade, il y a un décalage de version, mais qui n'empêche pas l'utilisation du device en l'état. Par contre, il sera impossible d'ajouter des modules ou de modifier des version: unable to process module <module id> add or update as the module identity could not be obtained |
| 1.5 | 1.4 | 1.5 | A partir de là, si l'on reconfigure les desired properties de l'$edgeAgent et $edgeHub (côté Cloud / Azure), pour qu'ils soient en 1.5, ces properties ne seront jamais appliquées côté device, à cause du message précédent. |
Notre workaround :
| EflowVm | $edgeHub / $edgeAgent version (device) | $edgeHub / $edgeAgent config (azure) | Description |
|---|---|---|---|
| 1.4 | 1.4 | 1.4 | Downgrade l'EflowVm à 1.4 |
| 1.4 | 1.4 | 1.5 | Configurer la version de l'$edgeAgent / edgeHub à 1.5 côté sur Azure. |
| 1.4 | 1.5 | 1.5 | La nouvelle configuration des $edgeAgent et $edgeHub sera appliquée. |
| 1.5 | 1.5 | 1.5 | Mise à jour l'Eflow en version 1.5. |
Si je résume, configurer et appliquer la config de l'$edgeAgent et $edgeHub doivent être faits avant que la mise à jour automatique ait été faite.
Ce qui implique deux questions :
- Quel est le flux standard pour un
EflowVmen production ? ça me parait étrange qu'il y ait ces manipulations de downgrade à faire. - Y a-t-il moyen d'automatiser l'auto Update pour qu'il soit correctement géré sans problème de désynchronisation entre l'
EflowVm, les modules et lesdesired properties?
Windows pour les entreprises | Windows pour IoT
Connectez-vous pour répondre