• Un serveur Constellation
• Des sentinelles Constellation
• Des packages déployés sur ces sentinelles
• Des contrôleurs et consommateurs qui peuvent se connecter au serveur

Les Sentinelles

Une sentinelle est un agent de déploiement pour Constellation. Concrètement il s’agit d’une application (ou service) installée sur un système Windows ou Linux et qui tourne en tache de fond.

Le rôle d’une sentinelle est d’exécuter les ordres provenant du serveur Constellation pour :

• Déployer des packages, c’est à dire télécharger des packages (= des programmes) depuis le serveur et les démarrer localement
• Contrôler les packages déployés sur la sentinelle (démarrer, arrêter ou redémarrer un package)
• Remonter les informations au serveur Constellation sur chaque package (état, consommation des ressources CPU et RAM, etc..)

Une fois une sentinelle installée et enregistrée dans une Constellation, il est possible depuis l’API ou la Console de suivre son état.

Les packages

Les packages sont des applications graphiques ou non graphiques (services) stockées dans le “Package Repository” du serveur Constellation et qui seront déployés sur des sentinelles de la Constellation.

Vous pouvez déployer autant de package que vous souhaitez sur chaque sentinelle. Une fois le package démarré, vous retrouverez son état et sa consommation de ressource dans la Console ou via l’API. Vous pourrez également l’arrêter, le redémarrer ou forcer la mise à jour du package.

Le package lui-même remonte ses logs dans Constellation et récupère ses paramètres de configuration (les Settings) depuis Constellation.

Ainsi si vous souhaitez changer une variable de configuration de l’un de vos packages, vous pouvez le faire directement depuis l’API ou la Console et propager cette mise à jour au package en question.

Chaque package peut produire des données publiées dans ce que l’on nomme des « StateObjects » qui seront accessibles par les autres packages et les consommateurs (comme une page Web) de sa Constellation. De même un package peut consommer les StateObjects produits par les autres packages de la Constellation.

Enfin chaque package peut échanger des messages avec les autres packages ou consommateurs connectés sur les hubs Constellation ce qui permet par exemple d’invoquer des méthodes sur d’autre système (ce que l’on nomme les MessageCallbacks).

A noter qu’il existe aussi une notion de « package virtuel » expliquée à la page suivante.

Les consommateurs

Le serveur Constellation expose une interface REST ainsi qu’un hub nommé « Consumer » à destination des « consommateurs ».

Une page Web par exemple est un consommateur, c’est à dire qu’elle se connecte à Constellation pour interroger des StateObjects ou envoyer/recevoir des messages mais elle n’est pas considérée comme un package dans le sens où une page Web n’est pas un programme déployé et démarré par une sentinelle (son cycle de vie est lié au navigateur du client). Un “consommateur” ne peut ni produire des logs ni avoir de settings ou encore publier des StateObjects. Il ne fait que consommer ni plus ni moins !

Les contrôleurs

Le serveur Constellation expose un hub nommé “Controller” permettant contrôler des éléments de la Constellation comme arrêter/démarrer des packages, s’abonner et récupérer en temps réel les logs des packages de la Constellation, propager les changements de configuration dans la Constellation, suivre l’ état et la consommation des ressources de chaque packages, etc…

Ce hub est notamment utilisé par la Console Constellation pour vous fournir une interface de pilotage de votre Constellation.

Pour se connecter sur ce hub, le credential utilisé pour l’authentification doit avoir la clé « EnableControlHub » activée.

The post L’architecture Constellation et les différents acteurs : sentinelle, package, contrôleur et consommateur appeared first on Constellation.

Tout cela est possible sur de véritables systèmes d’exploitation, tel que Windows ou Linux, car en effet un package n’est ni plus ni moins qu’une application ou un programme (graphique ou non) déployé sur une sentinelle. La vie d’un package est ainsi contrôlée par Constellation.

Seulement ce mécanisme n’est pas toujours possible. Si vous prenez un Arduino/ESP, NetDuino/Gadgeteer ou équivalent, il n’y a pas de notion de “processus”. Le programme est directement « téléversé » lors de l’opération de programmation de la puce. Une fois débranché, le microprogramme fonctionne de manière autonome mais il n’est pas possible de le modifier.

Autre exemple : un script Powershell. Le “programme” est dans le script lui-même. Il n’a pas de capacité de s’auto-programmer.

C’est pour cela que Constellation apporte cette notion de “sentinelles et packages virtuels”. En effet, une sentinelle virtuelle n’existe pas dans le sens il n’y a pas de « sentinelle » capable de déployer un package. Cette notion existe seulement décrire l’identité du package « virtuel ». Le package existe dans le sens où il fait partie de l’objet ou du script, mais il n’est ni stocké et ni déployé par la Constellation, il est « virtuel ».

Prenez l’exemple d’une sonde de température réalisée avec un Arduino/ESP8266 et connectée à Constellation.

Vous allez déclarer dans votre Constellation une sentinelle “virtuelle” nommée “CapteurSalon”. Cette sentinelle « contiendra » (virtuellement) un package virtuel nommé “Temperature”. Ce package est virtuel car il n’y a aucun package de ce nom dans le repository de votre serveur.

Dans votre microprogramme Arduino/ESP, vous allez identifier votre Arduino comme étant la sentinelle “CapteurSalon” exécutant le package “Temperature”.

Vous serez alors connecté à Constellation et votre package “virtuel” pourra exploiter les différentes fonctionnalités de la Constellation :

• Récupération des settings définis sur le serveur
• Envoi des logs
• Production de StateObjects
• Exploitation des StateObjects de la Constellation
• Echange de messages pour l’invocation de méthode (les MessageCallbacks)

D’un point vue Constellation, il s’agit d’un véritable package. Le package se nomme « Temperature » et est exécuté par la sentinelle « CapteurSalon ». Il s’agit en tout point d’un véritable package à la différence qu’il n’y pas la partie “orchestration”, c’est à dire qu’on ne pourra pas l’arrêter/démarrer à distance ce package ou encore déployer de nouvelles versions du package depuis Constellation.

The post Sentinelles et Packages « virtuels » appeared first on Constellation.

Message & Scope

Les notions de base du Messaging de Constellation sont :

Un message :

• porte obligatoirement une clé (le MessageKey), en quelque sorte l’équivalent du “Sujet” d’un mail.
• peut contenir optionnellement un contenu, nommé “Data”
• est envoyé à un scope.

Un scope :

• défini les destinataires d’un message
• peut être de différents types :
  • All : c’est à dire que tous les systèmes connectés dans Constellation recevront le message (y compris l’émetteur)
  • Other : tout le monde sauf l’émetteur
  • Package : cible un ou plusieurs packages
  • Sentinel : cible tous les packages hébergés sur les sentinelles visées par le scope
  • Group : cible les packages ou consommateurs appartenant aux groupes visés par le scope

Les scopes “Package”, “Sentinel” et “Group” peuvent déclarer une liste de packages, de sentinelles et de groupes.

• Lorsque l’on cible une sentinelle, on vise tous les packages qu’elle héberge.
• Lorsque l’on cible un package, on vise toutes les instances de ce package sur les sentinelles de votre Constellation.

Si vous voulez cibler un seul package en particulier, vous devez obligatoirement créer un scope de type Package et définir le nom du package préfixé du nom de la sentinelle avec la nomenclature “SENTINEL/Package”.

Chaque package ou consommateur peut s’inscrire à un groupe ou être inscrit d’office dans la configuration du serveur (lire l’article sur les groupes).

MessageCallback

Les messages dans Constellation servent essentiellement à invoquer des méthodes. On appelle cela des “MessageCallbacks” le fait de lier un message à une fonction de votre programme.

Il s’agit tout simplement déclarer une méthode de votre code comme « MessageCallback », c’est à dire que si le package reçoit un message dont la clé du message est le nom d’une méthode déclarée comme MessageCallback, alors cette méthode sera invoquée. Le contenu du message reçu (c’est à dire les “Datas”)  contiendra les paramètres de la méthode.

De la même façon, pour invoquer une méthode d’un autre package, il suffit d’envoyer un message dont la clé est la méthode à invoquer avec comme contenu de message les paramètres à passer à cette méthode.

Les Sagas

Chaque message envoyé dans Constellation est à sens unique. Il n’y a aucun retour.

Un message est envoyé à un scope,  il peut ne jamais être reçu (si « personne » n’est visée par le scope) ou à l’inverse être reçu par tout le monde.

Cependant il y a certain cas où il est indispensable d’obtenir une réponse à un message ! Comme en programmation, il n’y a pas que des procédures, il y a aussi des fonctions.

Pour cela, Constellation propose le concept de “Saga”. Une saga est un identifiant porté par un scope. Pour faire l’analogie, “La guerre des étoiles”, “L’Empire contre-attaque » ou “Le Retour du Jedi” sont trois films distincts qui portent le même identifiant de Saga : “Star Wars”.

Il en va de même pour les messages Constellation. Pour “répondre”, il suffit d’envoyer un message “de réponse” à un scope qui vise l’émetteur du message original en prenant soin d’utiliser le même identifiant de saga.

Ainsi l’émetteur en recevant ce message, pourra savoir qu’il s’agit de la réponse à son message car il retrouvera le même identifiant de saga.

Bien entendu l’identifiant de Saga doit être unique et aléatoire pour chaque couple “Request / Response” .

De ce fait, lorsque l’on reçoit un message, si le scope porte un identifiant de Saga cela veut dire que l’émetteur a envoyé le message “dans une Saga”, il s’attend donc à recevoir une réponse. Le clé d’un message de réponse est toujours “__Response”.

Auto-description des MessageCallbacks

Chaque packages (virtuel ou non) doit ou devrait déclarer son “Package Descriptor”.

Il s’agit de la description du package qui contient entre autre les MessageCallbacks du package, c’est à dire les méthodes que le package expose dans la Constellation.

Le MessageCallback Explorer de la Console Constellation exploite les “Package Descriptors” connus pour créer la liste de l’ensemble des MessageCallbacks exposés par les package d’une Constellation avec le détail des paramètres en entrée et le type de retour. Il est également possible d’invoquer ces MC avec une interface de test et de générer le code pour invoquer ces MC sur les différentes API de Constellation.

The post Messaging : Message, Scope, MessageCallback et Saga appeared first on Constellation.

Ils représentent des variables de type simple (numérique, chaîne de caractère, booléen, etc..) ou de type complexe (objet formaté en JSON).

Les StateObjects sont tous stockés sur le serveur Constellation et peuvent être interrogés par n’importe quels packages ou consommateurs de la Constellation (sauf si des autorisations restreignent l’accès).

Le StateObject

Chaque StateObject comporte :

• Le nom de la sentinelle et du package qui a produit le StateObject
• Un nom (la clé d’un StateObject)
• Une valeur
• Une date de mise à jour
• Une durée de vie en seconde (“0” si infinie)
• Un type
• Des métadatas (dictionnaire de clé / valeur)

Dans la philosophie Constellation, chaque package (virtuel ou non) publie des StateObjects représentant des « variables publiques ».

Par exemple un capteur de température Arduino publiera des StateObjects sur la température ou humidité qu’il relève, un package comme le “HWMonitor” publiera des StateObjects sur les compteurs hardware qu’il mesure (consommation CPU, RAM, etc..), ou encore un package comme celui “Paradox” publiera des StateObjects pour chaque zone d’un système d’alarme où chaque StateObject contiendra un objet indiquant l’état de la zone (ouverte/fermée, en alarme ou non, en défaut ou non, etc..).

Le « StateObject Explorer » de la Console Constellation permet d’explorer l’ensemble des StateObjects de la Constellation :

Avec la possibilité de visualiser tous les détails et de vous abonner aux mises à jour en temps réel :

La capture ci-dessus montre un StateObject produit par le package “NetAtmo” qui représente le détail d’un capteur NetAtmo (Id, version du firmware, nom du capteur, statuts de la communication, niveau de la batterie, etc..).

Comme chaque package peut publier des StateObjects dans Constellation, il est possible en interrogeant les StateObjects de votre Constellation de connaitre en temps réel l’état de tous vos systèmes (ou du moins “le dernier état connu”).

A noter que l’unicité d’un StateObject est obtenu par le triplet : “Sentinel + Package + Nom” car un nom de StateObject est unique pour une instance de package (couple Sentinel / Package), de même qu’un package est un unique pour une sentinelle et qu’une sentinelle est unique dans une Constellation.

Interrogation, abonnement et filtre

Dans les librairies Constellation (JavaScript, .NET, Python, Arduino, etc..) et d’un point de vue plus générique avec les interfaces REST Constellation vous allez retrouver les mêmes fonctionnalités :

• Le “Request” de StateObject
• Le “Subscribe” de StateObject

Le “Request” permet de récupérer la dernière valeur connue d’un ou de plusieurs StateObjects.

Le ”Subscribe” permet de créer un abonnement sur un ou plusieurs StateObjects. Une fois abonné, vous serez notifié en temps réel des qu’un StateObject de votre abonnement est mis à jour.

Dans ces deux méthodes vous serez amené à définir le ou les StateObjects que vous souhaitez récupérer ou suivre. Pour cela vous devez définir un filtre en indiquant :

• Le nom de la sentinelle du StateObject
• Le nom du package du StateObject
• Le nom du StateObject
• Le type du StateObject

Pour chaque filtre vous pourrez appliquer le wildcard “*” pour accepter toutes les valeurs possibles.

Ainsi appliquer le filtre /// sélectionnera tous les StateObjects de votre Constellation. N’oubliez pas que l’unicité d’un StateObject est obtenue par le triplet : “Sentinel + Package + Nom”.

Quelques exemples :

• */Demo/*/* : sélectionne tous les StateObjects du package “Demo” quelque soit la sentinelle
• MonPC/Demo/*/* : sélectionne tous les StateObjects du package “Demo” de la sentinelle “MonPC”
• MonPC/*/*/* : tous les StateObjects produits sur la sentinelle MonPC
• MonPC/*/*/MyData : tous les StateObjects de type “MyData” et produits sur la sentinelle MonPC
• MonPC/Demo/ABC/* : le StateObject ABC du package Demo sur la sentinelle MonPC

The post Les StateObjects appeared first on Constellation.

L’AccessKey

Chaque requête au serveur Constellation comporte soit dans les paramètres de l’URL (querystring) soit dans les entêtes (headers) HTTP trois informations :

• SentinelName : le nom de la sentinelle
• PackageName : le nom du package
• AccessKey : la clé d’accès

Les paramètres “SentinelName” et “PackageName” permettent d’identifier le package qui réalise la requête car un package (virtuel ou non) est toujours associé à une sentinelle (virtuelle ou non).

En fait le couple “SentinelName/PackageName” forme l’identifiant unique du package (nommé instance de package) dans la Constellation et l’AccessKey peut être comparé au “mot de passe”.

Une sentinelle (virtuelle ou non) déclarée dans la configuration de votre Constellation doit obligatoirement être associée à une clé d’accès et les packages (virtuels ou non) déclarés sur une sentinelle utilisent implicitement la même clé d’accès ou bien peuvent redéfinir une clé spécifique.

Il y a quelques cas particuliers :

• Lorsqu’une sentinelle produit des logs, son “PackageName” est “Sentinel”
• Pour les consommateurs ou contrôleurs, le “SentinelName” est soit “Consumer” ou soit “Controller” et le “PackageName” sert de “FriendlyName” pour les logs
• Dans le cas de l’utilisation de la fonction de “Debug on Constellation” depuis le SDK VisualStudio, le “SentinelName” est “Developer”

Les Credentials

Dans le fichier de configuration de votre Constellation, on ne déclare pas l’AccessKey directement sur une sentinelle ou un package.

En effet une sentinelle est associée à un credential et un package utilise implicitement le même credential que sa sentinelle ou bien redéfini son propre credential.

Un credential comporte obligatoirement deux propriétés :

• Le nom (unique) du credential
• L’AccessKey

Pour authentifier une requête, le serveur Constellation regardera alors si l’AccessKey de la requête correspond bien à celle déclarée pour le credential utilisé par le couple Sentinel/Package.

Un credential peut définir les propriétés suivantes :

• Enable : indique si le credential est activé ou désactivé
• EnableControlHub : indique si le credential peut se connecter sur le hub de contrôle (pour l’administration de la Constellation)
• EnableManagementAPI : indique si le credential peut se connecter à l’API de Management (pour l’édition de la configuration)
• EnableDeveloperAccess : indique si le credential peut utiliser la sentinelle virtuelle “Developer” pour debugger des packages (utilisé par le SDK Visual Studio)

Vous pouvez gérer les credentials depuis la Console Constellation ou depuis le fichier de configuration.

Login et AccessKey

L’AccessKey doit être une chaîne de caractère assez longue et sera utilisée un peu comme un mot de passe pour l’authentification.

Cependant il est assez compliqué de retenir un AccessKey surtout comparé à un couple “login / password” que nous utilisons au quotidien.

C’est pourquoi la Console Constellation, les installeurs Constellation ou encore le SDK Constellation propose d’utiliser un login/password pour générer un AccessKey.

La formule est très simple : AccessKey = sha1(login + password). En clair une clé d’accès peut être obtenue par le hash SHA1 de la concaténation du login avec un mot de passe.

Par exemple, si mon login est “admin” et que mon mot de passe est “P@ssw0rd” alors ma clé d’accès (AccessKey) sera a5761adf00e4060f05fab7017b32905cc9e5d540 (= le hash SHA1 de “adminP@ssw0rd”).

Les Authorizations

Par défaut un credential actif (enable=true) à le droit d’interroger (Request ou Subscribe) tous les StateObjects de votre Constellation sans restriction ou d’envoyer des messages à n’importe quel scope ou encore de s’abonner n’importe quel groupe.

Imaginez maintenant que vous réalisez une page Web en Javascript connectée à votre Constellation pour afficher les valeurs de quelques StateObjects en temps réel ou encore pour envoyer des messages pour contrôler certains dispositifs.

Dans le cas présent, si il s’agit d’une page JavaScript, le code est “client-side”, donc n’importe quelle personne ayant accès à cette page pourra visualiser le code source et récupérer l’AccessKey utilisée.

En clair si vous développez un petit morceau de Javscript pour afficher en temps réel la consommation de votre CPU (StateObject produit par le package HWMonitor par exemple) sur votre site Web, n’importe qui pourrait récupérer votre clé d’accès et suivre en temps réel le statut de votre alarme, votre courbe de poids, la température de votre chambre, le volume de votre ampli, etc… Ou pire encore, envoyer différents messages dans votre Constellation pour éteindre des machines, allumer des lumières, ouvrir la porte de garage, augmenter le chauffage, etc…

Un concept « d’autorisation” a été introduite dans la version 1.8 de Constellation pour restreindre les droits sur une clé d’accès (AccessKey) sur les éléments suivants :

• L’interrogation des StateObjects
• L’envoi de message (invocation des MessageCallback)
• L’abonnement à des groupes de message

De ce fait, si vous souhaitez afficher par exemple la consommation de votre CPU de telle machine, vous allez créer un credential qui n’aura que le droit (autorisation) de visualiser ce StateObject ni plus ni moins.

Plus d’information, consultez l’article dédié à la configuration des autorisations.

The post La sécurité : AccessKey, Credential et Authorization appeared first on Constellation.

Il héberge des hubs et des interfaces HTTP/REST. De plus il peut également héberger des fichiers statiques en configurant le “fileServer” ce qui permet par exemple l’auto-hébergement de la console Constellation (plus d’info ici).

Les hubs Constellation sont basés sur la technologie SignalR permettant d’exposer des canaux de communication bi-directionnels et temps réel en HTTP long-polling, server-event ou WebSocket en fonction des capacités du client.

Les interfaces HTTP/REST sont en fait des contrôleurs WebAPI exposant des méthodes en HTTP/REST. Les interfaces HTTP/REST permettent d’exposer des fonctionnalités de Constellation de manière très simple pour les devices ou frameworks ne pouvant supporter SignalR.

Il existe 4 hubs :

• Constellation
• Consumer
• Controller
• Sentinel

Ainsi que 3 interfaces HTTP/REST :

• Constellation
• Consumer
• Management

Le hub et l’interface HTTP “Constellation” sont utilisés par les packages Constellation (réels ou virtuels). Ils exposent des méthodes pour écrire des logs, pour récupérer les settings, pour publier ou interroger des StateObjects, envoyer ou recevoir des messages, etc…

Le hub et l’interface HTTP “Consumer” sont utilisés par les “consommateurs”. Par exemple une page Web est un consommateur, c’est à dire qu’elle se connecte à Constellation pour interroger des StateObjects ou envoyer/recevoir des messages mais elle n’est pas un package (son cycle de vie est lié au navigateur du client). Un “consommateur” ne peut pas produire des logs, avoir de settings ou encore publier des StateObjects.

Le hub “Controller” expose des méthodes pour contrôler la Constellation comme arrêter/démarrer des packages, s’abonner et récupérer en temps réel les logs des packages de la Constellation, propager les changements de configuration dans la Constellation, suivre les états et consommation des ressources des packages, etc… Ce hub est notamment utilisé par la Console Constellation pour vous fournir une interface de pilotage de votre Constellation. Pour pouvez également vous connecter et exploiter les fonctionnalités de contrôle de vos pages Web ou packages .NET.

Le hub “Sentinel” est un hub privé réservé aux sentinelles de la Constellation. C’est sur ce hub que les sentinelles s’enregistrent, remontent les états des packages qu’elles supervisent, etc…

Enfin l’interface HTTP “Management” aussi nommée “Management API” est une API HTTP/REST de management du serveur permettant la gestion des sentinelles, des packages, des settings, des credentials, etc… Cette API est notamment utilisée par la Console Constellation pour vous fournir une interface d’administration de votre Constellation.

The post Les différents hubs et interfaces REST du serveur Constellation appeared first on Constellation.

Concrètement un package est un fichier ZIP qui contient un exécutable (exe) qui sera exécuté et supervisé par une sentinelle.

Sentinel + Package = Instance de package

Par défaut, Constellation va utiliser le package dont le nom est celui de l’instance que vous déclarez dans la configuration.

Par exemple, pour déployer le package “HWMonitor” sur la sentinelle nommée “SENTINEL-DEMO”, on écrira dans le fichier de configuration :

<sentinel name="SENTINEL-DEMO" credential="Standard">
    <packages>    
      <package name="HWMonitor"></package>
    </packages>
</sentinel>

L’attribut “name” du package est le nom de l’instance du package. On parlera alors de l’instance “SENTINEL-DEMO/HWMonitor” pour identifier de manière unique l’instance de ce package dans une Constellation.

Lors du déploiement, Constellation va analyser chaque package dans son repository pour récupérer celui dont le nom déclaré son manifeste correspond au nom de notre instance.

Dans le cas où il ne trouve aucun package dont le manifeste déclare le nom de package recherché, il va tenter de sélectionner le package à partir du fichier “<nom d’instance>.zip”. Si ce fichier n’existe pas alors une erreur sera levée dans les logs de la Constellation.

Dans notre cas, Constellation va analyser chaque package de son repository (c’est à dire chaque fichier .ZIP) pour récupérer celui qui a dans son manifeste (PackageInfo.xml) déclaré la propriété “Name” à “HWMonitor”. Si il ne le trouve pas, il va tenter de récupérer le package par le nom de fichier “HWMonitor.zip”.

Versioning des packages

En plus du nom du package, le manifeste (PackageInfo.xml) déclare également d’autre information comme la version du package.

Le “Package Repository” d’un serveur Constellation peut donc contenir plusieurs versions d’un même package.

Par exemple, imaginez les packages suivants stockés dans le “Package Repository” de votre serveur Constellation :

• HWMonitor.zip (avec dans le manifeste: Name=”HWMonitor” et Version=”1.0”)
• HWMonitor-1.1.zip (avec dans le manifeste: Name=”HWMonitor” et Version=”1.1”)
• HWMonitor-1.2.zip (avec dans le manifeste: Name=”HWMonitor” et Version=”1.2”)

Note : la nomenclature des noms des fichiers dans le repository n’a aucune importance.

Si dans votre fichier de configuration vous déclarez simplement la ligne suivante :

<package name="HWMonitor"></package>

Constellation trouvera donc 3 packages qui correspondent (car l’attribut name=”HWMonitor” dans les trois packages). Dans ce cas, le serveur Constellation va sélectionner le package dont la version est la plus haute.

Ainsi dans cet exemple, c’est le package “HWMonitor-1.2.zip” qui sera déployé sur la sentinelle pour l’instance “HWMonitor”.

Résolution explicite du fichier d’un package

Jusqu’à présent la règle est donc d’utiliser le fichier dont le nom du package (d’après son manifeste) correspond au nom de l’instance déclarée (package “HWMonitor <> instance “HWMonitor”) et si plusieurs fichiers correspondent on sélectionne la version la plus haute. A contrario, si aucun fichier n’est trouvé, on tente d’utiliser le fichier “<nom d’instance>.zip”.

C’est donc une résolution “implicite” du fichier du package qui est réalisée par le serveur Constellation.

Toutefois il est possible de contourner ce comportement et de définir explicitement le fichier d’un package à utiliser grâce à l’attribut “filename”.

Si dans votre fichier de configuration vous déclarez la ligne suivante :

<package name="HWMonitor" filename="HWMonitor-1.1.zip"></package>

Vous définissez explicitement que cette instance nommée “HWMonitor” utilisera le package contenu dans le fichier “HWMonitor-1.1.zip”. On peut donc forcer l’utilisation d’une version spécifique en déclarant explicitement le fichier à utiliser pour une instance d’un package.

On aurait aussi pu écrire :

<package name="HWMonitor" filename="DemoPackage.zip"></package>

C’est à dire qu’on déclare une instance d’un package nommée “HWMonitor” utilisant le package contenu dans le fichier “DemoPackage.zip”, ce qui n’a pas de sens mais est tout à fait possible !

Ainsi pour résumer, Constellation utilise donc en priorité le fichier défini par l’attribut “filename”. Dans le cas contraire on applique la règle implicite définie précédement.

Instances multiples d’un même package

Avec cet attribut “filename” il devient possible de déployer plusieurs instances d’un même package sur une même sentinelle tant que le nom d’instance est différent.

Prenez la configuration suivante :

<sentinel name="SENTINEL-DEMO" credential="Standard">
    <packages>    
      <package name="HWMonitor1" filename="HWMonitor.zip"></package>
      <package name="HWMonitor2" filename="HWMonitor.zip"></package>
   </packages>
</sentinel>

Dans cet exemple, on a deux instances du package “HWMonitor.zip” qui seront déployées sur “SENTINEL-DEMO”.

Ces instances “SENTINEL-DEMO/HWMonitor1” et “SENTINEL-DEMO/HWMonitor2” sont deux instances différentes dans votre Constellation et peuvent avoir des configuration (settings) différentes mais elles sont basées sur le même code, car elles partagent la même source (le package “HWMonitor.zip”).

Vous pouvez donc déployer le même package plusieurs fois sur une même sentinelle en déclarant plusieurs instances (name) du même package (filename).

Résolution semi-implicite / semi-explicite d’un package

Le problème des instances multiples est que vous déclarez explicitement le fichier (filename) à utiliser.

Dans l’exemple précèdent “SENTINEL-DEMO/HWMonitor1” et “SENTINEL-DEMO/HWMonitor2” sont des instances du même package “HWMonitor.zip” qui d’après les exemples précédents correspond à la version “1.0” du package “HWMonitor”.

Toujours d’après les exemples précédents, on dispose également de la version 1.1 et 1.2 de ce package dans le « Package Repository »  (fichiers HWMonitor-1.1.zip et HWMonitor-1.2.zip).

Pour mettre à jour ces deux instances (“SENTINEL-DEMO/HWMonitor1” et “SENTINEL-DEMO/HWMonitor2”) vers une version plus récente, disons la version 1.2, il faudra modifier à la fois l’attribut “filename” de l’instance “HWMonitor1” mais également celui de l’instance de “HWMonitor2”.

Ce qui revient à écrire :

<sentinel name="SENTINEL-DEMO" credential="Standard">
    <packages>    
      <package name="HWMonitor1" filename="HWMonitor-1.2.zip"></package>
      <package name="HWMonitor2" filename="HWMonitor-1.2.zip"></package>
   </packages>
</sentinel>

Pour éviter cela, il y a un “mode intermédiaire” qu’on pourrait nommer résolution “semi-implicite” ou “semi-explicite” car il s’agit d’un mixte de ces deux modes !

Pour l’utiliser, il suffit d’omettre l’extension “.zip” dans l’attribut “filename”.

Dans notre exemple, déclarez simplement :

<sentinel name="SENTINEL-DEMO" credential="Standard">
    <packages>    
      <package name="HWMonitor1" filename="HWMonitor"></package>
      <package name="HWMonitor2" filename="HWMonitor"></package>
   </packages>
</sentinel>

On a toujours deux instances “HWMonitor1” et “HWMonitor2” et ces deux instances déclarent le “filename” à “HWMonitor”.

Sans l’extension “.zip”, “HWMonitor” ne correspond à aucun fichier de notre repository et c’est donc là que Constellation réalise une résolution partielle : semi-explicite / semi-implicite.

Cette résolution partielle sélectionne la dernière version du package qui porte le nom déclaré dans attribut “filename” (ici nommé “HWMonitor”).

Ainsi en ajoutant la version 1.3 du package “HWMonitor” dans notre repository, les deux instances seront mises à jour avec la version 1.3 de ce package sans avoir besoin de modifier la configuration de notre Constellation.

Pour résumer

• Un package déployé sur une sentinelle est une instance de package (couple Sentinelle/Package)
• Chaque instance a son propre cycle de vie, sa propre configuration et sa propre identité dans la Constellation
• Il n’y a pas de lien entre le nom du package et le nom de l’instance du package, vous pouvez nommer vos instances sans restriction à partir du moment où elles sont uniques pour une même sentinelle
• Vous pouvez avoir plusieurs instances d’un même package sur une même sentinelle
• Vous pouvez également avoir plusieurs instances de versions différentes d’un même package sur une même sentinelle
• Les packages (fichiers ZIP) sont tous stockés dans le “Package Repository” du serveur
• Pour résoudre le package à utiliser pour une instance :
  1. Si l’attribut “filename” est défini :
     1. Et qu’il correspond à un fichier du “Package Repository”, c’est ce package qui sera utilisé pour l’instance du package
     2. Sinon, sans extension .ZIP, on utilise la version la plus haute du package dont le nom (déclaré dans le manifeste) est celui déclaré dans l’attribut “filename”
  2. Sinon, sans l’attribut “filename” :
     1. On utilise la version la plus haute du package dont le nom (déclaré dans le manifeste) est celui déclaré dans l’attribut “name” (c’est à dire le nom de l’instance du package)
     2. Sinon on utilise le package qui se nomme <name>.zip si ce fichier existe dans le “Package Repository”
     3. Sinon une erreur est levée

The post Instance de package, package, versioning, multi-instances et résolution des packages appeared first on Constellation.

Ce fichier est automatiquement créé par Visual Studio lorsque vous créez un projet de type Constellation.

Il contient trois parties :

1. Les informations générales sur votre package
2. Les informations de compatibilité du package
3. Les informations sur les settings du packages

Exemple :

<?xml version="1.0" encoding="utf-8" ?>
<Package xmlns="http://schemas.myconstellation.io/Constellation/1.8/PackageManifest"
         Name="DemoPackage" 
         Version="1.0"
         Author="Sebastien Warin"         
         URL="http://sebastien.warin.Fr"
         Description="Demo package for Constellation"
         RequestLastStateObjectsOnStart="true"
         EnableControlHub="false">
  <Compatibility constellationVersion="1.8">
    <Platforms>
      <Platform id="Win32NT" isCompliant="true" />
      <Platform id="MacOSX" isCompliant="false" />
      <Platform id="Unix" isCompliant="true" />
    </Platforms>
  </Compatibility>
  <Settings>
    <Setting name="MonInterval" type="Int32" defaultValue="2016" isRequired="false" />
    <Setting name="MyConfigElement" type="ConfigurationSection" isRequired="true" schemaXSD="MyPackageConfigurationDesigner.xsd" />
  </Settings>
</Package>

Informations générales

Vous pouvez définir sur l’élément racine “Package” les attributs suivants :

• Name : le nom du package (il s’agit de l’identifiant). Si pas défini, le nom du package est le nom du fichier (sans l’extension ”.zip”)
• Description : le texte de description de votre package tel qu’il apparaîtra sur le catalogue
• Author : nom de l’auteur du package
• URL : URL de l’auteur
• PackageUrl : URL spécifique au package
• Version : version du package. Si pas défini, la version du package est le numéro de version de l’assembly.
• Icon : chemin relatif vers l’icone du package
• ExecutableFilename : le nom de l’exécutable du package. Si pas défini, l’exécutable est le “<nom du package>.exe”
• RequestLastStateObjectsOnStart : booléen indiquant si vous souhaitez recevoir les StateObjects produits par votre package lors de sa dernière exécution. (voir ici)
• EnableControlHub : booléen indiquant si vous souhaitez connecter votre package au hub de contrôle. (voir ici)

Informations de compatibilité

Vous pouvez définir des informations quant à la compatibilité de votre package.

Sur l’élément “Compatibility” vous pouvez indiquer les attributs suivants :

• dotNetTargetPlatform : version du framework .NET utilisée (net40 ou net45)
• constellationVersion : version de la Constellation utilisée (“1.7” ou “1.8” à l’heure actuelle)

Vous pouvez également ajouter des éléments enfants “Platforms” pour indiquer les plateformes supportées. Chaque “Platform” définie les attributs :

• id : identifiant de la plateforme (Win32NT, Unix ou MacOSX)
• isCompliant : booléen indiquant si la plateforme est supportée ou non

Par exemple si vous développez un package Python exploitant les GPIO d’un Raspberry, vous allez indiquer :

<Platforms>
  <Platform id="Win32NT" isCompliant="false" />
  <Platform id="Unix" isCompliant="true" />
  <Platform id="MacOS" isCompliant="false" />
</Platforms>

A l’inverse, un package comme HWMonitor qui utilise des API spécifiques à Windows, vous allez indiquer qu’il n’est pas compatible sur Unix/Linux et MacOS par les lignes :

<Platforms>
  <Platform id="Win32NT" isCompliant="true" />
  <Platform id="Unix" isCompliant="false" />
  <Platform id="MacOS" isCompliant="false" />
</Platforms>

Au démarrage d’un package, la sentinelle lancera des “Warnings” dans les logs Constellation si le package ne respecte pas le contrat de compatibilité sans toutefois bloquer le démarrage.

Ces informations servent également pour la Console Constellation, afin de vous donner des informations lors de la ajout et configuration des packages de votre Constellation.

Informations sur les Settings du package

Enfin, la troisième et dernière partie du manifeste sert à décrire les settings utilisés par un package.

La déclaration des settings dans le manifeste n’a pas impact sur le fonctionnement du package mais il permet de décrire les clés de configuration utilisées par le package pour que des outils tel que la Console Constellation puisse proposer une interface graphique de configuration pour chaque package. Il est donc vivement recommandé de décrire les settings de ses packages. De plus il est possible de définir des valeurs par défaut dans le manifeste.

Chaque setting déclaré dans le manifeste doit obligatoirement comporter les attributs suivants  :

• Name : le nom (clé) du setting
• Type : le type du setting

Le type peut être :

• Boolean : un booléen (true/false)
• Double : un double
• String : un chaine de caractère
• Int32 : un entier (32 bits)
• Int64 : un long (64 bits)
• ConfigurationSection : un section de configuration .NET
• DateTime : un DateTime
• TimeSpan : une durée
• XmlDocument : un document XML
• JsonObject : un objet JSON (objet ou tableau)

Par exemple :

<Settings>
  <Setting name="MyStringSetting" type="String"  />
  <Setting name="MyIntSetting" type="Int32" />
  <Setting name="MyBoolSetting" type="Boolean" />
  <Setting name="MyXmlDocument" type="XmlDocument" />
  <Setting name="MyJsonObject" type="JsonObject" />
</Settings>

Sur chaque setting déclaré, vous pouvez également définir les attributs suivants :

• “isRequiered“ : indique si le setting est obligatoire ou non (par défaut “false”). Si le setting n’est pas déclaré, une erreur est levée.
• “description” : permettant de donner une explication sur le setting (affichée à l’utilisateur sur la Console Constellation)
• “defaultValue” : la valeur par défaut du setting si le setting n’est pas déclaré (plus d’info)
• “schemaXSD” : indique le nom du fichier du schéma XSD (chemin relatif au package) que la valeur XML doit valider (seulement pour les settings de type XmlDocument ou ConfigurationSection)
• “ignoreLocalValue” : si “true” alors la valeur définie dans le fichier local App.config est ignorée  (plus d’info)
• “ignoreDefaultValue” : si “true” alors la valeur par défaut définie dans le manifeste est ignorée

Pour les settings XmlDocument, ConfigurationSection et JsonObject vous pouvez également ajouter une sous-section <defaultContent> sur vos settings pour définir le contenu par défaut.

Par exemple :

<Settings>
  <Setting name="MyStringSetting" type="String" description="This is a String setting" ignoreLocalValue="true" />
  <Setting name="MyIntSetting" type="Int32" isRequired="false" defaultValue="1234"  />
  <Setting name="MyBoolSetting" type="Boolean" />
  <Setting name="MyXmlDocument" type="XmlDocument" schemaXSD="MonSchema.xsd" />
  <Setting name="MyJsonObject" type="JsonObject" isRequired="true" ignoreDefaultValue="true">
    <defaultContent>
      <![CDATA[
      {
        "Number": 123,
        "String" : "This is a test (local)",
        "Boolean": true
      }
      ]]>
    </defaultContent>
  </Setting>
</Settings>

A lire également : Les Settings d’un package

The post Le Package Manifest appeared first on Constellation.