Préparation à l'utilisation du Catalogue de Logiciels - AWS IoT Core

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Préparation à l'utilisation du Catalogue de Logiciels

La section suivante fournit une vue d'ensemble du cycle de vie des versions du package et des informations sur l'utilisation du catalogue de packages AWS IoT Device Management logiciels.

Cycle de vie des versions du package

Une version d'un package peut évoluer selon les états du cycle de vie suivants : draftpublished, et deprecated. Cela peut aussi l'être deleted.

Le cycle de vie de la version du package avec le brouillon, la publication et la version obsolète. Il peut également être supprimé.
  • Ébauche

    Lorsque vous créez une version de package, elle est dans un draft état. Cet état indique que le package logiciel est en cours de préparation ou qu'il est incomplet.

    Tant que la version du package est dans cet état, vous ne pouvez pas la déployer. Vous pouvez modifier la description, les attributs et les balises de la version du package.

    Vous pouvez effectuer la transition d'une version de package draft existante published ou existante en deleted utilisant la console, ou en exécutant des opérations d'DeletePackageVersionAPI UpdatePackageVersionou d'API.

  • Publié

    Lorsque la version de votre package est prête à être déployée, passez de la version du package à un published état. Dans cet état, vous pouvez choisir d'identifier la version du package comme version par défaut en modifiant le package logiciel dans la console ou via l'opération UpdatePackageAPI. Dans cet état, vous ne pouvez modifier que la description et les balises.

    Vous pouvez effectuer la transition d'une version de package published existante deprecated ou existante en deleted utilisant la console ou en exécutant des opérations d'DeletePackageVersionAPI UpdatePackageVersionou d'API.

  • Obsolète

    Si une nouvelle version de package est disponible, vous pouvez transférer les versions antérieures de package vers deprecated. Vous pouvez toujours déployer des tâches avec une version de package obsolète. Vous pouvez également nommer une version de package obsolète comme version par défaut et modifier uniquement la description et les balises.

    Envisagez de transférer la version d'un package vers une version obsolète, mais que vous avez toujours des appareils sur le terrain qui utilisent l'ancienne version ou que vous devez la maintenir en raison d'une dépendance au deprecated moment de l'exécution.

    Vous pouvez effectuer la transition d'une version de package deprecated existante published ou existante en deleted utilisant la console ou en exécutant des opérations d'DeletePackageVersionAPI UpdatePackageVersionou d'API.

  • Supprimé

    Lorsque vous n'avez plus l'intention d'utiliser une version de package, vous pouvez la supprimer à l'aide de la console ou en lançant l'opération DeletePackageVersionAPI.

    Note

    Si vous supprimez une version de package alors que des tâches en attente y font référence, vous recevrez un message d'erreur lorsque la tâche sera terminée avec succès et que vous tenterez de mettre à jour l'ombre réservée nommée.

    Si la version du package logiciel que vous souhaitez supprimer est nommée version du package par défaut, vous devez d'abord mettre à jour le package pour nommer une autre version par défaut ou laisser le champ anonyme. Vous pouvez le faire à l'aide de la console ou de l'opération UpdatePackageVersionAPI. (Pour supprimer une version de package nommée par défaut, définissez le unsetDefaultVersionparamètre sur true lorsque vous lancez l'opération UpdatePackaged'API).

    Si vous supprimez un package logiciel via la console, toutes les versions du package associées à ce package sont supprimées, sauf si l'une d'entre elles est désignée comme version par défaut.

Conventions de dénomination des versions du package

Lorsque vous nommez des versions de package, il est important de planifier et d'appliquer une stratégie de dénomination logique afin que vous et les autres puissiez facilement identifier la dernière version du package et la progression des versions. Vous devez fournir un nom de version lors de la création de la version du package, mais la stratégie et le format dépendent en grande partie de votre analyse de rentabilisation.

À titre de bonne pratique, nous vous recommandons d'utiliser le format de versionnement SemVersémantique. Par exemple, 1.2.31 se trouve la version majeure pour les modifications fonctionnellement incompatibles, 2 la version majeure pour les modifications fonctionnellement compatibles et 3 la version corrective (pour les corrections de bogues). Pour plus d'informations, veuillez consulter la rubrique Gestion des versions sémantique 2.0.0. Pour plus d'informations sur les exigences relatives au nom de version du package, consultez VersionName dans le guide de référence de l' AWS IoT API.

Version par défaut

La définition d'une version par défaut est facultative. Vous pouvez ajouter ou supprimer des versions de package par défaut. Vous pouvez également déployer une version de package qui n'est pas nommée version par défaut.

Lorsque vous créez une version de package, elle est placée dans un draft état et ne peut pas être nommée version par défaut tant que vous n'avez pas fait passer la version du package à la version publiée. Le Catalogue de Logiciels ne sélectionne pas automatiquement une version par défaut ni ne met à jour une version de package plus récente par défaut. Vous devez nommer intentionnellement la version du package que vous choisissez via la console ou en lançant l'opération UpdatePackageVersiond'API.

Attributs de version

Les attributs de version et leurs valeurs contiennent des informations importantes sur les versions de vos packages. Nous vous recommandons de définir des attributs généraux pour un package ou une version de package. Par exemple, vous pouvez créer une paire nom-valeur pour la plate-forme, l'architecture, le système d'exploitation, la date de sortie, l'auteur ou l'URL Amazon S3.

Lorsque vous créez une AWS IoT tâche avec un document de tâche, vous pouvez également choisir d'utiliser une variable de substitution ($parameter) qui fait référence à la valeur d'un attribut. Pour plus d'informations, voir Préparation AWS IoT des tâches.

Les attributs de version utilisés dans les versions de package ne seront pas automatiquement ajoutés à l'ombre nommée réservée et ne peuvent pas être indexés ou interrogés directement via Fleet Indexing. Pour indexer ou interroger les attributs de version d'un package via Fleet Indexing, vous pouvez renseigner l'attribut de version dans l'ombre nommée réservée.

Nous recommandons que le paramètre d'attribut de version figurant dans le périphérique de capture d'ombres réservé indique les propriétés, telles que le système d'exploitation et l'heure d'installation. Ils peuvent également être indexés et interrogés via Fleet Indexing.

Les attributs de version ne sont pas tenus de respecter une convention de dénomination spécifique. Vous pouvez créer des paires nom-valeur pour répondre aux besoins de votre entreprise. La taille combinée de tous les attributs d'une version de package est limitée à 3KB. Pour plus d'informations, veillez consultez Software Package Catalog software package and package versions limits.

Activation de l'indexation AWS IoT de la flotte

Vous devez activer l'indexation de la flotte pour le Catalogue de Logiciels afin de créer ou de mettre à jour des packages logiciels et des versions de packages. L'indexation des flottes fournit un support qui permet de regrouper AWS IoT les objets par le biais de groupes d'objets dynamiques filtrés par version. Par exemple, l'indexation de la flotte peut identifier les éléments pour lesquels une version de package spécifique est installée ou non, pour laquelle aucune version de package n'est installée ou qui correspondent à des paires nom-valeur spécifiques. Enfin, l'indexation de flotte fournit des mesures standard et personnalisées que vous pouvez utiliser pour avoir un aperçu de l'état de votre flotte. Pour plus d’informations, consultez Préparation de l'indexation de la flotte.

Note

L'activation de l'indexation du parc pour le Catalogue de Logiciels entraîne des coûts de service standard. Pour plus d'informations, consultez AWS IoT Device Management Pricing

Ombre nommée réservée

Le Ombre nommée réservée$package, reflète l'état des packages logiciels et des versions de packages installés sur l'appareil. L'indexation de flotte utilise l'ombre nommée réservée comme source de données pour créer des métriques standard et personnalisées afin que vous puissiez interroger l'état de votre flotte. Pour de plus amples informations, veuillez consulter Preparing fleet indexing.

Une ombre nommée réservée est similaire à une ombre nommée, sauf que son nom est prédéfini et que vous ne pouvez pas le modifier. En outre, l'ombre nommée réservée n'est pas mise à jour avec les métadonnées et utilise uniquement les attributes et version mots clés.

Les demandes de mise à jour qui incluent d'autres mots clés, tels que description, recevront une réponse d'erreur dans le rejected sujet. Pour plus d'informations, consultez Device Shadow error messages.

Il peut être créé lorsque vous créez un AWS IoT objet via la console, lorsqu'une AWS IoT tâche se termine avec succès et met à jour le shadow, et si vous lancez l'opération d'UpdateThingShadowAPI. Pour plus d'informations, consultez UpdateThingShadowle guide du AWS IoT Core développeur.

Note

L'indexation de l'ombre nommée réservée n'est pas prise en compte dans le nombre d'ombres nommées que l'indexation de flotte peut indexer. Pour plus d'informations, consultez AWS IoT Device Management fleet indexing limits and quotas. En outre, si vous choisissez de faire en sorte que les AWS IoT jobs mettent à jour l'ombre nommée réservée lorsqu'une tâche est terminée avec succès, l'appel d'API est comptabilisé dans votre Device Shadow et vos opérations de registre et peut entraîner un coût. Pour plus d'informations, consultez les rubriques Limites et quotas des AWS IoT Device Management tâches ainsi que le type de données de l'IndexingFilterAPI.

Structure de l'$packageombre

L'ombre nommée réservée contient les éléments suivants :

{ "state": { "reported": { "<packageName>": { "version": "", "attributes": { } } } }, "version" : 1 "timestamp" : 1672531201 }

Les propriétés de l'ombre sont mises à jour avec les informations suivantes :

  • <packageName> : nom du package logiciel installé, qui est mis à jour avec le paramètre PackageName.

  • version : nom de la version du package installé, qui est mise à jour avec le paramètre versionName.

  • attributes : métadonnées facultatives stockées par l'appareil et indexées par l'indexation de la flotte. Cela permet aux clients d'interroger leurs index en fonction des données stockées.

  • version : le numéro de version de l’ombre. Elle est automatiquement incrémentée chaque fois que l'ombre est mise à jour et commence à 1.

  • timestamp :Indique quand l'ombre a été mise à jour pour la dernière fois et est enregistrée à l'heure Unix.

Pour plus d'informations sur le format et le comportement d'une ombre nommée, consultez Service AWS IoT Device Shadow Ordre des messages.

Suppression d'un package logiciel et de ses versions

Avant de supprimer un package logiciel, effectuez les opérations suivantes :

  • Vérifiez que le package et ses versions ne sont pas activement déployés.

  • Supprimez d'abord toutes les versions associées. Si l'une des versions est désignée comme version par défaut, vous devez supprimer la version par défaut nommée du package. La désignation d'une version par défaut étant facultative, il n'y a aucun conflit lors de sa suppression. Pour supprimer la version par défaut du package logiciel, modifiez le package via la console ou utilisez l'opération UpdatePackageVersionAPI.

Tant qu'il n'existe pas de version de package par défaut nommée, vous pouvez utiliser la console pour supprimer un package logiciel et toutes ses versions de package seront également supprimées. Si vous utilisez un appel d'API pour supprimer des packages logiciels, vous devez d'abord supprimer les versions des packages, puis le package logiciel.