Deploying a Cluster

Version: 17.07

Supported Since: 17.01

Deploying a cluster in IPS gives you a set of running ESB instances within the underlying Kubernetes/OpenShift platform, hosting a chosen set of configurations.

In IPS, each cluster has multiple associated cluster versions, and an active cluster (i.e. one that has running ESB instances) always has an active cluster version. Deploying a cluster effectively sets an active cluster version for the cluster, hence starting set of ESB instances hosting the projects and other configurations associated with the chosen cluster version.

Accessing the Deployment Page

You can access the cluster deployment page via multiple paths:

  • via Deployments tab on cluster details page

  • via the projects page where you can select a set of project versions and choose to deploy them on a preferred cluster

  • via the project version details page where you can attempt to deploy the currently viewing cluster version on a selected cluster

  • via the cluster versions page where you can select an existing cluster version to be directly deployed on the parent cluster

Deployment Page Components

The cluster deployment page is a "workbench" that allows you to put together a set of projects, their port mapping configurations, and additional configuration artifacts, into a single cluster version that can be deployed on the selected cluster. It consists of the following main components:


  • Add Projects button allows adding a new project version to the deployment.

  • Projects tab displays the projects associated with the deployment:

    • Deployed Projects section displays already deployed projects (if any), and will not be changed during the deployment.

    • Pending Updates section displays projects that would be changed (added/removed) during the deployment, with the Status column displaying the corresponding status (To be Deployed or To be Deleted).

add projects button and projects tab
Figure 1. Project-related elements

Port Mappings

Deployed and to-be-deployed projects display a Configure button where you can configure the port mappings for projects that would be deployed during the next deployment cycle.

Port mappings are assignments of external port numbers (visible outside the container network) to ports exposed by (connectors inside) a project, so that they can accept messages from the external network. For example, if your project has a HTTP ingress connector configured for port 8280, unless you map the port to an external port like 30005 that can be accessed outside the cluster (using an IP address of a worker machine in the cluster) you will not be able to send HTTP requests to the connector.
port mapping
Figure 2. Port Mapping configuration pop_up

Configuration Artifacts

Configuration Artifacts tab displays additional configuration files, such as custom libraries, XSDs or log4j2.xml configurations, that should be directly added to the deployed ESB instances ($X_HOME/conf, $X_HOME/lib folders or child paths under them) rather than being embedded in a project archive.

  • Add Uploaded Artifact button allows you to search for and pick an artifact that has been uploaded previously (e.g. a standard log4j2 configuration being used by several clusters).

add uploaded artifact
Figure 3. Add Uploaded Artifact pop-up
  • Add New Artifact button exposes a file uploader that can be used to add a new artifact, including

    • artifact type (Type): Configuration File (e.g. XSD, log4j2.xml) or Library (e.g. .JAR or .so file)

    • actual file (File)

    • artifact upload path on the UltraESB-X instance (Path): relative to

      • $X_HOME/conf in case of a Configuration File

      • $X_HOME/lib in case of a Library

add new artifact
Figure 4. Add New Artifact section


Remarks section contains a text field for including any comments regarding the deployment. This will be visible only when there are pending changes on top of the loaded cluster version (meaning that a new cluster version would be generated during deployment).

Monitoring Facilities

  • Cluster Status Indicator to the left of the Add Projects button displays the real-time status of the cluster while a deployment is ongoing.

  • Deployment Progress Bar provides a detailed view of the status of the cluster, and is continuously refreshed showing you real-time status of the pods that are or have been deployed in it.

cluster status indicator and progress bar
Figure 5. Cluster Status Indicator and Progress Bar

Deployment Page and Cluster Versions

The page allows you to directly deploy an existing cluster version on a cluster, or to make modifications to an existing cluster version (in which case a new cluster version would be generated at deployment time).

When accessed via the Versions or Deployments tab under cluster details, the deployment page will load a 'pure' cluster version (i.e. one that has no pending changes and can be deployed straightaway). In other cases, the page will contain pending changes (e.g. newly added project versions) which would eventually get deployed as a new cluster version.

Regardless of the access path, the deployment page will keep track of the changes you make on the currently loaded cluster version, and will create a new cluster version if and only if there are pending changes (added/removed projects, changed port mappings or added/removed configuration artifacts) at the time of clicking the Deploy button.

If you move away from a deployment page with pending changes without clicking Deploy, the changes will be lost!

Example Scenario

Assume you have a cluster that has already been reconfigured and deployed 5 times (meaning it has 5 old cluster versions):

  • If you want to deploy a new project on top of the currently deployed configuration, along with a customized log4j2.xml configuration:

    1. Go to clusters perspective → DetailsDeployments (which will load the currently deployed cluster version configuration by default).

    2. Click Add Project button and select the desired project version

    3. If the project has exposed ports, click Configure against the new project (now under Pending Changes) and enter a port number for the Endpoint input field

    4. Under Configuration Artifacts tab, click Add New Artifact.

    5. Select Configuration File as the artifact Type.

    6. Select the log4j2.xml file via the File section (either by dragging-and-dropping the file into it, or by clicking the section and using the file picker to pick the file on your local filesystem).

    7. Enter / for Path (which resolves to $X_HOME/conf/ when the file is being added to the actual ESB instance)

    8. Click Deploy.

  • If, instead, you want to deploy the project and the logging configuration, on top of cluster version #3,

    1. Go to clusters perspective → DetailsVersions.

    2. The 5 versions of the cluster would be listed in the versions page.

    3. Click the Deploy button against the desired version (#3).