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 manifestesinstall, le nom de l’environnement nouvellement créé. Pour les manifestesupdate, 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 viaGetRegions.--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éfautcs.log.--skipNodeEmails—true(par défaut) oufalse. Quandfalse, 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.