Packaging Standard Overview

Packaging Standard for CI/CD Automation

Packaging Standard, also known as JPS, is used to prepare ready-to-deploy application and add-on templates. These preconfigured solutions can automate environment creation, software installation, configuration, updates, and other lifecycle operations.

Packaging Standard Overview

JPS packages describe the infrastructure, software, configuration, and automation steps needed to deploy or modify a platform solution. The same package can be reused to provide a consistent installation process across compatible platform environments.

Repeatable Deployment Reuse the same manifest to install a predefined solution consistently.
Infrastructure Automation Define environment topology, node types, resource limits, and related settings.
Application Configuration Execute installation and configuration actions after the required nodes are available.
Marketplace Integration Publish prepared packages for convenient deployment through the platform interface.

Application and Add-On Packages

Package TypePurpose
Application Package Creates a new environment and deploys a complete predefined solution.
Add-On Package Applies additional software, configuration, or automation to an existing environment or node layer.
Update Package Runs actions against an existing solution without necessarily creating a new environment.
The exact package behaviour is defined by the manifest type and the actions included in the JPS file.

JPS Manifest

A JPS package is described through a manifest, commonly written in JSON or YAML. The manifest can define metadata, environment topology, user-selectable settings, installation actions, and other lifecycle logic.

type: install
name: Example Application
baseUrl: https://example.com/package/

nodes:
  - nodeType: docker
    nodeGroup: cp
    image: example/application:latest
    cloudlets: 8

onInstall:
  - log: "Application installation started"

A manifest may include sections for:

  • Package name, description, logo, and version information.
  • Environment and node topology.
  • Application settings entered by the user.
  • Installation, configuration, validation, and update actions.
  • External scripts, files, and reusable resources.
  • Success messages, warnings, and error handling.

Automation Workflow

A typical package installation follows this sequence:

  1. The user starts the package from Marketplace, Import, CLI, or API.
  2. The platform reads and validates the manifest.
  3. Required installation settings are collected.
  4. The environment is created or the target environment is selected.
  5. Manifest actions install and configure the solution.
  6. The platform records the operation in the Cloud Scripting log.
  7. The completed application or add-on is made available to the user.
CI/CD usage: JPS packages can serve as reusable deployment definitions inside automated application-delivery workflows.

Package Installation

JPS packages can be started through several platform interfaces:

  • Marketplace package installation.
  • Import through a manifest URL or manifest content.
  • Platform CLI.
  • Marketplace JPS API methods.

A CLI installation can use the following method:

~/jelastic/marketplace/jps/install \
  --jps {manifest_url_or_body} \
  [--envName {environment_name}] \
  [--settings {json_settings}] \
  [--nodeGroup {node_group}]
The required parameters depend on whether the package creates a new environment or updates an existing one.

Installation Logs

Cloud Scripting records the operations performed during package installation. Logs are useful for verifying completed actions and troubleshooting failed steps.

  • Review logs through the Cloud Scripting Console or the platform interface.
  • Use the optional logsPath parameter to define a custom log path.
  • Use loggerName to define the label shown with log entries.
  • Retrieve installation logs through API file-reading methods when automation requires it.
Security: Avoid writing passwords, tokens, private keys, and other sensitive values into installation logs.

Common Use Cases

  • Prepare a complete application stack for one-click deployment.
  • Install monitoring, security, backup, SSL, or administration add-ons.
  • Standardise deployment across development, staging, and production environments.
  • Automate repeatable configuration and maintenance procedures.
  • Distribute packaged solutions through Marketplace.
  • Integrate platform deployments into CI/CD pipelines.

What’s next?