Sommaire

Un package est une application avec ou sans une interface graphique qu’on déploie et exécute sur une sentinelle de votre Constellation (plus d’information ici).

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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
Instance de package, package, versioning, multi-instances et résolution des packages
Editer la page sur GitHub
Étiqueté avec :                    

Démarrez la discussion sur le forum Constellation