Aller au contenu

Installer un paquet JPS via CLI

Exécuter un paquet JPS (Cloud Scripting) depuis le CLI plateforme sur Stack Harbor PaaS — la méthode install, ses paramètres et deux exemples chiffrés couvrant l'installation par URL et par fichier de configuration.

Un paquet JPS (JSON Platform Specification) est un manifeste Cloud Scripting que la plateforme peut exécuter de bout en bout — provisionnement d’environnement, déploiement de code, configuration d’add-ons, application de personnalisations, ou toute combinaison. Les paquets JPS peuvent être soit des manifestes install (créer de nouveaux environnements) soit des manifestes update (appliquer des changements aux environnements existants comme add-ons).

Le CLI exécute les paquets JPS via une méthode : ~/jelastic/marketplace/jps/install. Cette page parcourt ses paramètres et deux exemples chiffrés.

La méthode install

~/jelastic/marketplace/jps/install \
  --jps {jps} \
  [--envName {envName}] \
  [--settings {settings}] \
  [--nodeGroup {nodeGroup}] \
  [--displayName {displayName}] \
  [--region {region}] \
  [--envGroups {envGroups}] \
  [--ownerUid {ownerUid}] \
  [--logsPath {logsPath}] \
  [--loggerName {loggerName}] \
  [--skipNodeEmails {skipNodeEmails}]

Les paramètres entre crochets sont optionnels.

Paramètres communs

  • --jps — lien vers le fichier manifeste (URL) ou corps du manifeste en ligne.
  • --envName — pour les manifestes install, le nom de l’environnement nouvellement créé. Pour les manifestes update, le nom de l’environnement cible.
  • --settings — objet JSON de paires clé/valeur passé au manifeste. Les paramètres requis sont définis à l’intérieur du manifeste lui-même.

Manifeste install seulement

  • --displayName — alias pour l’environnement créé, affiché dans le tableau de bord.
  • --region — région où l’environnement est créé. Obtenir la liste via GetRegions.
  • --envGroups — liste de groupes d’environnement auxquels le nouvel environnement doit appartenir. Tableau JSON, par exemple ["mygroup", "group/subgroup"].

Manifeste update seulement

  • --nodeGroup — le palier d’environnement auquel l’add-on s’applique. Valeurs courantes : bl (répartiteur de charge), cp (serveur applicatif), cache, sqldb, nosqldb, storage, vps, build, ou un groupe personnalisé pour les conteneurs Docker.

Journalisation et notifications

  • --ownerUid — ID utilisateur d’un compte partagé, quand on installe le paquet sur le compte de quelqu’un d’autre.
  • --loggerName — nom apparaissant à côté de l’horodatage de chaque opération dans le journal d’installation JPS.
  • --logsPath — chemin du fichier utilisé pour le journal d’installation JPS. Par défaut cs.log.
  • --skipNodeEmails — true (par défaut) ou false. Quand false, des notifications courriel sont envoyées pour les nouveaux nœuds créés par ce paquet.

Exemple 1 — installer un add-on depuis une URL

L’add-on TimeZone Change change le fuseau horaire d’un conteneur. Le manifeste est publié sur GitHub.

~/jelastic/marketplace/jps/install \
  --jps https://raw.githubusercontent.com/jelastic-jps/time-zone-change/master/manifest.jps \
  --envName my-app \
  --settings '{"dashoard_url":"America/New_York"}' \
  --nodeGroup cp

Correspondance des paramètres :

  • {jps} — URL du manifeste TimeZone Change.
  • {envName} — environnement existant auquel appliquer l’add-on.
  • {settings} — objet JSON correspondant aux paramètres attendus par le manifeste. Ici, le manifeste attend une seule clé dashoard_url (sic — le manifeste source utilise exactement ce nom de clé) avec une valeur de fuseau horaire.
  • {nodeGroup} — le palier auquel appliquer le changement.

En cas de succès, la réponse inclut "result": 0.

Pour inspecter le fichier journal propre à l’add-on :

~/jelastic/environment/file/read \
  --envName my-app \
  --path "/var/log/jpsaddon.log" \
  --nodeGroup cp

L’entrée de journal confirme que le fuseau a été appliqué.

Exemple 2 — installer avec un fichier de configuration

Pour les installations répétées ou les listes de paramètres plus longues, fournissez tous les paramètres dans un fichier JSON et référencez le fichier dans la commande d’installation.

1. Écrire le fichier de configuration

myparams.json :

{
  "jps": {
    "type": "update",
    "name": "JPS Example",
    "onInstall": {
      "log": "${settings.param1}"
    }
  },
  "envName": "my-app",
  "settings": {
    "param1": "value1"
  },
  "nodeGroup": "cp"
}

Le champ jps peut être soit :

  • Un corps de manifeste en ligne (comme ci-dessus), soit
  • Une URL pointant vers un fichier manifeste (comme dans l’exemple 1).

2. Exécuter install en référençant le fichier

~/jelastic/marketplace/jps/install --myparams myparams.json

Le CLI charge myparams.json et utilise ses clés comme paramètres.

3. Surcharger un paramètre unique

Pour redéfinir un paramètre sans éditer le fichier — par exemple cibler un environnement différent :

~/jelastic/marketplace/jps/install --myparams myparams.json --envName other-env

Les drapeaux ligne de commande surchargent les clés du fichier.

Vérifier l’installation

Le journal d’installation JPS est écrit à l’emplacement spécifié par --logsPath (par défaut cs.log). Pour l’inspection des journaux Cloud Scripting, le tableau de bord expose aussi le même journal sous Import > JPS > View Logs.

Une exécution réussie se termine par "result": 0. Tout autre code de résultat indique que le manifeste a échoué à une de ses étapes ; le journal montre l’étape et la cause.

Quand utiliser un paquet JPS plutôt que plusieurs appels CLI

  • Utilisez des appels CLI individuels pour les opérations isolées qui n’ont pas besoin de coordonner d’état.
  • Utilisez un paquet JPS quand le flux implique provisionner un environnement, déployer du code, appliquer plusieurs add-ons dans un ordre défini, ou quand vous voulez un installateur réutilisable et paramétré que votre équipe peut exécuter depuis le marketplace.

Le format de manifeste permet aussi de construire des installateurs idempotents, de définir des étapes de retour arrière avec onAfterReturn et de conditionner les étapes sur l’état de l’environnement — des modèles qui deviennent verbeux quand assemblés depuis des appels CLI individuels.

Voir aussi